UDC和CUDB 综合培训

WELCOME
AGENDA
› CH1 UDC INTRODUCTION
› CH2 HLR-FE
› CH3 EMA 6.2
› CH4 CUDB
› CH5 DEPLOYMENT & TRAFFIC CASE
› CH6 CUDB SUMMARY
› CH7 CUDB SYSTEM
› CH8 CUDB OPERATION PROCEDURE
› CH9 CUDB OPERATION DETAIL
› CH10 CUDB STATISTIC
› CH11 PG INTRODUCTION
© Ericsson AB 2011 | Introduction | Figure 1-1
UDC和CUDB 综合培训

CH1 UDC Introduction

Objectives
Analyze how User Data Consolidation 11B Solution is
introduced in mobile networks:

› Describe the new Data Layered Architecture (DLA) in the mobile

networks
› List the interfaces and protocols used in the UDC 11B
› Recognize the benefits of UDC 11B
› Discuss the new concepts related to the UDC solution
› List the HLR – FE node functions
› Check the CUDB node functions
› Illustrate the Provisioning Gateway functions
› Examine how signaling distribution function impacts in UDC

© Ericsson AB 2011 | Introduction | Figure 1-3

Business Scenario is Changing
Background

Create
Create business
business
growth
growth

networks
TV networks
networks

networks
Wireless networks

networks
Wireline networks

Data/IP networks
Service network
Manage
Manage network
network

Cable TV
evolution
evolution effectively
Wireless

Wireline

Data/IP
effectively Full Service Broadband
Cable

© Ericsson AB 2011 | Introduction | Figure 1-4

 Today’s Subscription Handling
› User data spread out across different Service Layer
Service Layer
databases and applications

› Different identities PCRF

Presence
HSS/SLF HLR/AuC AAA
– Different Data Models
Dev ice Mgt
Standard services / IMS

› Lack of controlled mechanism for 3PP

Multi Access Edge
to access subscriber profile
– Data inconsistency
– Data managed outside network Wireline access Wireless access

– Integration new application

› Domain-specific protocols
– MAP / LDAP / Diameter

Costly to maintain. Expensive to build and integrate

new applications and services (specially for large networks)

© Ericsson AB 2011 | Introduction | Figure 1-5

Architecture Evolution

AS AS AS AS AS
Telco Services Internet
Service Network

CUDB

GUP IdM
Telco Services
User Data Consolidation

EIR PGM HSS SAPC HLR AAA

IMS and communication enablers

Multi Access Edge

Fixed access Mobile access

Transport Network

Towards a standardized industry common architecture

© Ericsson AB 2011 | Introduction | Figure 1-6
Challenges for the Future

Difficult introduction of new services

Complex network architecture

Complex network administration

© Ericsson AB 2011 | Introduction | Figure 1-7

Consideration
› Difficult introduction of new services
– To reduce the logical complexity of the network is needed
– Make more business with the with the existing customer base

› Complex network architecture

– Reduce number of nodes
– Invest in future proof technology
– Phase out old technology

› Complex network administration

– Control of service provisioning
– Service/subscription lifecycle management

© Ericsson AB 2011 | Introduction | Figure 1-8

User Data Management Evolution

User
Centric

Service § Personalized services

Centric
§ Network and service
convergence

§ Pre-Full Service
Network Broadband architecture
Centric § Service convergence

§ Vertical Networks

© Ericsson AB 2011 | Introduction | Figure 1-9

Data Layered Architecture Values
Customer perceived

ü Centralized storage
• Storage administration effectiveness
OPEX • Optimized storage upgrade e.g. version control, change control
• Improved data availability
• Lower SW and HW maintenance cost
• Backup improvement
ü Simplified user &service provisioning
ü Easy access to end-user data

ü Optimized use of the network resources

CAPEX • Independent scalability of data storage and traffic
ü Low price HW

ü Easy integration of new applications and services

TTM • Simplified user &service provisioning
• Easy access to end-user data

Data ü Enhanced monitoring of subscriber behavior

• To customize and push services to the end users base on usage, habits,.
mining
© Ericsson AB 2011 | Introduction | Figure 1-10
What is User Data Consolidation?

UDC product offers any

combination of HLR/AUC,
MNP and HSS/SLF functions
both in monolithic and/or
data layered architecture

Operates 2G/3G/4G, IMS

(3GPP HSS) as well as
MNP simultaneously

