For a subscriber's services, that support and are supported by GUP:

• The subscriber shall be able to customise her subscribed services and interrogate customisation settings, subject to limitations by the Home operator and/or value added service provider. The user interface for customisation/interrogation is service specific and out of scope of this specification.

VASP services, i.e. services provided by Value Added Service Providers (VASP), shall - via mechanisms of the GUP - be able to:

• Identify the network, the service and the user in any GUP related operation
• Check a user's subscription information for the service.
• Provide access to a user's service specific GUP data stored by the application (according to the access rights set by the user).
• Access other GUP data of the user subject to limitations of access rights

VASP services - standardised and non-standardised - may be part of the 3GPP system (as operator supplied services in the home-network or in a different 3GPP network) or may reside outside the 3GPP system. It shall be possible for VASP services outside the 3GPP domain to access GUP only via a secure interface to the 3GPP system.

The home network operator shall, via GUP mechanisms, be able to:

• support On-line Service Registration
  Subscriber service registration can be set up by on-line subscription not just by customer care. This will also reduce Customer Relationship Management (CRM) workload.
• access Terminal Capabilities
  Terminal capabilities (e.g. software and hardware information, application features, etc) shall be accessible to the network. This information may be used to enable any services within network.
• access Value Added Service Provider Capability Information
  Value Added Service Provider capability information (e.g. Compression algorithms, Billing capabilities) should be accessible to the network. This information may be used to provide end-to-end service according to UE, Network and the Value Added Service Provider's capabilities.

None yet identified.

None identified in addition to the considerations in clause 8. Privacy and Authorisation.

These requirements are collected from the point of view of technical Network infrastructure and Elements:

• The GUP data shall be accessed by standardised GUP interfaces and protocols which use the generic GUP data model to carry the user profile.
• The GUP Interface shall be independent of the structure and semantics of the data.
• The GUP access mechanism shall support accessing of the whole profile data or a selected part of it.
• The GUP access mechanism shall include read, create, modify and delete access. GUP shall provide these access mechanisms to read, create, modify, and delete data of GUP components.
• The GUP data shall be transferred in a standardised way.
• The GUP interface shall include a standardised way for access control.
• The GUP interface shall enforce the subscriber privacy.
• The GUP interface shall enforce the user privacy.
• The GUP shall not cause significant additional load or delays to the network functions and elements.

This clause includes different UE specific requirements for the 3GPP GUP.

• GUP shall provide mechanisms to represent UE data as GUP components in the network(e.g. terminal capabilities, user preferences, etc).
• Network based applications should have "read" access to GUP components representing UE data, irrespective of the connection status of the UE.
• It shall be possible to back up GUP data to the home network or VASP network and to restore it to a UE, however, the mechanism used is outside the scope of GUP.

This clause includes different Service aspects and requirements for the 3GPP Generic User Profile. The following general requirements from the point of view of different Service Applications apply:

• It shall be possible for an application to retrieve the whole user profile or selected parts of it in one transaction.
• There shall be effective means to retrieve individual GUP data elements with acceptable delay for real-time services.

One typical use case for the latter requirement is a call control application that would take advantage of subscriber's preferences or charging related information. Third party applications may take advantage of the features specified e.g. for Open Service Access (see OMA Parlay Service Access Requirements [3]) to access GUP data. The description of GUP data shall be easily extensible for new, proprietary uses without any problems caused for the existing or standard applications.

This clause includes different technical Management aspects for the 3GPP Generic User Profile based on the needs of e.g. Self-Service Management, Subscription Management, Service Management, Network Element Management, Network Management and Customer Relationship Management. In 3G networks it is expected that user profile data is not only distributed over different network elements but belongs to different administrative domains. These administrative domains may be closed against external access. However, in order to enable a seamless service experience for the user a controlled transparency to exchange user profile data is needed. There exist two main cases to be addressed: Domain borders in the home network: Already in the network of the subscriber's home network operator there may exist different domains. Potential examples are application of 3rd party value added service providers which are loosely coupled with the network provider, e.g. their applications run under the brand of the network operator but their data are stored and maintained apart from the network operator's entities. Domain borders between different network operators: This is the well-known roaming scenario where a user is served by another network than his home one. Roaming is already addressed by mobile networks but in the case of 3G networks there is an important additional requirement: The assumed frequent changes of applications induces a need to handle frequent changes of data sources/consumers. The user profile data access architecture shall enable the transparent and flexible usage of the user profile data. It shall provide transparent access to distributed data fulfilling the needs of the different roles described above. Furthermore, the architecture shall address the fact that parts of the user profile data are potentially located in different administrative domains. Possible means are negotiation capabilities and proxy functionality at the domain borders. Management of GUP data components: Making a particular data store available for GUP is not in the scope of GUP and needs to be administered by other means. The administration (installation and modification) of the structure of GUP components at a specified data store is not in the scope of GUP and needs to be administered by other means.

