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.
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:
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.
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.
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.
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.
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