In the architecture, the User Data Repository (UDR) is a functional entity that acts as a single logical repository of user data and is unique from Application Front End’s perspective.

M

C

Application Front Ends connect to the UDR through the reference point named Ud to access user data.

M

C

Through the reference point, an Application Front End shall only interface with the UDR for the data relevant to its function, and not be impacted by other data that UDR stores for other applications.

M

C

The user data that an Application Front End accesses in the UDR through the reference point Ud shall comply with an agreed data structure between the Application Front End and the UDR.

M

C

The application logic in a Front End is performed during an FE-Session. An FE-Session starts either with the receipt of a request message on one of the supported interfaces from the UE, Core Network, service Layer or OSS, or with receipt of a notification message on the Ud interface from the UDR.

M

PC

SAPC session starts at IP-CAN session establishment (CCR-Initial). Receipt of notification does not start an FE session

Before an FE-Session starts, the FE does not have any user data stored.

M

C

During an FE-Session the FE:

- may (depending on the application logic) read user data from the UDR and store them temporarily locally;

- may (depending on the application logic) write user data to the UDR;

- may (depending on the application logic) communicate with entities of the Network or Service Layer or OSS on supported interfaces;

Op

C

The SAPC does not store temporarily locally data read from the UDR, that is, UDR is accessed at each request received.

During an FE-Session the FE:

- shall delete all temporarily locally stored user data when the FE-Session is completed.

M

C

After completion of an FE-Session, the FE does not have any user data stored and the FE does not maintain any state information. A subsequent FE-Session for the same user triggered by a new request message on one of the supported interfaces from the UE, Core Network, service Layer or OSS, or a new notification message on the Ud interface from the UDR may be performed by a different FE.

M

C

The SAPC session ends at IP-CAN session termination (CCR-Termination).

While the FE session duration may vary (depending on the application logic), means should be provided by the different FEs (e.g. storing temporary data in the UDR to be shared by other FEs) so that any request may be handled by any FE at any given time.

Op

PC

The SAPC session duration is equal to IP CAN session duration. Whereas an IP-CAN session can be initiated towards any SAPC, subsequent requests within a session must be handled by the same SAPC.

1. The FE receives an initial request on one of the supported interfaces from UE, Core Network, Service Layer or OSS.

2. When receiving an initial request message, the FE may read user data from the UDR.

3. The FE shall store the read user data (if any) as a temporary local copy and use it when performing its application logic. There may be applications that do not need to retrieve and store user data from the UDR in order to perform the application logic.

4. The FE performs its application logic.

4a. As part of performing the application logic, the FE shall continue and complete the communication with the UE, Core Network, Service Layer or OSS. This may include sending messages to and receiving messages from entities within the UE, Core Network, Service Layer or OSS other than the entity that sent the initial request.

4b. As part of performing the application logic, the FE shall access user data in the UDR if so required by the application. This may happen more often than once. Steps 4a and 4b may be performed in any order of sequence.

5. After application logic is completed, the FE shall delete its temporary local copy of user data.

6. The UDR shall send a notification message to an appropriate FE if the data modified in step 4b are subscribed data for notification. The notification message shall include user data. More than one notification messages are sent if the modified data are subscribed more often than once.

7. The FE shall store the received user data as a temporary local copy and use it when performing its application logic.

8. The FE performs its application logic.

8a. As part of performing the application logic, the FE shall communicate with the UE, Core Network, Service Layer or OSS if so required by the application.

8b. As part of performing the application logic, the FE shall access user data in the UDR if so required by the application. This may happen more often than once. Steps 8a and 8b may be performed in any order of sequence

NOTE: In the UDR step 8b may result in another notification message being sent to an appropriate FE, which is not shown in the figure.

9. After application logic is completed, the FE shall send a notify acknowledgement to the UDR. Depending on the application the notify acknowledgement may be sent earlier, e.g. immediately after step 6.

10. After application logic is completed, the FE shall delete its temporary local copy of user data.

M

PC

Step 10 is not done. The SAPC session is equal to IP-CAN session, so the data is kept during the session duration.

1. It shall be possible for an authorized Front End to read relevant user data stored in the UDR.

M

C

2. It shall be possible for an authorized Front End to modify (i.e. create, update, and delete) relevant user data stored in the UDR.

M

PC

The creation and deletion of SAPC Subscribers is performed by the Provisioning System.

7. A group of Front Ends (or a single Front End) for a specific application type shall be distinguished by a unique Front End cluster identifier.

M

C

When an application FE - during processing of its application logic - needs to retrieve user data from the UDR it shall issue a Query data request message and send it over the Ud reference point to the UDR. The message shall contain:

- the FE Identifier or the FE Cluster Identifier

- the user identity an identity of the user, e.g. IMSI, MSISDN, IMS public user identity, IMS private user identity

- the requested data the identification of the data of which the value is requested Data identification and structure shall comply with the requesting FE's data view

M

C

When an application FE - during processing of its application logic - needs to insert new user data in the UDR, e.g. open a new user account in the database, it shall issue a Create Data Request message and send it over the Ud reference point to the UDR. The message shall contain:

- the FE Identifier or the FE Cluster Identifier - the user identity an identity of the user, e.g. IMSI, MSISDN, IMS public user identity, IMS private user identity

- the identification of data to be inserted

- the new data value

M

C

When an application FE - during processing of its application logic - needs to update user data in the UDR it shall issue an Update data request message and send it over the Ud reference point to the UDR. The message shall contain:

- the FE Identifier or the FE Cluster Identifier - the user identity an identity of the user, e.g. IMSI, MSISDN, IMS public user identity, IMS private user identity

- the requested data the identification of the data of which the value is to be updated

- the new data value value of the data that is to be written in the UDR

M

C

The message may contain:

- the update condition, if supported by the UDR

Op

NC