Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.335  Word version:  17.0.0

Top   Top   Up   Prev   None
0…   4…   5…   A…   A.4…   B…

 

B  Applicability of the UDC concept to network nodesp. 34

B.1  Introductionp. 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 Prerequisitep. 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.
Up

B.3  Step 1 - Separating User Data from Application Logicp. 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:
Copy of original 3GPP image for 3GPP TS 23.335, Fig. B.3.1-1: Separating User Data from Application Logic
Up
However, separating user data from application logic without any additional steps does not provide much benefit (if any).

B.4  Step 2 - Introducing Provisioning FEsp. 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.
Copy of original 3GPP image for 3GPP TS 23.335, Fig. B.4.1-1: Introducing Provisioning FEs
Figure B.4.1-1: Introducing Provisioning FEs
(⇒ copy of original 3GPP image)
Up
Again, this step alone does not provide much benefit.

B.5  Step 3 - Storing outsourced user data in a logically single UDRp. 35

This step is an essential part of the UDC concept. The outsourced user data are stored in a logically unique UDR:
Copy of original 3GPP image for 3GPP TS 23.335, Fig. B.5.1-1: Storing outsourced user data in a logically single UDR
Up
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.
Copy of original 3GPP image for 3GPP TS 23.335, Fig. B.5.1-2: Storing outsourced user data in a logically single UDR
Up

B.6  Step 4 -Full Load Sharing and Failover functionalityp. 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.
Copy of original 3GPP image for 3GPP TS 23.335, Fig. B.6.1-1: Full Load Sharing and Failover functionality
Up
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 UDRp. 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:
Copy of original 3GPP image for 3GPP TS 23.335, Fig. B.7.1-1: Converging user data in the UDR
Figure B.7.1-1: Converging user data in the UDR
(⇒ copy of original 3GPP image)
Up
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 HLRp. 37

1)
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.
Step 4 is applicable.
In summary all steps are applicable and provide the full benefits of the UDC concept.
Up

B.9  Example analysis for S-CSCFp. 37

1)
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.
Step 4 is not applicable.
In summary the applicable steps (1 and 3) do not provide any benefit.
Up

B.10  Example analysis for PCRF and SPRp. 38

1)
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.
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.
Up

B.11  Summaryp. 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 historyp. 39


Up   Top