Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 22.240  Word version:  17.0.0

Top   Top   Up   Prev   None
0…   5…

 

5  Stakeholder requirementsp. 12

These requirements are given from the perspective of the key stakeholders.
The stakeholders within the context of GUP are:
  • the Subscriber
  • the User
  • the Value Added Service Provider
  • the Home Network Operator
  • the Roamed-to Network Operator
  • the Regulator
Up

5.1  Subscriber Requirementsp. 13

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.

5.1.1  User Requirementsp. 13

For a user's services, that support and are supported by GUP:
  • The user shall be able to customise the services , that have been subscribed to her by the subscriber and interrogate customisation settings, subject to limitations by the Home operator and/or value added service provider and/or subscriber. The user interface for customisation/interrogation is service specific and out of scope of this specification.

5.2  Value Added Service Provider Requirementsp. 13

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.
Up

5.3  Home Network Operator Requirementsp. 13

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.
Up

5.4  Roamed-to Network Operator Requirementsp. 14

None yet identified.

5.5  Regulatory Requirementsp. 14

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

6  General Requirementsp. 14

This clause includes different general technical requirements which are not from the perspective of a particular stakeholder.

6.1  Network Requirementsp. 14

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.
Up

6.2  UE Requirementsp. 14

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.
Up

6.3  General Service Requirementsp. 15

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.
Up

6.4  Management Requirementsp. 15

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.
Up

6.5  Synchronization Requirementsp. 15

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.
Up

6.6  Data Description Requirementsp. 16

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" ...)
Up

7  Securityp. 16

Secure mechanisms shall be available for the transfer of User Profile data to, from or between authorised entities. Access to User Profile data shall only be permitted in an authorised and secure manner. The secure mechanisms to be applied shall be appropriate to the level of confidentiality of the data, the endpoints of the transfer and the routes that are available for the transfer of the data. The owner of the data, normally the body storing the master copy of the data, shall be responsible for applying the appropriate level of security to the transfer of the data.
The secure mechanisms available shall include the following:
  1. Authentication of consumer
    Before any user data transfer takes place, it shall be possible for the supplier of the data to verify the identity of the consumer.
  2. Authentication of supplier
    It shall be possible for the consumer of data to identify the supplier.
  3. It is permissible for either the supplier or consumer of data to employ the services of a third party, known to, and trusted by, both in order to provide authentication of identity.
  4. The validity of an authentication of identity shall, if required, be subject to a maximum time limit.
  5. It shall be possible for the supplier of data to render the data to be unreadable by any party not authorised to receive it.
  6. It shall be possible for the consumer of data to detect whether the data have been tampered with during transmission. .
  7. The security mechanisms shall provide verification that the data has been sent by the supplier and received by the consumer (non-repudiation).
  8. It shall be possible for the supplier and/or the consumer to create an audit log of all GUP data transfer transactions of a specified type, provided that this requirement is made known before any transfer takes place
  9. User profile data in general is proprietary data. This data may not be shared with unauthorized entities. Access control to the data is required. This access control must also apply to data which is located at legacy systems, currently without own access control functionality.
  10. Correct setting of data values in the user profile may be critical for the integrity of certain network services. Therefore, consistency checks are needed to minimise the risk.
  11. Transaction security for the change of data should be available in order to ensure the consistent change of data at different locations.
Up

8  Privacy and Authorisationp. 17

This clause describes the requirements for the authorization of access to the user profile data. The Privacy can be provided by the means of authorization mechanism.

8.1  General Requirementsp. 17

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.
Up

8.2  Authorisation Rulesp. 17

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).
Up

9  Chargingp. 18

It shall be possible to support charging for the management, access and synchronization of the 3GPP Generic User Profile. (e.g. for capability negotiation or remote diagnostic information gathering).

A  Example 3GPP Generic User Profile use casesp. 19

1. Setting up a Subscription for a new customer
  • Precondition
    • A person has just purchased a new device, and requires new subscription data to be initiated in the shop.
  • Actions
    • Subscription data is input by the shop personnel by means of a Subscription Management application.
    • Subscription Management application stores the data in Generic User Profile in the Home Network.
  • Post-condition
    • The user can leave the shop. Her subscription is ready to use.
2. Application Access to User Profile Data using OSA (Pull Scenario)
  • Precondition
    • The application is registered with the OSA framework
    • The application is authorised to access the user profile management Service Control Function and use methods which permit read/write data in user profiles
  • Actions
    • The application uses OSA to read/write data in the user profile of the user
    • The network provides the requested data or modifies the data as requested
  • Post-condition
    • Consistency of the user profile data
3. Notification of user subscription to an HE-VASP application using OSA (Push Scenario)
  • Precondition
    • The OSA application from the HE-VASP is registered with the OSA framework
    • The OSA application is authorized to receive subscription/unsubscription notifications
    • The OSA application has subscribed to the notification permitting to it to know when new users have subscribed to the service implemented by the OSA application
  • Actions
    • A new user subscribes to the service implemented by the OSA application
    • The Home Environment notifies the OSA application about a new subscription and provides it with relevant information (e.g. identity of the user)
    • Possibly the OSA application provides the home environment with a link (e.g. URL) to a location where the user can customize the service
  • Post-conditions
    • The OSA application can now have access to home environment -owned user profile information for this user, provided that it is granted the related access rights
    • The user can customize service data for the service implemented by the OSA application
