Content for TS 23.335 Word version: 18.0.0
B Applicability of the UDC concept to network nodes
B.1 Introduction
B.2 Basic Prerequisite
B.3 Step 1 - Separating User Data from Application Logic
B.4 Step 2 - Introducing Provisioning FEs
B.5 Step 3 - Storing outsourced user data in a logically single UDR
B.6 Step 4 -Full Load Sharing and Failover functionality
B.7 Step 5 - Converging user data in the UDR
B.8 Example analysis for HLR
B.9 Example analysis for S-CSCF
B.10 Example analysis for PCRF and SPR
B.11 Summary
$ Change history
B Applicability of the UDC concept to network nodes p. 34
B.1 Introduction p. 34
This informative annex outlines a step by step approach which aims to help clarifying whether a given network node is applicable to the UDC concept.
B.2 Basic Prerequisite p. 34
A fundamental concept of UDC is to separate a network node's user data from a network node's application logic.
It is understood that a network node's application logic is running in sessions, which last for a limited duration. During a session the application logic makes use of user data, i.e. user data cannot be separated from the application logic while a session is ongoing. Only when no session is ongoing user data can be separated from the application logic.
Consequently, Network Nodes that (in non-UDC networks) do not store user data (while no session is ongoing), are not applicable to the UDC concept.
Furthermore, Network Nodes that (in non-UDC networks) do not perform application logic (i.e. pure data bases), are not applicable to the UDC concept.
B.3 Step 1 - Separating User Data from Application Logic p. 34
In principle, any network node (in non-UDC networks) that stores user data while no session is ongoing and that performs application logic is a candidate for separation of user data and application logic:
However, separating user data from application logic without any additional steps does not provide much benefit (if any).
B.4 Step 2 - Introducing Provisioning FEs p. 35
If part of the candidate node's user data is permanent data which is applicable to provisioning at that node, provisioning-application logic could also be separated from the node's application logic.
Again, this step alone does not provide much benefit.
B.5 Step 3 - Storing outsourced user data in a logically single UDR p. 35
This step is an essential part of the UDC concept. The outsourced user data are stored in a logically unique UDR:
Figure B.5.1-1: Storing outsourced user data in a logically single UDR
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
One of the benefits of this step is that e.g. Provisioning FE 2 could not only access via Ud those user data which were separated from the application logic in Node-FE 2, but also those user data that were separated from the application logic in Node-FE 1.
Figure B.5.1-2: Storing outsourced user data in a logically single UDR
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
B.6 Step 4 -Full Load Sharing and Failover functionality p. 36
What is said for the provisioning FEs in step 3, in theory also holds for other node-FEs: Node-FE 2 could access via Ud not only its own outsourced data, but also data sourced out by Node-FE 1. However, careful analysis is needed before deciding the cases in which "cross data accessibility" should be allowed. The main point to consider is whether or not parallel sessions in different FEs result in problems.
If routing mechanisms used on the network interfaces allow configuration of alternative routes to address e.g. load sharing, link loss or node outage, and parallel sessions in different FEs are not regarded a problem, FEs of the same application type could share load or could take over in cases of node-FE outage.
This step does not impact FE or UDR implementation but is a routing configuration issue outside the UDC. Furthermore, this step - although it provides great advantages - is believed not to be essential to the UDC concept. Deployments may or may not take advantage of this step if applicable. Non-applicability of this step is not a knock-out criterion for the decision on applicability of the UDC concept for a given node.
B.7 Step 5 - Converging user data in the UDR p. 37
It is believed to be beneficial when the user data outsourced by several nodes are not stored separated within the UDR but are somehow converged:
This step is purely UDR internal and therefore out of scope of CT4 standards, and not further looked at in this annex.
B.8 Example analysis for HLR p. 37
1)
Step 4 is applicable.
In summary all steps are applicable and provide the full benefits of the UDC concept.
An HLR (in non-UDC Networks) stores user data (while no session is ongoing) and performs application logic, therefore step 1 is applicable.
2)
An HLR (in non-UDC Networks) stores permanent user data provisioned at the HLR, therefore step 2 is applicable.
3)
Outsourced HLR user data may be stored in a common UDR to allow access from any Provisioning-FE connected to the UDR. Step 3 is applicable.
4)
Parallel sessions in two different HLR-FEs: It is believed that e.g. one HLR-FE could process a MAP-SendRoutingInfoForSM message while another HLR-FE processes a MAP-AnyTimeInterrogation message for the same user at the same time. This in general holds for all HLR-FE session initiating messages. Furthermore the duration of an HLR-FE session in general is in the range of seconds or minutes rather than hours or days. The transaction mechanism supported on the Ud interface is suitable to address data synchronization.
B.9 Example analysis for S-CSCF p. 37
1)
Step 4 is not applicable.
In summary the applicable steps (1 and 3) do not provide any benefit.
An S-CSCF (in non-UDC Networks) stores (or may store) user data (while no session is ongoing i.e. no SCSCF-application logic is running) and performs application logic, therefore step 1 is applicable.
2)
An S-CSCF (in non-UDC Networks) does not store permanent user data provisioned at the S-CSCF, therefore step 2 is not applicable.
3)
Outsourced S-CSCF user data may be stored in a common UDR, but access from Provisioning FEs is not applicable. Step 3 is applicable, but does not provide any benefit.
4)
Parallel sessions in two different S-CSCF-FEs may be regarded a challenge.
B.10 Example analysis for PCRF and SPR p. 38
1)
Step 4 may not applicable.
In summary steps 1, 2, and 3 are applicable and provide some benefits. Applicability of step 4 may provide further benefits but it is for further study.
A PCRF (in non-UDC Networks) does not store user data (while no session is ongoing); on the other hand an SPR does not perform application logic. It seems that the concept of separating application logic from user data (see step 1) is already in place.
2)
Also step 2 (direct provisioning of user data in the SPR rather than via PCRF) seems to be already in place.
3)
Also step 3 (combining several SPRs to a logically unique database) is applicable.
4)
Parallel sessions in two different PCRFs needs further study.
B.11 Summary p. 38
Any network entity that performs application logic (in sessions which are limited in duration) and that stores user data (during the time where no session is running) is in principle applicable to the UDC concept. However some nodes may not fully benefit from the UDC concept, especially if
- permanent user data stored at the node - in a non UDC network - is not provisioned at that node
- parallel sessions for the same user at the same time cannot run independently
$ Change history p. 39