© Ericsson AB 2011 | Introduction | Figure 1-11

Today’s Monolithic Architecture
Circuit Switch
Circuit Switch
& Packet Switch IMS,
& Packet Switch
Core Network IMS,EPC,EPC,
Core Network Networks
Networks
(MSC, IN, GGSN,
(MSC, IN, GGSN, (CSCF, MME,
IMS, EPC, AS,
GAN Networks
SGSN, etc.)
SGSN, etc.) (CSCF,(CSCF,MME, AS,
MME, AS, etc.)
etc.) .)
etc.).)

STP/SGW

FNR
Operational FNR SLF
Support HLR
System AuC
(OSS) HLR AuC
HSS
HSS

Customer
Admin
System
(CAS)

© Ericsson AB 2011 | Introduction | Figure 1-12

Data Layered Architecture (DLA)
Classic architecture User Data Consolidation

OSS BSS OSS BSS

Provisioning UDC 11B Provisioning

CUDB
User
data

User User User User

data data data data

Business Business Business Business Business Business Business Business

Logic Logic Logic Logic Logic Logic Logic Logic

HLR/AUC/MNP HSS Application Application HLR/AUC/MNP HSS Application Application

FE FE FE FE

Common database for multiple applications

© Ericsson AB 2011 | Introduction | Figure 1-13
Benefits of UDC
› Easy Launch of New Services
– All data in one DataBase with same structure
› Independent Scalability of Storage and Traffic Processing
Capacity
– HLR-FE
– CUDB
› Geographical Redundancy
– HLR POOL n+k
– 1+1+1 DSG
– Single Point of Data Access
› Lower expenses (Capex and Opex)

© Ericsson AB 2011 | Introduction | Figure 1-14

Benefits of UDC

Easy Management and Access to data

Efficient network handling – Opex savings

Optimized network infrastructure – Capex savings

Faster and cheaper new services deployment

© Ericsson AB 2011 | Introduction | Figure 1-15

Classical HLR/AUC/HSS and UDC Solution

Classic HLR/AuC
& HSS Node HSS
HLR/AuC

PG
CUDB
HLR/AuC/HSS node

OAM PROVISIONING
HLR/AuC/HSS DB
DataBase LOGIC

DB
OAM

LOGIC Ericsson evolved HLR/AuC

HLR/AuC/HSS Application
PROTOCOLS HLR FE

OAM
Classic HLR/AuC node LOGIC
Signaling &
PROTOCOLS
application logic
HSS
FE
© Ericsson AB 2011 | Introduction | Figure 1-16
 User Data Consolidation 11B
Solution details
Circuit Switch
& Packet Switch
Core Network
(MSC, IN, GGSN,
SGSN, etc.)
STPs
STPs

CAS

Provisioning HLR/AUC
HLR/AUC FEFE HSS/SLF - FE
Gateway HSS/SLF - FE
(including MNP) Application
layer

Operational
Support
System Processing Layer
Data
(OSS) layer
CUDB
Data
Store
Data
Store
… Data
Store

© Ericsson AB 2011 | Introduction | Figure 1-17

Network Applications
HLR FE

Circuit Switch
& Packet Switch
Core Network
Application (MSC, IN, GGSN,
SGSN, etc.)
FE STPs
STPs

• Provide Application Logic

• Stateless (any front end Provisioning
can serve any request, Gateway HLR FE HSS/SLF - FE
user data are not
retained)
• Serves single transaction
• Dynamically selected (any
FE may serve any
subscriber at any time)
• FE redundancy and Processing Layer
scalability handled by
additional FE’s (n+k
CUDB Data Store Data Store … Data Store
redundancy)

© Ericsson AB 2011 | Introduction | Figure 1-18

Provisioning Gateway (PG)
Circuit Switch
& Packet Switch
Provisioning Core Network
Gateway (MSC, IN, GGSN,
SGSN, etc.)
STPs
STPs
• Single point of provisioning
• Provisioning Orchestration
• Full CRUD support
• Data validation
• Application Notifications HSS/SLF –
• Data consistency PG HLR FE FE
• Bulk provisioning

• Provisioning Load
Distribution

• Application Notifications Processing Layer

• Easy to extend interfaces & Data Store Data Store … Data Store
orchestration logic by Plug- CUDB
in for protocols and logic
© Ericsson AB 2011 | Introduction | Figure 1-19
Data Layer
Processing Layer
Circuit Switch
& Packet Switch
Core Network
(MSC, IN, GGSN,
SGSN, etc.)
STPs
STPs