To avoid unnecessary duplicated data storage an application should be able to access parts of the user's GUP data. The following requirements are applicable to the synchronization model:

1. GUP shall offer a mechanism to define synchronized copies, i.e. instances that are kept synchronized with the master instance.
2. GUP shall offer a mechanism to define working copies, i.e. instances that do not require any synchronization.
3. GUP shall make sure that synchronized copies do not conflict with the access right of the corresponding GUP components. For example, if the access rights to some parts of the GUP component change such that the data consumer no longer has access rights, then those parts of the GUP component would no longer be synchronised.

The Generic User Profile is a generic, extensible profile data collection with mechanisms to e.g. create, retrieve, delete and modify the data. GUP shall define a standardised way of data description. This allows for a standardised access and handling of these data, not excluding the possibility of proprietary extensions. Only part of the data contents are standardised within 3GPP specifications, whereas application specific data is outside the scope of the 3GPP standardisation. This specification does not mandate any 3GPP service specific data to be part of the 3GPP Generic User Profile. However the common data types shall be specified to facilitate the separate work on the service specific definitions (e.g. for the user profile in HSS). The common data shall contain data types for at least:

• Private IDs (IMSI and IMS Private User Identity)
• Public IDs (MSISDN and SIP URL)
• Other address types, that are supported by 3GPP (e.g. e-mail)
• Service identifications
• Generic privacy control data
• Date and time
• Service Subscription state (e.g. "active", "not subscribed", "dormant" ...)

It shall be possible for the user to define privacy requirements for components of the 3GPP Generic User Profile to determine access rights. It is agreed in the subscription agreement between the home network operator and the subscriber how the access and privacy control is carried out e.g. who is able to control different parts of the user profile including the privacy settings. The GUP shall provide means to implement access and privacy control according to the different agreements. The GUP authorization shall be independent of who has set the privacy rules for each part of the GUP data. A generic mechanism shall be provided to ensure that only such data for which there is a valid authority can be created, read, modified or deleted. The privacy requirements shall fulfill local privacy regulations. Lawful interception and other regulator requirements may imply that GUP data is delivered to authorities despite the privacy settings.

Authorisation of the requested action (create, read, modify or delete) on the user profile data depends on the following information:

• identification of the requesting application
• identification of the requesting subscriber (if delivered in the request)
• identification of the targeted user
• identification of the targeted user profile data

The disclosure of the user profile data must be considered based on the identification of the application requesting access to the data. The possible identities of the applications will not be standardized but are implementation specific. Regarding trusted applications involving other subscribers or comparable entities it shall be possible also to check the access rights of the subscriber being served by the application. This requires that the identification of the served subscriber is passed via the GUP mechanism in addition to the application identification. The access is first defined per applications and secondly per served subscriber. The access may be granted also to the public, some group or a list of subscribers. The identity of targeted user will be based on the 3GPP network identities (Private and Public User Identities). Public User Identities would be normally applied, but especially within the operator domain the Private Identity could be used as well. The targeted user profile data will be controlled as per the whole user profile and/or per different GUP components and/or per different GUP data elements. Depending on the service the privacy of the requested GUP data can additionally be managed in the service level e.g. in Presence or IMS group management. The privacy rules for these services are specified in the corresponding 3GPP specifications. The GUP shall also support the possibility that the privacy of specific GUP data is queried from other privacy control system. Existing privacy solutions should be considered and adopted if applicable (e.g. LCS).