For the purposes of the present document, the following terms and definitions apply: 3GPP Generic User Profile (GUP): GUP Component (logical): GUP Component instance (physical): GUP Data Element: GUP Data Model: Data Description Method: Master component instance (aka master instance): Public User Identity: User: Further 3GPP system related definitions are given in TR 21.905.

For the purposes of the present document, the following abbreviations apply: GERAN GUP IMS IMSI MVNO OSA PID UE UTRAN VASP VHE WLAN Further 3GPP system related abbreviations are given in TR 21.905.

The fact of having several domains within the 3GPP mobile system (e.g. Circuit-Switched, Packet-Switched, IP Multimedia Subsystem ) and access technologies (e.g. GERAN, UTRAN and WLAN) introduces a wide distribution of data associated with the user. Further, the new functions both in terminals and networks mean that the data related to Users, Services and User Equipment will be increased greatly. This causes difficulties for Users, Subscribers, network Operators and Value added service providers to create, access and manage the user-related data located in different entities. The objective of specifying the 3GPP Generic User Profile is to provide a means to enable harmonised usage of the user-related information originating from different entities. The specification of the GUP shall also allow extensibility to cater for future developments. The 3GPP Generic User Profile is the collection of User-related data which affects the way in which an individual user experiences services where a community of entities share this data. The 3GPP Generic User Profile can be stored in the home network environment and/or Value Added Service Provider equipment. The 3GPP Generic User Profile will be accessed by different stakeholders and managed either by one (centralised) or by different stakeholders (de-centralised) such as the user, subscriber, value added service provider and network operator by a standardised access mechanism. The 3GPP Generic User Profile allows intra-network usage (i.e. data exchange between applications within a mobile operator's network) and inter-network usage (between mobile operator's network and value added service providers) as illustrated in Figure 1. The 3GPP Generic User Profile may be also be used by different applications in a standardised way. The 3GPP Generic User Profile will help to create and manage the user data in each entity and on the other hand to make it easier to find all user related data as a whole in the home network environment. Technically the 3GPP Generic User Profile provides an architecture, data description and interface with mechanisms to handle the data.

For each user (characterised by an IMSI or IMS PID) one User Profile exists, which may consist of several 'components'. These components may be distributed in the home network and value added service provider's environment. Within the home network, the components may be distributed in various network nodes. Figure 1 below provides a conceptual overview of GUP and is as such for informative purposes only. Only one master of the component exists, but one or more copies of the master component may exist. The home operator shall be able to copy master components, which are located outside the home network to the home network. Within the home network, functionality exists that is able to locate GUP components, thereby making applications unaware of the actual location of the components. The administration and management of the data associated with this functionality is under the control of the home network. Although GUP does not attempt to provide an actual classification of the data it may contain, one may consider categorisations such as general user information, terminal related information, service specific information, etc. as indicated in clause 4.4.

This clause describes in general terms where the generic user profile data resides and which entities use that information. A general feature of the user profile is that the different entities are data consumers for a certain subset of the generic user profile and are data suppliers for another part. The 3GPP GUP data are distributed by nature and consequently stored in home network and Value Added Service Provider Equipment.

The Generic User Profile provides a generic mechanism to access and manipulate user related data for suppliers and consumers. Using this mechanism the data can be retrieved and managed in a uniform way. However the data contents itself are not described within the Generic User Profile, but only the data model and a schema shall be defined. The suppliers and consumers of the data can be divided into the following groups of applications:

• Applications in the home network
• 3rd Party Applications
• OAM and subscription management applications

Applications in the home network may include those related to call or session handling as well as messaging or web services. Typically fairly high requirements are set on the response time. 3rd Party Applications are similar to applications in the home network but they are non-trusted which means that strict security, access and privacy procedures shall be carried out. OAM activities related to user profile are provisioning and administration of user data by the network operator. These activities are characterised by needs for high throughput and allow longer response time. In order to allow simple and centralized administration it should be transparent to the administrator where the different parts of the user data are stored. As a result, this role needs a single system image on user profile, or, on functional terms, a common data access function. As one alternative the user self-service management may be implemented as part of this function.

GUP components instances may be distributed in the home network and value added service provider's environment. The distribution model is shown in Figure 1. A data consumer can request a copy of a GUP component, i.e. the master instance of the component. This copy may be a working copy or a synchronised copy. Master instance: the data supplier holds the master instance of a GUP component. A synchronized copy of a GUP component is a component instance that is kept synchronized with the master instance. Synchronization here means that changes made to the master instance will be propagated to the synchronized copy (e.g. update, deletion, etc.) The synchronized copy is held within the data consumer's local store.. A working copy of a GUP component is a component instance that corresponds to a copy (or snapshot) of the master instance at a given point in time. The working copy is held within the data consumer's local store. Future changes to the master instance (e.g. update, deletion, etc.) are NOT propagated to the working copy. The working copy remains unaffected by changes of the master instance of the GUP component. If a GUP component is no longer applicable for a given user, the master instance for this GUP component is deleted and all data stores holding synchronized copies are notified about this deletion. If the access rights of the component are changed, a proper notification is sent to the owner of the synchronized copy.

The present document does not mandate any data to be part of the 3GPP Generic User Profile. However the following kind of data are considered to be useful for inclusion in GUP.

1. Authorised and subscribed services information:
   These kind of data are generally owned by the home operator and allow management and interrogation of subscription information and would typically consist of:
   • authorised services that the subscriber may subscribe to
   • services the subscriber actually has subscribed to
2. General user information
   Data, owned by the user, which are not specific to individual services, but may be useful for any service. These would be data like
   • settings (e.g. name, postal address), preferences (e.g. language)
   • Registered Service Profiles of the user, indicating the currently active Service Profile of the user.
3. PLMN specific user information
   Data, owned by the home operator, which are not specific to individual services, but may be useful for any service. These typically would be data like
   • addresses (e.g. MSISDNs, URLs) of the user.
   • WAP parameters (e.g. standard WAP gateway)
   • GPRS parameters (in UE and HSS)
   • Preferred access technologies (The preferred access technology, second preferred access technology etc. e.g. UTRAN, GERAN, WLAN etc.)
4. Privacy control data of the user
   Data, owned by the user, which are specific to individual services and which control privacy settings of that service. These could e.g. be
   • Privacy settings for standardised services like the Presence service or Push service.
   • Privacy settings of non-standardised services.
5. Service specific information of the user:
   Data, owned by the user or value added service provider, which are specific to individual services (standardised or non-standardised). These could e.g. be
   • Service customisation data of the user.
   • Service authentication- and authorisation data (for "single sign on") like keys, certificates, passwords...
6. Terminal related data
   These are data, which relate in particular to the user's terminals (ME and UICC). These could e.g. consist of
   • Terminal capabilities of the terminal currently in use (e.g. User Interface capabilities, communication capabilities, available services, service capabilities,…).
   • Data for initial configuration and/or reset of the ME.
   • Backup data for recovery of the ME configuration including service specific data.
7. Charging and billing related data
   This data consists of information necessary for the user related charging and billing. This data could e.g. consist of:
   • The billing policy

GUP provides a means of supporting access to data for ranges of services and functions (e.g. MMS, Presence). The support of users' services and personalization data may result in manipulating data in a structured manner, and a standardised way of describing and accessing these data structures, utilizing a Data Description Method based on XML Schema. As there may be technologies which have impact on the GUP but could not be included in the Data Description Method, the Data Description Method should take this coexistence with other technologies into consideration.