Data Layer
(Processing Layer)
HLR/AuC-FE HSS/SLF -
• Provides single point of PG HLR FE
MNP
HSS FE
FE
contact for data layer
• Hides the structure of the
data storage layer
• Locates appropriate data
store for the subscriber
data request Processing Layer

Data Store Data Store … Data Store

CUDB

© Ericsson AB 2011 | Introduction | Figure 1-20

Data Layer
Data Store
Circuit Switch
& Packet Switch
Core Network
(MSC, IN, GGSN,
SGSN, etc.)
STPs
STPs

HSS/SLF -
Data layer PG HLR FE
FE
(Data Store)

• Reliable data store

• Independent data bases
• High availability; and
geographic replication Processing Layer

Data Store Data Store … Data Store

CUDB

© Ericsson AB 2011 | Introduction | Figure 1-21

Subscriber Data
› Data Type:
– Subscriber data:
Example: Subscriber Identity (MSISDN, IMSI, Additional
MSISDNs, IMSI Changeover, IMEISV, LMSID), Service Stored in
Subscriptions (SUDs), Subscription Options (CAMEL, CF CUDB
Functions…), MNP (network prefix and subscriber type), IMS
Subscription, EPS Subscription, WLAN Subscription,…

– Service associated data: Stored in

Examples: CAMEL profiles, GPRS profiles, IMS Service Profile, CUDB

Subscriber profiles, Access Point Name, Bearer Capability data, Stored in

Extended QoS data, GMLC addresses, gsmSCF addresses… Front Ends

– Configuration data:
Examples: Application parameters, Area specific feature data,
Exchange properties, Own Calling address, Roaming area Stored in
characteristics… Front Ends

© Ericsson AB 2011 | Introduction | Figure 1-22

Data Model
› Data Model is how any kind of information is represented or organized
in a database repository.

› CUDB is built as LDAP directory FE (Lightweight Directory Access

Protocol)
– LDAP provides both read and update access.

› The LDAP uses the Directory Information Tree (DIT) concept to

arrange any information.

› Attributes names and its value form the Relative Distinguish Name
(RDN) of an object.

› Distinguish Name (DN). uniquely identifies an object inside the tree.

– RDNs of the sequence of entries from a particular object to the root entry of
the tree

© Ericsson AB 2011 | Introduction | Figure 1-23

UDC Data Model
Subscriber centric

System
Root
User
Branch

MSC Serv
Ident- Associa-
Subscr. Common Common
ities tions
data data

Ident1 Subscr.
(e.g. Ident2 Identity App1 App1
IMSI) (e.g. Common App2 Common App2
MSISDN) Profile Common Data Common
Profile Data

App1
Profile App2
(e.g. Profile
HLR) (e.g.
HSS)
© Ericsson AB 2011 | Introduction | Figure 1-24
Addition of New Application
Example

System
Root
User
Branch

MSC Serv
Ident- Associa-
Subscr. Common Common
ities tions
data data

Ident1 Subscr. MNP

(e.g. Ident2 Identity
IMPU IMSI) (e.g. CAMEL
MSISDN) Profile GPRS
IMPU IMS
Profile
Common
HLR Profile
Subs- AUC
cription Subs-
IMS
Data cription
Subs-
Data
cription
Data

© Ericsson AB 2011 | Introduction | Figure 1-25

UDC External Interfaces
Network Management

OSS CAS
M1 Prov1

IMS
CSCF EPC
AP Dzx
GMSC MME
XCAPS Cx ,Dx S6a
Zx GPRS
WLAN AS Sh ,Dh
UDC
MAP
Gi
G GSN
Wm, Wa C Gr SGSN
Access
Node IWMSC
Lh SMS MAP

GMLC C DCR
PPR SMS D MSC
GMSC CS1+
Mobile C C J
SCP
location
MG GMSC MSC gsmSSF gsmSCF
Mobile IN
GSM/UMTS CS
© Ericsson AB 2011 | Introduction | Figure 1-26
 UDC External Interfaces
› Customer Administration System ↔ UDC
– Customer Administration Interface defined for 3G (CAI3G)

› Signalling Network ↔ UDC

– MAP / INAP
– Diameter / RADIUS

› OAM Entity ↔ UDC

– SSH / SFTP / SNMP / HTTP

