6 UDC information model handling

32.1813GPPFramework for Model Handling and ManagementRelease 17Telecommunication managementTSUser Data Convergence (UDC)

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 General

The relations of the UDC information models are depicted in Figure 6.1-1 below.

Common Baseline IM (CBIM)

Specialized IM (SpIM)

Appl IM (AIM)

Customise to Operator’s Services

Integrate AIM into SpIM and consolidate

Fig. 6.1-1 UDC Information Models

Figure 6.1-2 below shows the process that leads to integrating and consolidating data for a given operator from the UDR perspective.

Initially the Common Baseline Information Model (CBIM) is specialised according to the service and user structure of the given operator resulting in the initial version of the operator’s the Specialized Information Model (SpIM).

The actual version of the operator’s Specialized Information Model (SpIM)) is combined together with one or more Application Information Models (AIMs) to form a new version of the Specialized Information Model (SpIM) of the operator. The SpIM represents and considers all the data of all converged services offered by the operator.

It is the decision of the operator, when a new actual version of the SpIM is implemented into the UDR. An implementation of the actual version of the SpIM into the UDR leads to the Consolidated Data Model (CDM), which is representing the actual implementation of the UDR.

Common Baseline IM (CBIM)

Specialized IM (SpIM)

Consolidated Data Model (CDM)

Appl IM (AIM)

Figure 6.1-2: UDC Information and Data Models in the UDR

Consider now integration for a given application. An Application Data Model (ADM) has to be developed both for the UDR and for the Application/Front-End to be used on the Ud interface.

In the integrated model handling environment under responsibility of the operator implementation of the SpIM and the AIM of the application leads to the Application Data Model (ADM), this is depicted in Figure 6.1-3. The ADM gets implemented in the application FE and in the Application Data Model View in the UDR.

Common Baseline IM (CBIM)

Specialized IM (SpIM)

Application Data Model

(ADM)

Appl IM (AIM)

Figure 6.1-3: UDC Information and Data Model handling for an Application Type in an integrated Operator environment

In the case of separate development of the Application Data Model (ADM) for an application on the Application/Front-End side, implementation of the CBIM and the AIM of the application leads to the ADM being implemented there. This is depicted in Figure 6.1-4.

Common Baseline IM (CBIM)

Application Data Model

(ADM)

Appl IM (AIM)

Figure 6.1-4: Separate Information and Data Model handling for an Application Type for Application Front-End

6.2 Initial SpIM Creation from CBIM

The Specialized Information Model is initially generated through operator specific specialisation of CBIM e.g. through definition of the operator-specific End-User groupings.

6.3 AIM Integration into SpIM

After the initial SpIM has been created, AIMs are imported and consolidated into it. The SpIM takes into account the specific applications, the functionality included and the relevant business information.

6.4 Consolidation of User Data in the SpIM

6.5.1 Example of consolidation of data in the SpIM using aggregation

The Figure 6.5.1-1 below provides an example of building the SpIM by aggregating semantically identical data. Attributes that are common to at least two different service profiles are defined in IOCs that are then aggregated to these service profiles. For example, the Roaming1 IOC contains roaming data that is common to GPRS, EPS and CS service profiles, ODB3 contains operator determined barring data that is common to both GPRS and EPS service profiles and Trace contains data that is about subscriber and equipment trace common to all GPRS, CS, EPS and IMS profiles. Using aggregation means that the attribute value will be always same in each of the service profile that has aggregated the IOC where the attribute is defined. Note also that this example only shows how a portion of the data can be consolidated using aggregation.

Figure 6.5.1-1: Consolidation of data in the SpIM using aggregation.

6.5.2 Example of specialization for authentication methods

Figure 6.5.2-1 shows an example of how the CBIM can be further specialized for the purpose of considering different authenticatio-n methods.

Figure 6.5.2-1: Authentication methods

6.5.3.1 AkaUsim

6.5.3.1.1 Definition

This object class represents data that is required to perform Authentication and Key Agreement (AKA) when the UE is equipped with a USIM. For details of AKA see subclause 6.3 in 3GPP TS 33.102 [6]. For example, an encrypted subscriber key and the AMF can be attributes of this object class.

6.5.3.2 CsAka

6.5.3.2.1 Definition

This object class represents data that is required to perform AKA when accessing Circuit-Switched services, such as the sequence number used for AKA authentication to access CS services. For details of AKA see subclause 6.3 in 3GPP TS 33.102 [6].

6.5.3.3 GPRSAka

6.5.3 3.1 Definition

This object class represents data that is required to perform AKA when accessing GRPS services such as the sequence number used for AKA authentication to access GPRS services. For details of AKA see subclause 6.3 in 3GPP TS 33.102 [6].

6.5.3.4 EpsAka

6.5.3.4.1 Definition

This object class represents data that is required to perform AKA when accessing Evolved Packet-Switched services, such as the sequence number used for AKA authentication to access EPS services. For details of AKA see subclause 6.3 in 3GPP TS 33.102 [6].

6.5.3.5 ImsAkaIsim

6.5.3.5.1 Definition

This object class represents data that is required to perform IMS AKA for accessing IMS services when the UE is equipped with a UICC that contains an ISIM, for example, the encrypted subscriber key and AMF that is used for accessing IMS services. For details of IMS AKA see subclause 6.1 in 3GPP TS 33.203 [7].

6.5.3.6 ImsAka

6.5.3.6.1 Definition

This object class represents data that is required to perform IMS AKA when accessing IMS services, such as the sequence number used for AKA authentication to access IMS services. For details of IMS AKA see subclause 6.1 in 3GPP TS 33.203 [7].

6.5.3.7 ImsAkaUsimIsim

6.5.3.7.1 Definition

This object class represents the data that is required to perform IMS AKA for accessing IMS services when the UE is equipped with either a USIM or an ISIM, for example, the realm. It aggregates one of the AkaUsim or ImsAkaIsim object classes, depending on whether the UE is equipped with a USIM or an ISIM, respectively. For details of IMS AKA see subclause 6.1 in 3GPP TS 33.203 [7].

6.5.3.8 GPRSImsBundled

6.5.3.8.1 Definition

This abstract object class represents the data that is required to perform GPRS-IMS bundled authentication. For details of the GPRS-IMS bundled authentication see 3GPP TS 33.203 [6] Annex T.

NOTE: This object class is set to be abstract because it does not need any new particular data. The GPRS-IMS bundled authentication requires the IPv4 address or Ipv6 prefix allocated by GPRS to the UE, therefore, data that is stored elsewhere. This object class is merely here for completeness, but need not be implemented.

6.5.3.9 NassImsBundled

6.5.3.9.1 Definition

This object class represents the data that is required to perform NASS-IMS bundled authentication, such as the line identifier. For details of the NASS-IMS bundled authentication see 3GPP TS 33.203 [6] Annex R.

6.5.3.10 SipDigest

6.5.3.10.1 Definition

This object class represents the data that is required to perform SIP Digest authentication for accessing IMS services. For example, it includes the H(A1) parameter of HTTP Digest, the realm, QoP, and Algorithm directives in HTTP Digest authentication. For details of the SIP Digest authentication see 3GPP TS 33.203 [6] Annex N.

6.5 Construction of AIM

An AIM comprises all the information required by an application. In the construction of an AIM, the following possibilities exist with respect to the current version of the SpIM:

– AIMs may be constructed from new information not yet present in the current version of the SpIM.

– AIMs may be constructed by using information that already exists in the current version of the SpIM.

– AIMs may be constructed requiring both new information and information that already exists in the current version of the SpIM.