4. Customization of service specific data for a VHE service provided by a HE-VASP
  • Preconditions
    • The user has a VHE subscription
    • The user is subscribed to the service provided by the HE-VASP
    • There is a link from the user Personal Service Environment (PSE) to the HE-VASP for service customization
    • The user has access to her PSE and has successfully been logged to it
  • Actions
    • The user accesses her PSE and decides to customize the service provided by the HE-VASP
    • She transparently access a service customization interface provided by the HE-VASP (possibly via a hyperlink)
    • She defines/modifies service customization data, which are managed and stored by the HE-VASP
  • Post-condition
    • Next time she uses the service, new customization data will be used
Up

B  Additional Informationp. 21

1. Setting up a Subscription for a new customer
  • Precondition
    • A person has just purchased a new device, and requires a new subscription to be initiated in the shop.
  • Actions
    • The user preferences for services are established.
    • Information about the terminal capabilities are received from the UE.
    • User Profile content is created for the Subscriber, and downloaded over the air, via local link or similar
  • Post-condition
    • The user can leave the shop. Her phone/device is ready to use. Basic settings needed to start and run initial applications ready.
2. Initial Service Configuration (Bootstrap)
  • Precondition
    • No settings made, user with a subscription
  • Actions
    • Settings, partly based on user profile downloaded over the air, via local link or similar
    • The download initiated by the value added service provider, network operator, 3rd party or user
  • User Data
    • Setting received could include basic connectivity configuration parameters and the user's security policy
  • Post-condition
    • The user's phone/device ready to use. Basic settings needed to start and run initial applications ready
3. Backup/Restore of User Profile Components stored in the UE
  • Precondition
  • Backup
    • The phone is configured, all the user preferences are set.
    • The settings include user profile parameters such as generic parameters, service personalisation parameters, user's security policy and other user preferences
  • Restore
    • The phone's initial configuration enables download of configuration and user data at least via local link.
    • A backup of phone configuration and user preferences is available in the network.
  • Actions
    • The user wishes to backup or restore the current version, or parts of the current user profile to the network, or to another UE.
    • The backup/restore is performed via local link or remotely towards the network
    • The backup/restore can be initiated by the user, the value added service provider, 3rd parties or the network operator
  • User Profile Storage
    • Secure area of the (U)SIM or ME or retained in the network by the value added service provider. User private data is only stored in the network with the user permission.
4. Content Negotiation
  • Precondition
    • The user has set her preferences in the UE
    • Terminal type capability information is stored in "internet"
  • Actions
    • The user initiates request for content. The request contains:
      • User preference fetched from the UP
      • Reference to the capability information is stored in "internet"
      • Deviating capability information
    • Returned content selected or tailored according to User preferences and capability information
5. Terminal Management - Manual Helpdesk
  • Precondition
    • A user is complaining because her pocket web browser does not work. He calls the helpdesk
  • Actions
    • The UE capabilities are established by the helpdesk person
    • A helpdesk person at an operator, value added service provider or enterprise verifies that the correct operating parameters are set on the device of a complaining user
  • Post-condition
    • The user's is happy. The pocket web browser is running correctly
6. Terminal Management - Automated Self Fixing
  • Precondition
    • A software agent on the user's device identifies an error.
  • Actions
    • It contacts the helpdesk software entity to fix the problem.
    • The UE capabilities are established by the automated self-fixing solution.
    • The self-fixing solution correctly diagnoses the error and provisions a bug fix.
  • Post-condition
    • The user's device software executes correctly (and is happy)
7. Automatic Access Selection based on preferred list
  • Precondition
    • The UE shall be able to support automatic access technologies selection (i.e. without user intervention).
    • The user has set her preferences in the UE and enabled automatic access technologies selection.
    • A list of preferred access technologies capabilities information is stored in "internet"
    • The access technologies are authorized.
  • Actions
    • The user equipment initiates request for selected access technology. The request contains:
      • User preferences fetched from the UP
      • Reference to the access technology capabilities information is stored in "internet"
    • The preferred access technology is selected.
  • Post-condition
    • The preferred access technology is selected based on the order of precedence defined in a list of access technologies on the UE. The switch to a less preferred access technology, in case the most preferred is not available, takes place without user intervention.
8. Multiple Access Technology Negotiation
  • Precondition
    • The user has set her preferences in the UE and enabled access selection.
    • Terminal type capability information is stored in "internet"
    • The access technologies are authorized
    • The user has access and connection with one ongoing application
  • Actions
    • The (Multi-mode) terminal initiates request for another access technologies.
    • The terminal chooses the most appropriate access form based on the UP and/or the sessions in progress demand of service quality.
    • Returned access form selected according to User preferences and capability information.
  • Post-condition
    • Change of access technology without interrupting any session(s) to/from that host (context transfer).
    • The old access connection end.
    • The user and the terminal are connected via the new access (i.e. WLAN) with the same user identity, without having to re-authenticate.
Up

C  Bibliographyp. 24

The following material, though not specifically referenced in the body of the present document (or not publicly available), gives supporting information.
3GPP TS 21.133:
"3G Security; Security Threats and Requirements".
3GPP TS 22.097:
"Multiple Subscriber Profile (MSP) Phase 1; Service description - Stage 1".
3GPP TR 22.121:
"The Virtual Home Environment".

$  Change historyp. 25


Up   Top