Contents
1 Introduction
This document provides a description of the multiple geographical areas optional feature in Centralized User Database (CUDB).
1.1 Scope
The purpose of this document is to describe the multiple geographical areas optional feature in CUDB.
1.2 Revision Information
| Rev.A | This document is based on 13/155 34-HDA
104 03/6 with the following changes:
| |
1.3 Target Groups
This document is intended for system administrators and users working with the multiple geographical areas.
1.4 Prerequisites
The Multiple Geographical Areas feature can only be used if the Deployment Flexibility Value Package is available.
1.5 Typographic Conventions
Typographic conventions can be found in the following document:
2 Overview
The geographical area concept is an optional feature that implies tailored data distribution to reduce the required bandwidth across geographically separated locations by ad-hoc distribution of subscriber data.
2.1 Prerequisites
This section is not applicable to this feature.
2.2 Architecture
Figure 1 shows the distribution of subscriber data based on the zone concept.
- Note:
- It is important that Figure 1 shows a CUDB system in double geographical redundancy configuration. Another configuration can be Triple.
Individual subscribers can be allocated to one of the multiple areas, reducing data flow among those areas. Zones have independent storage resource management. When a subscriber profile is created, the subscriber is allocated to a home zone. When the subscriber profile is accessed, it is usually done from the zone where the subscriber was allocated to. This helps to keep the traffic locally in the network. In case of mobility (for example, the subscriber moves to other part of the country) the subscriber data can be still transparently accessed.
2.3 Description
This section describes the functions of the multiple geographical areas optional feature in detail.
2.3.1 Defining Zones
As multiple geographical areas is an optional feature, zone assignment can be skipped in provisioning time. It is assumed that all of the nodes belong to an implicit zone if this optional feature is decided to be applied. After the activation, new areas can be defined but the already created nodes belong to the implicit one.
After activating the feature, it is not possible to rollback. The zone policy is applied in any provisioning operation. A default zone can be defined when the feature is applied to use when no zone is provided during the provisioning.
The zone information in the subscriber data must be used with care in filters to retrieve subscriber information stored in a given zone because if the zone was not provisioned or it was modified after the provisioning operation, the results of the query can be misleading.
As a default configuration, zoneId is the parameter taken in order to determine which zone is going to be used. In case zoneId is not defined but the defaultZone is, the defaultZone parameter is considered as the zone to be used. Otherwise, when neither zoneId nor defaultZone are defined, the implicit zone is the default value of zoneId.
2.3.2 Provisioning with Zones
A home zone for the subscriber can be specified at its provisioning time. If the zone is not specified and a default zone is defined in the system, the subscriber is stored in the default zone. If no default zone is configured, CUDB can automatically choose the zone where to store the subscriber from the configured zones, plus the implicit zone. This means that a subscriber always belongs to a zone (to any of the configured zones or to the implicit zone) irrespective of whether the subscriber was assigned to a particular zone at provisioning time or CUDB automatically chose the zone where to store it.
Provisioning a subscriber in a zone means that the system selects a node which belongs to that zone, and stores the subscriber there if there is enough free space.
When provisioning a subscriber the following error situations can occur regarding this feature:
- The specified zone is not defined in the CUDB System. So there is no node that belongs to that zone. The provisioning request is rejected and the corresponding event is logged.
- There is not enough space in the specified zone. The provisioning request is rejected even if extra space is available in a different zone. The corresponding event is logged.
For more information about the protocol, refer to CUDB LDAP Interwork Description, Reference [1].
For more information about logged events, refer to CUDB Data Distribution, Reference [2].
2.3.3 Zone Management Considerations
The following rules must be considered about zone management:
- A node belongs to only one zone.
- There are no limitations in the number of zones that can be defined in the CUDB system.
- moving a node between zones is not supported, a node must remain in the zone assigned to it at the node creation.
- Once a zone is defined, it can not be removed.
- Once a default zone is defined, it is possible to change it, but it can not be removed.
- A zone contains all of the resources for subscribers
stored in such zone. For example, entire DS group (both master and
slave DS included). If a CUDB Node is assigned to an existing zone,
all the CUDB Nodes containing the rest of replicas for the DS Groups
in the original CUDB Node, must belong to the same zone.
- Note:
- This rule is relevant only if the geographical redundancy configuration is double or triple.
For more information about zone management procedures, see Section 3.
2.4 Dependencies and Interactions
This section is not applicable to this feature.
3 Operation and Maintenance
This section provides operation and maintenance information of the multiple geographical areas feature.
3.1 Configuration
The operation and maintenance procedures required by this feature are the following:
- Define a default zone. For more information, refer to CUDB Node Configuration Data Model Description, Reference [3].
- Add a zone to the CUDB system with node addition procedure. The node belongs to a non-existing zone. For more information, refer to CUDB System Administrator Guide, Reference [4].
- Note:
- Configuration changes related to these procedures are rejected if the Deployment Flexibility Value Package is not available.
3.2 Fault Management
This section is not applicable to this feature.
3.3 Performance Management
This section is not applicable to this feature.
3.4 Security
This section is not applicable to this feature.
3.5 Logging
Log events are detailed in CUDB Data Distribution, Reference [2].
Glossary
For the terms, definitions, acronyms and abbreviations used in this document, refer to CUDB Glossary of Terms and Acronyms, Reference [5].
Reference List
| CUDB Documents |
|---|
| [1] CUDB LDAP Interwork Description. |
| [2] CUDB Data Distribution. |
| [3] CUDB Node Configuration Data Model Description. |
| [4] CUDB System Administrator Guide. |
| [5] CUDB Glossary of Terms and Acronyms. |