Content for TS 23.335 Word version: 17.0.0
0 Introduction
1 Scope
2 References
3 Definitions, symbols and abbreviations
3.1 Definitions
3.2 Symbols
3.3 Abbreviations
...
...
0 Introduction p. 5
The UDC concept (TS 22.101) supports a layered architecture, separating the data from the application logic in the 3GPP system, so that user data is stored in a logically unique repository allowing access from core and service layer entities, named Application Front Ends.
Network elements and functionalities should be designed to access user data remotely and without storing them permanently locally, i.e. the Front Ends shall work in a subscriber dateless configuration.
1 Scope p. 5
The present document describes the procedures and signalling flows associated to the technical realization of the 3GPP User Data Convergence (UDC). It furthermore indicates some requirements for the stage 3 specifications.
Special consideration is put in the following areas:
- reference architecture for the UDC concept
- general description of procedures for the user data manipulation (e.g. create, delete, update, etc.)
- identification of the requirements on the UDC for the applicability of the mechanisms described in this document.
2 References p. 5
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TR 22.985: "Service requirement for the User Data Convergence (UDC)".
[3]
TS 22.101: "Service aspects; Service principles".
[4]
TS 29.002: "Mobile Application Part (MAP) specification".
[5]
TS 23.002: "Network architecture".
[6]
TS 32.182: "User Data Convergence (UDC); Common Baseline Information Model (CBIM)".
[7]
TS 33.210: "3G Security; Network Domain Security; IP network layer security".
[8]
TS 32.181: "Telecommunication management; User Data Convergence (UDC); Framework for Model Handling and Management".
[9] Void.
[10]
TS 23.280: "Common functional architecture to support mission critical services".
3 Definitions, symbols and abbreviations p. 6
3.1 Definitions p. 6
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
Front End:
a core network functional entity or service layer entity or provisioning entity that can access user data stored in a unique repository.
Front End Identifier:
A name that uniquely identifies an FE within the set of all FEs accessing an UDR.
Front End Cluster:
FEs handling the same application may be grouped in clusters to differentiate between them e.g. with regard to geographical location, feature support, vendor, or other characteristics. All FEs within a cluster are treated equally for required purposes (e.g. authorization, notifications, etc.).
Application type:
The application handled by a FE (e.g. HLR) determines the application type of the FE. The application type is derived from the name indicated by a FE.
Front End Cluster Identifier:
A name that identifies a cluster grouped with FEs supporting the same application.
User Data Repository:
facility where user data can be accessed stored and managed in a common way.
Transaction:
a transaction is a sequence of operations towards the User Data Repository (one or several), performed as a single logical unit of work. A logical unit of work must exhibit four properties, called the ACID (Atomicity, Consistency, Isolation, and Durability) properties, to qualify as a transaction.
A transaction usually consists of the following steps, start transaction, making updates, and end of transaction; the transaction can finish successfully, in that case it is said the updated data is committed, or unsuccessfully, in that case the transaction is cancelled and the updates made till that moment are rolled back so that the data remains as it were before the transaction.
Atomicity:
a transaction must be an atomic unit of work; either all of its data modifications are performed or none of them is performed.
Consistency:
when completed, a transaction must leave all data in a consistent state. In the User Data Repository, all rules must be applied to the transaction's modifications to maintain all data integrity. All internal data structures must be correct at the end of the transaction.
Isolation:
modifications made by concurrent transactions must be isolated from the modifications made by any other concurrent transactions. A transaction either sees data in the state it was in before another concurrent transaction modified it, or it sees the data after the second transaction has completed, but it does not see an intermediate state. This is referred to as serialization because it results in the ability to reload the starting data and replay a series of transactions to end up with the data in the same state it was in after the original transactions were performed.
Durability:
after a transaction has completed, its effects are permanently in place in the User Data Repository. The modifications persist even in the event of a system failure.
3.2 Symbols p. 7
For the purposes of the present document, the following symbols apply:
Ud
reference point between a FE and the UDR
3.3 Abbreviations p. 7
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
FE
Front End
UDC
User Data Convergence
UDR
User Data Repository