© Ericsson AB 2011 | Introduction | Figure 1-27

UDC 11B Internal Interfaces

Ud

JMX/RMI

HSSProv
Ud
HLRAuC
Prov Ud
NotifMobility

D', Gr' and J'

© Ericsson AB 2011 | Introduction | Figure 1-28

UDC 11B Internal Interfaces

› PG ↔ HLR-FE
– MML

› PG ↔ CUDB
– Lightweight Directory Access Protocol (LDAP)

› PG ↔ HSS/SLF FE
– Simple Object Access Protocol (SOAP)

› HLR FE ↔ CUDB
– LDAP
– SOAP (SAE Mobility Management ) (Optional)

› HSS/SLF FE ↔ CUDB
– LDAP

› HLR FE ↔ HSS/SLF FE
– MAP

© Ericsson AB 2011 | Introduction | Figure 1-29

Signaling Impact (I)
New Protocol in CN: LDAP

› What is LDAP?
– Lightweight Directory Access Protocol.
– The LDAP hierarchy has a tree structure.
– LDAP is a client-server based directory access protocol that
provides both read and update access.

› Characteristics of LDAP
– Uses TCP/IP instead of OSI stack
– Open standard by the Internet Engineering Task Force (IETF)
– Several LDAP implementations are available and freely distributed
(i.e. OpenLDAP)

© Ericsson AB 2011 | Introduction | Figure 1-30

Hierarchy LDAP -- What is directory?
› A directory is a specialized database, also called a data
repository, that stores ordered information about objects as a
hierarchical structure
› Examples: Phone book, Library catalog, Domain Name
Service (DNS) , Microsoft Active Directory
C=SE

O= Telia O=Ericsson

OU= products OU= people

CN= John Smith

© Ericsson AB 2011 | Introduction | Figure 1-31
LDAP Concepts and Architecture
› Data Model:
– Data Model is how any kind of information is represented or organized in a
database repository.

› Directory Data Structure

– Directory Information Tree (DIT).
› DIT is composed of entries that have one key attributes.
– Each attributes name, together with its value forms the Relative Distinguish
Name (RDN) of an entry.
– The concatenation of the RDNs found by walking up the tree to its root entry
forms the Distinguish Name (DN).
› This DN uniquely identifies an entry inside the tree.
– Each entry in the DIT may have one or more key attributes, and a set of
attributes, grouped in object classes, characterizing that entry.
› Object classes define what type of entries are possible in an LDAP
directory.
© Ericsson AB 2011 | Introduction | Figure 1-32
LDAP Server Configuration

LDAP Operations

LDAP TCP/IP LDAP

Client Server

HLR/AUC-S CUDB Directory

© Ericsson AB 2011 | Introduction | Figure 1-33

LDAP Operations (I)
› Authentication
– LDAP BIND
› Establish a client-server session

– LDAP UNBIND
› Close a client-server session

› Control
– LDAP ABANDON
› Abort an ongoing operation request

› Query
– LDAP SEARCH
› Read data from LDAP server

– LDAP COMPARE
› Verify data stored in the LDAP server

© Ericsson AB 2011 | Introduction | Figure 1-34

LDAP Operations (II)

› Update
– LDAP ADD
› Create a directory entry

– LDAP DELETE
› Remove a directory entry

– LDAP MODIFY
› Add/delete/modify attributes

– LDAP MODIFY DN
› To change the Relative Distinguished Name (RDN) of an entry
and/or to move a subtree of entries to a new location in the
Directory

© Ericsson AB 2011 | Introduction | Figure 1-35

Security
› No Authentication
– Leave the password and DN field empty in the bind API
call
– LDAP FE automatically assumes an anonymous user
session

› Basic Authentication
– Client identifies itself by a DN and a password
– LDAP FE considers the client authenticated if the DN
and password matches what stored in the directory.
– Grants access with the appropriate access controls.

© Ericsson AB 2011 | Introduction | Figure 1-36

LDAP Concepts and Architecture (II)
HLR-FE LDAP Example

RootDSE
RDN * Additional MSISDN
Aliases
DN
dc=<CUDBrootEntry
RDN >

ou=multiSCs Ou=servCommonData

ou=identities ou=associations ou=mscCommonData

0-n serv=CSPS serv=CSPS

RDN 0-n
dc=msisdn assocId=id
(multiple subscription) dc=secMsisdn dc=msisdn
(normal subscription) Ou=PRP

