5 GUP information model
23.2403GPP3GPP Generic User Profile (GUP)Architecture (Stage 2)Release 17TS
A Generic User Profile consists of a number of independent GUP Components. However, a GUP Component may contain (i.e. reference) other GUP components e.g. to enable reuse of data.
The GUP Component has a unique identity within the Generic User Profile. In addition to the component type the component identity contains either a subscriber identity or more generic identification depending on which kind of component is in question. A GUP Component can be retrieved through one RAF, and it may consist of a number of GUP Components, Data Element Groups and/or Data Elements.
A GUP Component contains zero or more Data Element Groups. The Data Element Group contains indivisible Data Elements and/or Data Element Groups. The nested Data Elements Groups allow deeper hierarchical structures. The Data Element Group in the lowest hierarchical level contains one or more Data Elements. The Data Element Groups inside a GUP Component may be of the same or different types.
Alternatively the GUP Component may contain zero or more Data Elements without the Data Element Groups. A GUP component shall have at least one Data Element Group or Data Element.
A Composite Datatype is used to define the structure of the whole GUP Component. The structure includes definition about what kind of Data Element Groups and/or which Data Elements belong to the defined GUP Component as well as the data types and valid values of the data.
The UML Class Diagram below illustrates the basic concepts of the GUP Information Model.
Figure 5.1: The basic concepts of GUP
GUP defines an Authorisation Component, which is just like any other GUP Component. This implies that the same capabilities as for any GUP Component (e.g. identities and structure) are also applied to the Authorisation Component. The Authorisation Component is able to reference any element of the GUP Information Model and define the authorisation regarding those elements. The Authorisation Component may be either subscriber specific or common to several subscribers and/or elements of the GUP Information Model.
Note that any GUP Component may include additional data items, which are used (e.g. by RAF) for the authorisation purposes but those are seen as a part of the data specific to a certain GUP Component, and thus not a part of the generic authorisation specified by GUP.
Figure 5.2 presents an example structure of Generic User Profile with the terms used in the UML Class Diagram. Note that the data structure may be also deeper than shown in the example figure, e.g., the Data Element Groups might consist of nested Data Element Groups.
Figure 5.2: Example structure of GUP information
One purpose of the example structure is to clarify the intended relation between the UML Class Diagram and the hierarchical structure of GUP in terms of XML. Use of XML fulfils the requirements for the architectural structure of the GUP information model.
Each Generic User Profile consists of one or several GUP Components depending on the nature of the user related data. GUP Components are independent XML documents. The Generic User Profile is thus formed of a number of XML documents.
Each GUP Component consists of GUP Components, Data Elements and/or Data Element Groups as defined in the component specific definitions. In XML terms the Data Elements are XML elements. The Data Element Group is a structured XML element with an arbitrarily deep data structure.
Annex A (informative):
Examples of 3GPP Generic User Profile usage
Example 1: GUP Usage with Subscription Management
An application is accessing targeted subscriber’s subscription data (HSS GUP Component) stored in the HSS. It is assumed that RAF is implemented in the HSS and the targeted HSS GUP Component has been created by using the Create Component procedure. The application in this case can be e.g. a Subscription Management application, a service application or any third party application that is interested in the subscription data of a specific subscriber in operator A’s network.
The example of the interworking interface diagram is shown in Figure A.2. In this example GUP Server is working in the proxy mode of operation.
Figure A.2: An Example of the Interworking Diagram between GUP and an Application
The interworking steps between the Application, GUP Server and HSS are summarised below:
Step 1: Application A invokes a Query procedure to the GUP Server including the targeted subscriber’s public user identity joe.doe@operatorA.com in the Resource Identity parameter. The HSS GUP Component will be included in the Data Reference parameter clarifying the targeted data (component type) that the application is interested in. Also specific data (i.e. XML Data Element) within one GUP Component can be requested. Application A’s identity is included in the Requestor data parameter for the identification and authorisation purposes of the request.
Step 2: GUP Server authenticates the application and authorises the request with the result that Application A is allowed to access the HSS GUP Component of the subscriber joe.doe@operatorA.com.
Step 3: GUP Server locates the target GUP Data Repository (RAF address), i.e. that the HSS GUP Component of the subscriber joe.doe@operatorA.com is located in the HSS 1, and invokes Read data procedure to HSS 1.
Step 4: HSS 1 makes an internal query by using the public user identity joe.doe@operatorA.com and returns a response to Read data procedure to the GUP Server including the requested HSS GUP Component data of the subscriber joe.doe@operatorA.com.
Step 5: GUP Server passes the received response to Query procedure further to Application A.
The GUP Server may retrieve authorisation GUP Components from a RAF, if it does not hold sufficient information by itself to carry out the authorisation.
If necessary, e.g. when the application requests several GUP Components, or the whole profile including several GUP components in different repositories, GUP Server can invoke several requests to various RAFs and combine responses to one response when returning a response to the application.
Annex B (informative):
3GPP Generic User Profile candidates
This table lists the Generic User Profile candidates grouped per GUP access. It gives for each data access, the supplier, the consumer and the data repository. The applied categorization of the data in the table does not imply similar GUP component structure.
GUP access |
Supplier |
Data repository |
Description of the data |
Consumer |
General user data for IMS |
AS manager |
AS |
ISIM subscriber data for IMS: – Private & Public SIP URI of the user – Settings back up/restore – Preferences (e.g. languages) – Phone books – Buddy list – Available services – Service capabilities – Active service profile |
S-CSCF |
MMS VASP applications Ref TS 23.141 [7] |
AS manager |
AS |
MMS application specific data: – Authorization – Confidentiality – Charging information – Message distribution |
MMS server |
Privacy control settings of the user |
AS manager |
AS |
Privacy control data of the user: – Privacy settings for standardized service like Presence – Privacy setting of non standardized services |
UE-ISIM |
PLMN specific user information |
O&M |
HSS |
PLMN specific user information: – User addresses (e.g. MSISDNs, URLs) – WAP parameters (e.g. standard WAP gateway) – GPRS parameters – Preferred access technologies (e.g. UTRAN, GERAN, WLAN etc…) |
S-CSCF AS |
Authorized and subscribed service information for CS & PS |
O&M HSS-HLR |
HSS-HLR |
Authorized and subscribed service information: – Subscriber ID (IMSI, MSISDNs) – General subscription information – Subscription restrictions – Basic & Supplementary services – Charging plans – Operator determined barring data is FFS – SMS subscription – MMS subscription |
MSC/VLR GMSC SGSN GGSN MMS server |
CSE handling of user subscriptions for CS & PS |
CSE |
HSS-HLR |
– Forwarding & barring information – CAMEL subscription information |
CSE |
Authorized and subscribed service information for IMS |
O&M |
HSS |
Authorized and subscribed service information: – IM Subscriber ID (Private User ID, Public ID) – Subscribed media – Billing policy – Initial filter criteria – Service keys & triggering aspects – Authorized services that the subscriber may subscribe to – Services the subscriber actually has subscribed to |
S-CSCF AS |
CAMEL services for IMS |
O&M |
HSS-HLR |
CAMEL subscription information for IMS |
IM-SSF |
Annex C (informative):
Change history
Change history |
|||||||
---|---|---|---|---|---|---|---|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
2003-06 |
SA#20 |
SP-030310 |
Raised to v.6.0.0 after approval at SA#20 |
2.0.0 |
6.0.0 |
||
2003-09 |
SA#21 |
SP-030381 |
001 |
1 |
Rg reference point compliance with Liberty Alliance Project ID-WSF |
6.0.0 |
6.1.0 |
2003-09 |
SA#21 |
SP-030381 |
002 |
1 |
Introduction of discovery service |
6.0.0 |
6.1.0 |
2003-09 |
SA#21 |
SP-030381 |
003 |
1 |
Corrections to Rg reference point descriptions |
6.0.0 |
6.1.0 |
2003-09 |
SA#21 |
SP-030381 |
004 |
1 |
Removal of GMLC as example |
6.0.0 |
6.1.0 |
2003-12 |
SA#22 |
SP-030659 |
007 |
1 |
Selection of the GUP Server mode of operation |
6.1.0 |
6.2.0 |
2003-12 |
SA#22 |
SP-030659 |
009 |
1 |
Notification Reference |
6.1.0 |
6.2.0 |
2003-12 |
SA#22 |
SP-030659 |
010 |
2 |
Subscribe Operation, Subscription Status |
6.1.0 |
6.2.0 |
2003-12 |
SA#22 |
SP-030659 |
011 |
1 |
GUP information model improvement |
6.1.0 |
6.2.0 |
2003-12 |
SA#22 |
SP-030659 |
012 |
1 |
GUP Annex B terminal Capability negotiation for IMS |
6.1.0 |
6.2.0 |
2004-03 |
SA#23 |
SP-040038 |
006 |
4 |
Adding a listing function |
6.2.0 |
6.3.0 |
2004-03 |
SA#23 |
SP-040038 |
013 |
2 |
Rg reference point alignment with Liberty ID-WSF |
6.2.0 |
6.3.0 |
2004-03 |
SA#23 |
SP-040038 |
014 |
Generalizing the subscriber identity term to resource identity |
6.2.0 |
6.3.0 |
|
2004-03 |
SA#23 |
SP-040038 |
015 |
1 |
Authorization enhancements |
6.2.0 |
6.3.0 |
2004-03 |
SA#23 |
SP-040038 |
016 |
Authorization model alignment with GUP Information Model |
6.2.0 |
6.3.0 |
|
2004-06 |
SA#24 |
SP-040321 |
017 |
1 |
GUP Server in Home operator network |
6.3.0 |
6.4.0 |
2004-06 |
SA#24 |
SP-040321 |
018 |
1 |
Rp Intra-operator interface |
6.3.0 |
6.4.0 |
2004-06 |
SA#24 |
SP-040321 |
019 |
1 |
GUP Authentication failure |
6.3.0 |
6.4.0 |
2004-06 |
SA#24 |
SP-040321 |
020 |
Removal of editor’s note on existing profile components |
6.3.0 |
6.4.0 |
|
2004-06 |
SA#24 |
SP-040321 |
021 |
1 |
Addition of an example in Annex A |
6.3.0 |
6.4.0 |
2004-06 |
SA#24 |
SP-040321 |
022 |
2 |
Clarification of requirement for component location management |
6.3.0 |
6.4.0 |
2004-09 |
SA#25 |
SP-040525 |
024 |
1 |
Addition of missing security aspects |
6.4.0 |
6.5.0 |
2004-12 |
SA#26 |
SP-040757 |
025 |
Removal of UE as GUP Data Repository |
6.5.0 |
6.6.0 |
|
2005-03 |
SA#27 |
SP-050109 |
026 |
Use of Discovery Service as Trusted Authority |
6.6.0 |
6.7.0 |
|
2007-06 |
SP-36 |
– |
– |
– |
Update to Rel-7 version (MCC) |
6.7.0 |
7.0.0 |
2008-12 |
SP-42 |
– |
– |
– |
Update to Rel-8 version (MCC) |
7.0.0 |
8.0.0 |
2008-12 |
SP-46 |
– |
– |
– |
Update to Rel-9 version (MCC) |
8.0.0 |
9.0.0 |
2011-03 |
SP-51 |
– |
– |
– |
Update to Rel-10 version (MCC) |
9.0.0 |
10.0.0 |
2012-09 |
– |
– |
– |
– |
Update to Rel-11 version (MCC) |
10.0.0 |
11.0.0 |
2014-09 |
SP-65 |
– |
– |
– |
Update to Rel-12 version (MCC) |
11.0.0 |
12.0.0 |
2015-12 |
– |
– |
– |
– |
Update to Rel-13 version (MCC) |
12.0.0 |
13.0.0 |
2017-03 |
– |
– |
– |
– |
Update to Rel-14 version (MCC) |
13.0.0 |
14.0.0 |
2018-06 |
SP-80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
14.0.0 |
15.0.0 |
2020-07 |
SP-88E |
– |
– |
– |
Update to Rel-16 version (MCC) |
15.0.0 |
16.0.0 |
2022-03 |
SP-95E |
– |
– |
– |
Update to Rel-17 version (MCC) |
16.0.0 |
17.0.0 |