dc=imsi mscld=id serv=CSPS

msisdn *msisdn
msisdn msisdn ou=gprsProfiles ou=camelProfiles
1-n
imsi serv=CSPS ccid
0-n 0-n
serv=CSPS pdpcp csp

ei=gprs ei=camel

RDN
DN: "serv=CSPS, MSISDN=<MSISDNnumber>, dc=msisdn, ou =identities, dc=<CUDB root entry>"
© Ericsson AB 2011 | Introduction | Figure 1-37
SS7 Signaling Distribution
› The SD function is a mandatory function of the UDC
solution
› Distributing request to a specific available HLR FE.
– In STP / SRP / MSC

› Initial messages from CN nodes can be distributed towards

any available HLR FE
› The same HLR FE is used for the subsequent requests

› At the SCCP level each HLR FE has its own E.164 Global
Title
› At the MTP/M3UA level each HLR FE has its own Signaling
Point Code
© Ericsson AB 2011 | Introduction | Figure 1-38
Signaling Impact (II)
Core Network to HLR-FE’s

HLR-FE “pool”

CN
node
SD
function
HLR FE 1 HLR FE 2 … HLR-FE N
1. New MAP operation
SPC-1 SPC-2 SPC-N
IMSI GT-1 GT-2 GT-N
MISDN
HLR number

2. SD function selects an available

HLR FE from the “pool” (In this case
HLR FE 2
3. New MAP operation

4. HLR-FE 2 Global Title (GT-2) included in CgPA at

SCCP level

5. MAP operation Response (GT-2 as SCCP CgPA)

6. MAP operation Continuation (GT-2 as SCCP CdPA)

7. MAP operation Termination (GT-2 as SCCP CgPA)

© Ericsson AB 2011 | Introduction | Figure 1-39

 Scenario A: Example of Configuration
SCCP GTT MSC/VLR
ADDRESSING DEST 1 LSH TERM HLR-FE HLR-FE HLR-fE HLR-FE
VLR Address 1 2-310 No Yes 1 2 3 4
VLR Address 2 2-320 No Yes
VLR Address 3 2-330 No Yes
SGSN Address 1 2-410 No Yes GT=GT-HLRS1 GT=GT-HLRS2 GT=GT-HLRS3 GT=GT-HLRS3
SPC=2-110 SPC=2-120 SPC=2-130 SPC=2-140
SGSN Address 2 2-420 No Yes

MTP3/M3UA HLR-Servers
DEST Route 1 Route 2 LSH
This traffic could also 2-310 2-100 2-200 Yes
be routed directly to 2-320 2-100 2-200 Yes
CN nodes at
MTP/M3UA level 2-330 2-100 2-200 Yes
2-410 2-100 2-200 Yes
2-420 2-100 2-200 Yes SCCP GTT SRP
ADDRESSING DEST 1 DEST 2 DEST 3 DEST 4 LSH TERM
IMSI Series
MSISDN Series 2-110 2-120 2-130 2-140 Yes Yes
SCCP GTT MSC/VLR
HLR Number
ADDRESSING DEST 1 DEST 2 LSH TERM
SRP SRP
IMSI Series
SPC=2-100 SPC=2-200
MSISDN Series 2-100 2-200 Yes No
HLR Number
GT - HLRS1 2-110 - No No MTP3/M3UA STP
GT - HLRS2 2-120 - No No DEST Route 1 LSH
GT - HLRS3 2-130 - No No
2-110 2-110 No
GT - HLRS4 2-140 - No No
2-120 2-120 No
Core Network
MTP3/M3UA MSC/VLR
DEST Route 1 Route 2 LSH 2-130 2-130 No
2-100 2-100 2-200 No
2-200 2-200 2-100 No
2-140 2-140 No
2-110 2-100 2-200 Yes 2-310 2-310 No
2-120 2-100 2-200 Yes
2-130 2-100 2-200 Yes 2-320 2-320 No
2-140 2-100 2-200 Yes
2-330 2-330 No
2-410 2-410 No
This traffic could also 2-420 2-420 No
be routed directly to
HLR-FE at MSC/VLR SGSN MSC/VLR SGSN
MTP/M3UA level MSC/VLR VLR Address 2 SGSN Address 1 VLR Address 3 SGSN Address 2
VLR Address 1 SPC=2-320 SPC=2-410 SPC=2-330 SPC=2-420
SPC=2-310

© Ericsson AB 2011 | Introduction | Figure 1-40

 Scenario B: Example of Configuration
SCCP GTT MSC/VLR
ADDRESSING DEST 1 LSH TERM
VLR Address 1 2-310 No Yes HLR-FE HLR-FE HLR-FE HLR-FE
VLR Address 2 2-320 No Yes 1 2 3 4
VLR Address 3 2-330 No Yes
SGSN Address 1 2-410 No Yes GT=GT-HLRS1 GT=GT-HLRS2 GT=GT-HLRS3 GT=GT-HLRS4
SPC=2-110 SPC=2-120 SPC=2-130 SPC=2-140
SGSN Address 2 2-420 No Yes SPC=2-300 SPC=2-300 SPC=2-300 SPC=2-300

MTP3/M3UA HLR-Servers
DEST Route 1 Route 2 LSH
This traffic 2-310 2-100 2-200 Yes
could also be
2-320 2-100 2-200 Yes
routed directly
2-330 2-100 2-200 Yes MTP3/M3UA STP
to VLR/SGSN
2-410 2-100 2-200 Yes DEST Route 1 Route 2 Route 3 Route 4 LSH
(not through
STP) SCCP GTT MSC/VLR 2-300 2-110 2-120 2-130 2-140 Yes
2-420 2-100 2-200 Yes
ADDRESSING DEST 1 TERM 2-110 2-110 - - - No
2-120 2-120 - - - No
IMSI Series 2-130 2-130 - - - No
MSISDN Series
HLR Number
2-300 Yes STP STP 2-140 2-140 - - - No
SPC=2-100 SPC=2-200 2-310 2-310 - - - No
GT - HLRS1 2-110 Yes 2-320 2-320 - - - No
GT - HLRS2 2-120 Yes 2-330 2-330 - - - No
GT - HLRS3 2-130 Yes 2-410 2-410 - - - No
GT - HLRS4 2-140 Yes 2-420 2-420 - - - No

Core Network
MTP3/M3UA MSC/VLR
DEST Route 1 Route 2 LSH
2-300 2-100 2-200 Yes
2-110 2-100 2-200 Yes
2-120 2-100 2-200 Yes
This traffic 2-130 2-100 2-200 Yes
could also be 2-140 2-100 2-200 Yes
routed
directly to
HLR-Fe (not MSC/VLR SGSN MSC/VLR SGSN
MSC/VLR
through STP) VLR Address 2 SGSN Address 1 VLR Address 3 SGSN Address 2
VLR Address 1 SPC=2-320 SPC=2-410 SPC=2-330 SPC=2-420
SPC=2-310

© Ericsson AB 2011 | Introduction | Figure 1-41

Location Update
Signaling Example

MSC MSC SD
UE HLR FE CUDB
(new) (old) (STP)
LU request LU request LU request
LDAP Search (IMSI)

LDAP Search Result

ISD
ISD Rsp
LDAP Modify (MSISDN)

LDAP Modify Result

LU rsp
LU rsp
LU rsp

Cancel Loc Cancel Loc

Cancel Loc rsp
Cancel Loc rsp

© Ericsson AB 2011 | Introduction | Figure 1-42

Terminating Call
Signaling Example

SD HLR
GMSC VLR CUDB
(STP) FE

SRI
SRI

LDAP Search (MSISDN)

LDAP Search Result

PRN

PRN rsp

SRI rsp

© Ericsson AB 2011 | Introduction | Figure 1-43

Redundancy in All Layers
Circuit Switch & Packet Switch Core Network
(MSC, IN, GGSN, SGSN, etc.)

STP STP
1+1 Signalling Redundancy
STP STP

HLR/AUC HSS/SLF
FE FE
Multiple Site HLR FE and HSS/SLF FE
HLR/AUC HSS/SLF to minimize site failures effects.
FE FE
HLR/AUC HSS/SLF N+K Redundancy
FE FE

replication replication
PL-cluster PL-cluster PL-cluster replication PL-cluster CUDB assures Data
replication
consistency.
DS-cluster DS-cluster replicationDS-cluster
1+1+(1) Redundancy
replication replicationDS-cluster
DS-cluster DS-cluster

DS-cluster replication DS-cluster replication DS-cluster

This solution provides
DS-cluster replicationDS-cluster replicationDS-cluster
high disaster resilience
Site #1 Site #2 Site #3 Site #4

© Ericsson AB 2011 | Introduction | Figure 1-44