4 Reference Architecture

23.2403GPP3GPP Generic User Profile (GUP)Architecture (Stage 2)Release 17TS

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

4.1 GUP Functionalities

4.1.1 Harmonized access interface

The GUP harmonized access interface is the interface which can be used by the GUP suppliers and GUP consumers to access, manage and transfer the profile data. This application layer interface is independent of the profile structure.

4.1.2 Single point of access

There exists for each Profile a single point of access, which knows the location of the various components of the Profile. A discovery service, e.g. Liberty Discovery Service Specification [2] may be used to get the contact reference information for this access point if not known by other means.

4.1.3 Authentication of profile access

A GUP functionality exists that is responsible to authenticate applications. Authentication is a vital function to be passed before any kind of access to GUP data is granted. GUP shall adopt generic mechanisms such as used for the OSA framework approach. More specifically GUP shall use authentication mechanisms from Liberty Alliance Project as specified in Liberty ID-WSF Security and Privacy Overview [5], Liberty Discovery Service [2] and Liberty ID-WSF Security Mechanisms [6].

4.1.4 Authorization of profile access

A GUP functionality exists that is responsible to authorise applications to access GUP data based on User specific or common privacy rules. All attempts to access the GUP data are to be authorized according to the defined policies which shall include the requestor information, the requested data, the target subscriber and the performed operation, or some of those.

GUP shall use authorization mechanisms from Liberty Alliance Project as specified in Liberty ID-WSF Security and Privacy Overview [5] and Liberty ID-WSF Security Mechanisms [6].

The GUP data structures need to satisfy the requirement to provide the authorization information on the different levels: profile, component or data element. In addition to the generic authorization data, additional service specific data may be defined (e.g. for LCS). The same applies for the authorization decision logic. The execution of the authorization logic leads to a decision whether a requestor is allowed to make the request at all, and additionally to which part of data the requestor has the appropriate access rights with regard to the nature of the request.

GUP provides mechanisms for the different GUP entities for managing the authorization data.

Both HPLMN based applications and non-HPLMN based applications are expected to send requests to the GUP Server. The GUP server shall have functionality to apply different authorization criteria, policy control and load control to HPLMN and non-HPLMN applications. Policy control and load control are out of the scope of the present document.

4.1.5 Privacy control

The tight connection of authentication, authorization and subscriber specific privacy requirements results in privacy control. Privacy control implies a centralized management for access rights including the subscriber’s privacy requirements.

GUP shall use privacy control mechanisms and other privacy related features from Liberty Alliance Project as specified in Liberty ID-WSF Security and Privacy Overview [5] and Liberty ID-WSF Security Mechanisms [6].

4.1.6 Synchronization of data storage

The GUP data repository holds the master copy of the GUP component data. Applications or GUP server may copy (i.e. read) the component data or request synchronization. The present document defines how the data is requested and sent. What is thereafter done with the data by the application or GUP server is beyond the scope of the present document.

Synchronization means that the changes to the master copy of the data are propagated to the entities that request synchronization. The synchronization request specifies which data are monitored for changes. It is also possible to request that all changes are reported.

Synchronization may cause heavy processing load to the involved entities, thus some policies are required in the implementations but those are not specified for the time being. However the GUP interfaces should carry sufficient data for enabling the load control mechanisms to work.

The entity under a heavy processing load has the responsibility to handle the error cases and conditions and to reach the synchronization as fast as possible. All the unresolved errors or load balancing actions that affect synchronization shall be reported.

4.1.7 Access of profile from visited network

Access to GUP from a visited network shall follow the single point of access principle.

4.1.8 Location of Profile Components

A GUP functionality exists that keeps information where GUP data are located.

4.1.9 Charging for profile access

The GUP Server shall be capable of providing charging information, e.g. to enable transaction/event based charging.

Some GUP Data Repositories may provide charging information, while other GUP Data Repositories do not provide charging information.

Mechanisms are needed to permit the GUP Server to know which GUP Data Repositories are (and are not) producing their own charging information. When the GUP Data Repository is capable of producing charging information, mechanisms are needed for the correlation of the charging information produced by GUP Server and GUP Data Repository.

The charging information may also be used for other event logging, customer care, privacy auditing, etc. functions.

4.2 GUP functional entities

The GUP reference architecture as shown in Figure 4.1 consists of:

– GUP Server;

– Repository Access Function (RAF);

– GUP Data Repositories;

– Rg and Rp reference points;

– Applications.

Figure 4.1: GUP reference architecture

An example of mapping the GUP reference architecture to current infrastructure environment is shown in Figure 4.2.

Figure 4.2: An example of mapping the GUP reference architecture to current infrastructure environment

4.2.1 GUP Server

The GUP Server is a functional entity providing a single point of access to the Generic User Profile data of a particular subscriber. The reference architecture does not specify or limit the physical location of the GUP Server enabling flexibility in the implementations. However, the GUP Server shall be located in the home operator network of the targeted subscriber.

The GUP Server includes the following main functionalities:

– Single point of access for reading and managing generic user profile data of a particular subscriber.

– Location of Profile Components.

– Authentication of profile requests.

– Authorization of profile requests.

– Synchronization of Profile Components.

The GUP Server may support two modes of operation:

– Proxy mode (see figure 4.3). The Application requests user related data located in the GUP Data Repositories from the GUP Server. After taking care of needed actions specified for the GUP Server (and depending on the type of the request) the GUP Server makes requests to the corresponding GUP Data Repositories and receives responses from them. Finally the Application gets a response to the original request from the GUP Server. Depending on the type of the request also possible subsequent responses are delivered through the GUP Server.

– Redirect mode (see figure 4.4). The Application requests user related data located in the GUP Data Repositories from the GUP Server. After taking care of needed actions specified for the GUP Server (and depending on the type of the request) the GUP Server returns to the Application the information (e.g. address of GUP Data Repository(s)) to allow the Application to request the information from the GUP Data Repositories. The Application then directly requests the information from the GUP Data Repositories.

The Proxy mode is the default mode of operation. Redirect capability and preference for the applied mode may be indicated by the application with the Requestor data parameter when accessing the GUP Server. The GUP Server decides which mode is selected for the different requests. In addition to the Requestor data parameter, the decision is based on the capabilities of the GUP Server and the related Repository Access Functions (RAF) as well as on the service configuration and policy data in the GUP Server related to the particular application. These service configuration and policy data are out of the scope of GUP standardisation. If the Redirect mode is not supported by the GUP Server the response is always sent according to the Proxy mode.

Figure 4.3: GUP Server acting as a Proxy Server

Figure 4.4: GUP Server acting as a Redirect Server.

4.2.1.1 Single point of access

The GUP Server shall accept data management related requests from the applications via the Rg reference point, and either convey the corresponding GUP component specific requests to GUP Data Repositories via Rp reference point or redirect the Application to convey the requests to the GUP Data Repositories. Note that one data request from an application to the GUP Server can cause sending of several GUP Data Repository requests by the GUP Server or Application. Also mapping to proprietary interfaces instead of Rp is possible in implementations.

In Proxy mode the GUP Server shall receive the results of the requests from GUP Data Repositories and deliver the results back to the requestor (Application). In case of responses from several GUP Data Repositories the GUP Server shall combine separate XML documents received from the repositories and deliver the composed information to the requestor. In redirect mode the Application will receive the results of the requests from the GUP Data Repositories.

4.2.1.2 Location of profile components

The GUP Server stores information about the GUP Components and the locations of data repositories of GUP Components related to each subscriber. Thus e.g. the separate GUP components composing the whole User Profile of a certain subscriber can be located and identified. The application shall be able to affect where a new GUP Component is created by the GUP Server. It is beyond this specification how the GUP server gets the component locations in the cases when it is not involved in the creation of those components.

4.2.1.3 Authentication of profile request

The GUP Server shall make sure that the application requesting user profile data is properly authenticated. The authentication is based on the identification of the requesting application and/or the identification of the possible subscriber requesting the user profile data. The GUP Server may rely on the authentication made by other trusted entities.

4.2.1.4 Authorization of profile request

The GUP Server shall take care of the authorization of the access to the user profile data. The authorization itself may be handled by a separate entity in the network, or alternatively by the RAF or GUP Data Repository. The authorization shall be based on the requestor information, the requested data, the target subscriber and the performed operation, or some of them. The authorization rules of the requested data shall be defined at least in the GUP Component level in GUP Server. (Note that the authorization may be based on also on finer granularity of the data content.) It shall be possible to manage the authorization data via the Rg and Rp reference points.

4.2.1.5 Synchronization of profile components

In proxy mode, the GUP Server shall convey the data synchronization requests from the applications to the RAFs in the same way as the other profile requests. Also the related change notifications from the RAFs are passed on to the requesting application. This requires that some kind of book keeping about the synchronization requests implemented. In redirect mode the GUP server shall redirect the Application to the RAFs in the same way as the other profile requests.

The GUP Server may store a copy of the actual data from the GUP Data Repository, but it is up to the local policy of the GUP Server.

4.2.1.6 Additional functionality

The GUP Server may take part in the charging of the data management operations concerning the profile.

The GUP Server may take part in the rate and/or size limiting of the data operations towards the profile.

The GUP Server may utilise a discovery service to register its contact reference information.

4.2.2 Repository Access Function (RAF)

The Repository Access Function (RAF) realizes the harmonized access interface. It hides the implementation details of the data repositories from the GUP infrastructure. The RAF performs protocol and data transformation where needed.

The protocol between the RAF and the GUP data repository is out of the standardization scope. It is recommended that the protocol used should support GUP requirements.

The RAF may take part in the authorization of access to such GUP information, which are under the control of the RAF. In addition, the authorization data may be managed via the Rp reference point.

4.2.3 GUP Data Repository

Each GUP Data Repository stores the primary master copy of one or several profile components. The RAF provides for the standardized access to the GUP Data Repository. The storage formats or the interface between the RAF and GUP Data Repository are not specified by GUP. It is presumed that the RAF and the GUP Data Repository are usually co-located in the same network element.

The GUP Data Repository may contain also the authorization data depending on the authorization model and architecture.

4.2.4 Reference Points

Reference Points in the GUP Reference Architecture:

1. Reference point Rg
This reference point shall allow applications to create, read, modify and delete any user profile data using the harmonized access interface. The GUP Server locates the data repositories responsible of the storage of the requested profile component(s) and in case of proxy mode carries out the requested operation on the data. The reference point Rg shall support interworking to other mechanisms that support parts of the user profile outside the scope of 3GPP e.g. Liberty ID-WSF SOAP Binding Specification [3] and Liberty ID-WSF Data Services Template [4].

In the redirect mode, the GUP Server returns the locations of the GUP Data Repositories and the application can then send the requested operations via reference point Rp directly to the corresponding GUP Data Repositories.

The reference point Rg carries user related data, and therefore shall be protected by security mechanisms.

2. Reference point Rp
This reference point shall allow the GUP Server or applications, excluding external applications (e.g. located in a third party application or in the UE), to create, read, modify and delete user profile data using the harmonized access interface. Rp is an intra-operator reference point. External applications and third party GUP data repositories shall be connected to the GUP Server only using the Rg reference point.

The reference point Rp carries user related data, and therefore shall be protected by security mechanisms.

4.2.5 Applications

The applications that may apply GUP reference points Rg and Rp may be targeted for different purposes e.g. for value added services or subscription management. Both operator’s own applications and third party applications are covered. The latter ones shall apply Rg reference point.

Additionally the applications may utilise a discovery service to discover the contact reference information if not found out by other means. A discovery service e.g., as specified in Liberty Discovery Service Specification [2], may also act as Trusted Authority providing essential security related information (e.g. preferences in terms of peer entity and message authentication mechanism to be used and authentication and/or authorization assertions). Different policies may be followed in the use of discovery service. It may be used by different applications in different ways: per each operation, occasionally or not at all. In general terms, third party applications belonging to external security domains shall use a discovery service as a normal step, but in operator’s services it may not be needed at all.

Applications have different authorization rights to the GUP data of different subscribers as agreed between the parties.

4.2.6 Message flow of using GUP

For an application requesting GUP data component(s) a message flow is described in the following:

– The application requests a GUP component(s) via Single Point of Access (Rg) from the GUP server. The application will indicate if it can support the Redirect mode.

– The GUP server authenticates the application. Note that also separate authentication services may be applied.

– The GUP Server identifies the level of authorization the Application is allowed to access the GUP data.

– The GUP Server identifies the location of the GUP component(s).

At this point the GUP Server may (see figure 4.5 below)

– Access the GUP component(s) by means of the Harmonized Access Interface (Rp) or by other means outside the scope of GUP.

– Respond to the application with the result of the request, optionally combining results from different GUP data repositories.

Or, depending on GUP data repositories choice and if the application has indicated that it can support the Redirect mode (see figure 4.6 below)

– Respond to the application with reference(s) to the component(s) and additionally authorization credentials with limited lifetime. Note that authorization credentials from other sources are not excluded.

– The application uses the reference(s) and the authorization credentials to access GUP data repositories by means of the Rp reference point.

Privacy rules may stay together with the data it applies to at the data repository where the data is stored. In this case this privacy rules shall apply. Optionally, the GUP Server may apply additional privacy rules. However the GUP Server must never "bypass" existing privacy rules.

The following figures show the message flows for both cases as described.

Figure 4.5: An Example of Application requesting GUP data component(s) message flow (Proxy mode)

Figure 4.6: An Application requesting GUP data component(s) message flow (Redirect mode)

4.3 Rg reference point procedures

This clause defines the procedures applied in the Rg reference point between the applications and the GUP Server. This reference point supports also third party profile access. Rg can be used e.g. to create the whole user profile or some components in it, to read any piece of data in the profile or to modify those. There are means to authorise all requests and protect the user’s privacy in all operations. Rg is applied to control the data stored in the different GUP components identified by a resource identity and the component type. The resource identity contains either a subscriber identity or a generic component identification, which is given to components that are not bound to a single subscriber.

There are the following procedures:

– Create

– Delete

– Modify

– List

– Query

– Subscribe

– Unsubscribe

– Notify

Instead of proxying the requests (or handling them by itself) the GUP Server may also apply the redirect mode of operation for applications that support redirect mode, which implies that the GUP Server responds to the request with the redirection information such as redirection address and authorisation assertions. Redirection can be made with Create, Delete, Modify, Query and Subscribe procedures.

4.3.1 Create procedure

Create procedure is used by the application to create a new user profile or new components to an existing profile. The procedure is always related to a single resource identity which is given in the request. Additionally the Create procedure shall carry the component types and the data to be created to each component. At least one component shall be provided. Creation of the first component implies profile creation. The component type identifies what data are concerned i.e. not just the data typing. It is presumed that the profile data structure is already known by the both parties. No new type of data can be defined by this procedure, only the data contents are provided. Furthermore the application shall provide the necessary data for authentication and authorization of this create function (e.g. credentials, assertions and identifications).

The outcome of the procedure shall be provided in a separate response message. If the requestor data indicated that the application is able to receive redirect instructions, the GUP server may decide to return redirect instructions based on policies set by the operator in the GUP server. After this response the procedure is terminated without any other specified results or retained information in the GUP Server.

Table 4.1: Request data of Create procedure

Parameter	Description	Use
Resource Identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Component data	Specifies which components are addressed and provides the data for those. There may be several Component data elements corresponding to several created components. At least one element must be present. See the table below for the more detailed contents.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authentication and authorization process. E.g. end user and application identification, credentials or privacy policy information.	Optional

Table 4.2: Contents of Component data parameter

Parameter	Description	Use
Component type	Specifies the type of the created component. The Component type identifies the applied component data definitions.	Mandatory
Data	Specifies the GUP component data according to the specified Component type.	Mandatory

Table 4.3: Response data of Create procedure

Parameter

Description

Use

Redirection data

Specifies the redirection instructions and assertions.

Optional

Status

Indicates whether:

1. The procedure was carried out successfully,

2. The request was redirected, or

3. A failure was detected.

For the proxy mode 1 or 3 can be indicated. For the redirect mode 2 or 3 can be indicated. The possible failure is described in sufficient detail.

Mandatory (like the response itself)

4.3.2 Delete procedure

Delete procedure is used by the application to remove a profile or selected GUP components from the repository. The attached resource identity and the component type are specified. If no component type is provided, the whole user profile identified by the resource identity will be deleted. The application shall provide the necessary data for authentication and authorization purposes (e.g. credentials, assertions and identifications).

Table 4.4: Request data of Delete procedure

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Component types	Specifies the types of the components.	Optional
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authentication and authorization process. E.g. end user and application identification, credentials or privacy policy information.	Optional

Table 4.5: Response data of Delete procedure

Parameter

Description

Use

Redirection data

Specifies the redirection instructions and assertions.

Optional

Status

Indicates whether:

1. The procedure was carried out successfully,

2. The request was redirected, or

3. A failure was detected.

For the proxy mode 1 or 3 can be indicated. For the redirect mode 2 or 3 can be indicated. The possible failure is described in sufficient detail.

Mandatory (like the response itself)

4.3.2a List procedure

List procedure is used by the application to list the existing profile items in the various GUP Data Repositories, and it is needed to handle large number of items. Different search criteria may be given as input. Only the references (i.e. resource identities and component types) are returned by the procedure. The listing may optionally operate sequentially, and then only a selected number of items is returned in one listing. The application shall provide the necessary data for authentication and authorization purposes (e.g. credentials, assertions and identifications).

The outcome of the procedure shall be provided in a separate response message.

Table 4.5a: Request data of List procedure

Parameter	Description	Use
Search criteria	Specifies which profiles are to be listed. The criteria may include at least resource identity (or part of it) and/or component type.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authentication and authorization process. E.g. end user and application identification, credentials or privacy policy information.	Optional

Table 4.5b: Response data of List procedure

Parameter	Description	Use
Listing data	Provides the listed data (several elements). See the table below for the contents of a single element.	Mandatory
End indication	Indicates that the end of list has been reached.	Optional
Status	Indicates whether: 1. The procedure was carried out successfully, 2. The request was redirected, or 3. A failure was detected. For the proxy mode 1 or 3 can be indicated. For the redirect mode 2 or 3 can be indicated. The possible failure is described in sufficient detail.	Mandatory

Table 4.5c: Contents of Listing data parameter

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Component types	Specifies the component types which are linked to the Resource identity and match with the search criteria.	Mandatory

4.3.3 Modify procedure

Modify procedure is used by the application to change the data in the GUP components. Also adding and deleting data is possible by Modify procedure, but it cannot create a new component. The modified data are identified by the resource identity and the data reference. The modification may concern the whole component or any lower level piece of data referenced in the procedure invocation. The contents for the entire referenced data shall be provided. Several individual changes to different components can be made with one procedure invocation. It must be noted that if modification of one component fails, the other changes cannot always be rolled back (implementation specific feature). However the response data shall specify which modifications were not accomplished. It is also possible to add more similar type of data elements to an existing array type of element. The requestor shall provide the necessary data for authentication and authorization purposes (e.g. credentials, assertions and identifications).

Table 4.6: Request data of Modify procedure

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Modification data	Specifies which data are addressed and how those are changed. There may be several Modification data items corresponding to several individual modifications. These modifications may concern the same or different components. See the table below for the contents of one modification.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authentication and authorization process. E.g. end user and application identification, credentials or privacy policy information.	Optional

Table 4.7: Contents of Modification data parameter

Parameter	Description	Use
Data reference	Specifies which data are modified or expanded. The reference identifies both the component type and the possible deeper level data reference. The reference must be unique in a way that it refers only to one data item.	Mandatory
New data	Specifies the data to be stored in the GUP component. It is expected that all the data elements in the referenced data structure are given.	Mandatory
Overwrite indication	Specifies if the data are added to the existing data or replaces those. Default action is "insert".	Optional

Table 4.8: Response data of Modify procedure

Parameter

Description

Use

Redirection data

Specifies the redirection instructions and assertions.

Optional

Status

Indicates whether:

1. The procedure was carried out successfully,

2. The request was redirected, or

3. A failure was detected.

For the proxy mode 1 or 3 can be indicated. For the redirect mode 2 or 3 can be indicated. The possible failure is described in sufficient detail.

Mandatory (like the response itself)

4.3.4 Query procedure

Query procedure is used by the application to retrieve the data in the user profile or its specific components. The queried data are identified by the resource identity and the data reference. The data retrieval may concern the whole profile, component or any parts of a component as referenced in the invocation. The requestor shall provide the necessary data for authentication and authorization purposes (e.g. credentials, assertions and identifications).

The retrieved data shall be provided in a separate response message. If the requestor data indicated that the application is able to receive redirect instructions, the GUP server may decide to return redirect instructions based on policies set by the operator in the GUP server. After this response the procedure is terminated without any other specified results or retained information in the GUP Server.

Table 4.9: Request data of Query procedure

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Data references	Specifies which data are read. The data reference identifies the component type and the deeper level reference (if the whole component is not meant to be read). Multiple references may be given. It is also possible to refer to the profile root which implies that the whole profile data are queried.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authentication and authorization process. E.g. end user and application identification, credentials or privacy policy information.	Optional

Table 4.10: Response data of Query procedure

Parameter	Description	Use
Data	Contains the retrieved data as indicated by the Data references.	Mandatory
Redirection data	Specifies the redirection instructions and assertions.	Optional
Status	Indicates whether: 1. The procedure was carried out successfully, 2. The request was redirected, or 3. A failure was detected. For the proxy mode 1 or 3 can be indicated. For the redirect mode 2 or 3 can be indicated. The possible failure is described in sufficient detail.	Mandatory

4.3.5 Subscribe procedure

Subscribe procedure is used by the application to request notifications about changes in the GUP component data. The subscribed data are identified by the resource identity and the data reference. Furthermore the application can identify which elements are to be monitored for changes if it is not interested in all changes. Data synchronization can be performed by Subscribe and Notify procedures. The GUP Server returns the identification of the subscription request to provide means for the application to link the notifications of Notify procedure to the related subscribe requests. With Subscribe procedure an application can also request a list of all its subscriptions to notifications from the GUP Server. The GUP Server shall provide all the application’s subscriptions to notifications in the response message.

A filtering data parameter is defined to facilitate performance optimization. This may be left partly vendor/operator specific. The requestor shall provide the necessary data for authentication and authorization purposes (e.g. credentials, assertions and identifications).

Table 4.11: Request data of Subscribe procedure

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID). This parameter may be absent only when List of subscriptions parameter is present, otherwise this parameter shall always be present.	Conditional
Notification Reference	Specifies the call-back address of the Requestor. The GUP server shall send the notifications to this address.	Mandatory
List of subscriptions	Indicates that the application requests the list of all its subscriptions from the GUP server.	Optional
Data references	Specifies which data are monitored for changes. The reference identifies both the component type and the possible deeper level data reference. Multiple references may be given. Any change within the referenced data structure causes a notification to be sent. If the parameter is absent, all modifications are notified.	Optional
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authentication and authorization process. E.g. end user and application identification, credentials or privacy policy information.	Optional
Filter data	Specifies additional conditions for sending notifications to optimize the performance e.g. when immediate synchronization is not required. The parameter specifies also whether the initial data values are requested to be reported.	Optional

Table 4.12: Response data of Subscribe procedure

Parameter	Description	Use
Invoke identifications	Contains the invoke identification assigned by the GUP Server for this request. When the application has requested the list of all its subscriptions, this parameter will contain all the invoke identifications assigned by the GUP Server to the application.	Mandatory (unless the request is redirected or fails)
Redirection data	Specifies the redirection instructions and assertions.	Optional
Status	Indicates whether: 1. The procedure was carried out successfully, 2. The request was redirected, or 3. A failure was detected. For the proxy mode 1 or 3 can be indicated. For the redirect mode 2 or 3 can be indicated. The possible failure is described in sufficient detail.	Mandatory (like the response itself)

4.3.6 Unsubscribe procedure

Unsubscribe procedure is used by the application to cancel one or several existing subscriptions. The outcome of the procedure shall be provided in a separate response message.

Table 4.13: Request data of Unsubscribe procedure

Parameter	Description	Use
Invoke identifications	Specifies one or several invoke identifications assigned by the GUP Server for the subscriptions.	Mandatory

Table 4.14: Response data of Unsubscribe procedure

Parameter	Description	Use
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory (like the response itself)

4.3.7 Notify procedure

Notify procedure is invoked by the GUP Server when the data which was identified in Subscribe procedure changes or when the invoked Subscribe procedure requested sending of all the initial values of the referenced data. The procedure identifies the changed data and provides the new values.

The outcome of the procedure shall be provided in a separate response message.

Table 4.15: Request data of Notify procedure

Parameter	Description	Use
Invoke identification	Specifies the invoke identification assigned by the GUP Server for this subscription.	Mandatory
Notified data	Specifies which data are reported together with the data itself. Multiple pieces of data may be provided.	Mandatory

Table 4.16: Response data of Notify procedure (optional)

Parameter	Description	Use
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory (however the whole response is optional)

4.3.8 Common information definitions

The information elements that are applied in several procedures of Rg reference point are described in this clause.

4.3.8.1 Requestor data

The Requestor data contain the information that the sender of the request provides in order to facilitate the authentication and authorization functions. The access control and user privacy functions work based on these data. Also an unspecified Additional info parameter is defined to carry data e.g. for monitoring or accounting purposes. All the elements are optional. However at least one shall be present if the parameter is applied.

Table 4.17: Requestor data

Element	Description	Use
Subscriber identification	Specifies the end user being served.	Optional
Application identification	Specifies the application being served. The GUP Server has to link the Application identification to the actual sender of the request by the appropriate means taking into account the applied security measures and domains.	Optional
Credentials	Contains authentication information.	Optional
Authorization assertion	Contains the assertion for authorization. The nature of the assertion must be for one time use to prevent replay and cut-and-paste attacks. E.g. digest or signature mechanisms may be applied.	Optional
Privacy policy	Information about the applied privacy policy.	Optional
Redirection indications	Specifies if the application being served is able to handle returned redirect requests or if it specifically desires to apply the redirect mode. However the GUP Server decides which mode is used. If the parameter is missing, it is presumed that no such capability exists with the application.	Optional
Additional info	Additional unspecified information related to the requestor or request.	Optional

4.3.8.2 Redirection data

The Redirection data is returned to the requester if redirection is called for. These data contain the address where the request is to be redirected to and the authorisation assertions optionally provided by the GUP Server, which may this way carry out at least part of the authorisation on behalf of the RAF (or Data Repository). The RAF (or the GUP Data Repository) takes the final decision whether the authorisation is accepted or not.

Table 4.17a: Redirection data

Element	Description	Use
Redirection address	Specifies the address (e.g. URI) where the request is to be redirected.	Optional
Authorisation assertion	Contains the assertion for authorisation. This may be placed in the Requestor data item in the subsequent requests over Rp reference point.	Optional

4.3.9 Error handling and common error types

The basic principle in error handling is that all errors in carrying out the procedures lead to complete abortion of the requested operation. However if e.g. multiple modifications with separate data references are made with one procedure invocation, it is possible that part of these are completed even if some would fail. The procedure error responses identify the error type together with more detailed information about the cause of the error.

The common error types which can be applied to all procedures contain:

Table 4.18: Common error types

Error	Description
Invalid operation	The operation is invalid or unsupported.
Invalid parameter	The given parameter of the operation is invalid.
Unauthorized operation	There was no authority for the requested operation.
Data unavailable	The requested data were not available.
Unexpected error	An unexpected error condition was met.
Authentication error	The authentication of the requestor has failed.

4.4 Rp reference point procedures

This clause defines the procedures applied in the Rp reference point. The application or GUP server acts as the active requestor towards the Repository Access Function (RAF) entities e.g. to read or modify the data. It is assumed that the both ends share initially the same data structure definitions. Rp is applied to control the data stored in the different user profile components identified by a resource identity and the component type. The resource identity contains either a subscriber identity or a generic component identification which is given to components that are not bound to a single subscriber.

There are the following procedures:

– Create Component

– Delete Component

– Modify Data

– List Data

– Read Data

– Subscribe To Data

– Unsubscribe To Data

– Notify Data

– Define Data

4.4.1 Create Component procedure

Create Component procedure is used by the application to add a new profile component in the contacted repository. The attached resource identity and the created component type are specified along with the created data. The component type identifies what data are concerned i.e. not just the data typing. It is presumed that the profile data structure is already known by the both parties. No new type of data can be defined by this procedure, only the data contents are provided. The requestor shall provide the necessary data for authorization purposes (e.g. assertions and identifications).

This procedure is synchronous in nature but it is also possible to define a separate response message.

Table 4.19: Request data of Create Component procedure

Parameter	Description	Use
Resource Identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Component type	Specifies the type of the created component. This is needed because several types may be supported by one RAF. The Component type identifies the applied component data definitions.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authorization process. E.g. end user and application identification. See clause 4.4.9.	Optional
Component data	Specifies the profile component data according to the specified Component type.	Mandatory

Table 4.20: Response data of Create Component procedure

Parameter	Description	Use
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory (like the response itself)

4.4.2 Delete Component procedure

Delete Component procedure is used by the application to remove a profile component from the contacted repository. The attached resource identity and the component type is specified. The requestor shall provide the necessary data for authorization purposes (e.g. assertions and identifications).

This procedure is synchronous in nature but it is also possible to define a separate response message.

Table 4.21: Request data of Delete Component procedure

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Component type	Specifies the type of the component.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authorization process. E.g. end user and application identification. See clause 4.4.9.	Optional

Table 4.22: Response data of Delete Component procedure

Parameter	Description	Use
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory (like the response itself)

4.4.2a List Data procedure

List Data procedure is used by the application to list the existing profile items in the various GUP Data Repositories, and it is needed to handle large number of items. Different search criteria may be given as input. Only the references (i.e. resource identities and component types) are returned by the procedure. The listing may optionally operate sequentially, and then only a selected number of items is returned in one listing. The application shall provide the necessary data for authentication and authorization purposes (e.g. credentials, assertions and identifications).

The outcome of the procedure shall be provided in a separate response message.

Table 4.22a: Request data of List Data procedure

Parameter	Description	Use
Search criteria	Specifies which profiles are to be listed. The criteria may include at least resource identity (or part of it) and/or component type.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authentication and authorization process. E.g. end user and application identification, credentials or privacy policy information.	Optional

Table 4.22b: Response data of List Data procedure

Parameter	Description	Use
Listing data	Provides the listed data (several elements). See the table below for the contents of a single element.	Mandatory
End indication	Indicates that the end of list has been reached.	Optional
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory

Table 4.22c: Contents of Listing data parameter

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Component types	Specifies the component types which are linked to the resource identity and match with the search criteria.	Mandatory

4.4.3 Modify Data procedure

Modify Data procedure is used by the application to change the data in a profile component. The component is identified by the resource identity and the component type. The modification may concern the whole component or any lower level piece of data referenced in the procedure invocation. The contents for the entire referenced data shall be provided. Several individual changes to the component can be made with one procedure invocation. It is also possible to add more similar type of data elements to an existing array type of element. The requestor shall provide the necessary data for authorization purposes (e.g. assertions and identifications).

This procedure is synchronous in nature but it is also possible to define a separate response message.

Table 4.23: Request data of Modify Data procedure

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Component type	Specifies the type of the component.	Mandatory
Modified data	Specifies which data are addressed and how those are changed. There may be several modified data items corresponding to several individual modifications. See the table below for the contents of one modification.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authorization process. E.g. end user and application identification. See clause 4.4.9.	Optional

Table 4.24: Contents of Modified data parameter

Parameter	Description	Use
Data reference	Specifies which data are modified or expanded. The reference may indicate the whole component or any deeper level piece of data. The reference must be unique in a way that it refers only to one data item.	Mandatory
New data	Specifies the data to be stored in the profile component. It is expected that all the data elements in the referenced data structure are given.	Mandatory
Overwrite indication	Specifies if the data are added to the existing data or replaces those. Default action is "insert".	Optional

Table 4.25: Response data of Modify Data procedure

Parameter	Description	Use
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory (like the response itself)

4.4.4 Read Data procedure

Read Data procedure is used by the application to retrieve the data in a profile component. The component is identified by the resource identity and the component type. The data retrieval may concern the whole component or any parts of it as referenced in the invocation. The requestor shall provide the necessary data for authorization purposes (e.g. assertions and identifications).

Table 4.26: Request data of Read Data procedure

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID).	Mandatory
Component type	Specifies the type of the component.	Mandatory
Data references	Specifies which data are read. The data reference may point to a piece of data on any level in the data structure (also to the whole component). Multiple references may be given.	Mandatory
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authorization process. E.g. end user and application identification. See clause 4.4.9.	Optional

Table 4.27: Response data of Read Data procedure

Parameter	Description	Use
Data	Contains the retrieved data as indicated by the Data references. All the data under the referenced one are returned. Multiple packets of data are given if so requested.	Mandatory
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory (like the response itself)

This procedure is synchronous in nature but it is also possible to define a separate response message.

4.4.5 Subscribe To Data procedure

Subscribe To Data procedure is used by the application to request notifications about changes in the profile component data. The component is identified by the resource identity and the component type. Furthermore the application can identify which elements are to be monitored for changes if it is not interested in all changes. Data synchronization can be performed by Subscribe To Data and Notify Data procedures. The RAF returns the identification of the subscription request to provide means for the application to link the notifications of Notify Data procedure to the related subscribe requests. With Subscribe To Data procedure an application can also request a list of all its subscriptions to notifications from the RAF. The RAF shall provide all the application’s subscriptions to notifications in the response message.

A filtering data parameter is defined to facilitate performance optimization. This may be left partly vendor/operator specific. The requestor shall provide the necessary data for authorization purposes (e.g. assertions and identifications).

Table 4.28: Request data of Subscribe To Data procedure

Parameter	Description	Use
Resource identity	Specifies the resource identity with its type (e.g. SIP URI public ID). This parameter may be absent only when List of subscriptions parameter is present, otherwise this parameter shall always be present.	Conditional
Notification Reference	Specifies the call-back address of the Requestor. The RAF shall send the notifications to this address.	Mandatory
List of subscriptions	Indicates that the application requests the list of all its subscriptions from the RAF.	Optional
Component type	Specifies the type of the component.	Mandatory
Data references	Specifies which data are monitored for changes. Multiple references may be given. Any change within the referenced data structure causes a notification to be sent. If the parameter is absent, all modifications are notified.	Optional
Requestor data	Specifies the data related to the requestor. These data may be used as input in the authorization process. E.g. end user and application identification. See clause 4.4.9.	Optional
Filter data	Specifies additional conditions for sending notifications to optimize the performance e.g. when immediate synchronization is not required. The parameter specifies also whether the initial data values are requested to be reported.	Optional

Table 4.29: Response data of Subscribe To Data procedure

Parameter

Description

Use

Invoke identifications

Contains the invoke identification assigned by the RAF for this request.

When the application has requested the list of all its subscriptions, this parameter will contain all the invoke identifications assigned by the RAF to the application.

Mandatory

Status

Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.

Mandatory (like the response itself)

4.4.6 Unsubscribe To Data procedure

Unsubscribe To Data procedure is used by the application to cancel one or several existing subscriptions.

Table 4.30: Request data of Unsubscribe To Data procedure

Parameter	Description	Use
Invoke identifications	Specifies one or several invoke identifications assigned by the RAF for the subscriptions.	Mandatory

Table 4.31: Response data of Unsubscribe To Data procedure

Parameter	Description	Use
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory (like the response itself)

4.4.7 Notify Data procedure

Notify Data procedure is invoked by the RAF when the data which was identified in Subscribe To Data procedure changes or when the invoked Subscribe To Data procedure requested sending of all the initial values of the referenced data. The procedure identifies the changed data and provides the new values.

Table 4.32: Request data of Notify Data procedure

Parameter	Description	Use
Invoke identification	Specifies the invoke identification assigned by the RAF for this subscription.	Mandatory
Notified data	Specifies which data are reported together with the data itself. Multiple pieces of data may be provided.	Mandatory

Table 4.33: Response data of Notify Data procedure (optional)

Parameter	Description	Use
Status	Indicates whether the procedure was carried out successfully or whether some failure was detected. The possible errors are described in sufficient detail.	Mandatory (however the whole response is optional)

4.4.8 Define Data procedure

Define Data procedure is used by the application to define new data elements to the profile component data structure. The names and types for the new data are specified. This procedure facilitates extension of the profile data with new, proprietary data. Subsequently these data can be handled by the above described procedures e.g. modified by the Modify Data procedure.

4.4.9 Common information definitions

The information elements that are applied in several procedures are described in this clause.

4.4.9.1 Requestor data

The Requestor data contain the information that the sender of the request provides in order to facilitate the authorization functions. The access control and user privacy functions work based on these data. Also an unspecified Additional info parameter is defined to carry data e.g. for monitoring or accounting purposes. All the elements are optional. However at least one shall be present if the parameter is applied.

Table 4.34: Requestor data

Element	Description	Use
Subscriber identification	Specifies the end user being served.	Optional
Application identification	Specifies the application being served. The RAF has to link the Application identification to the actual sender of the request by the appropriate means taking into account the applied security measures and domains.	Optional
Authorization assertion	Contains the assertion for authorization. The nature of the assertion must be for one time use to prevent replay and cut-and-paste attacks. E.g. digest or signature mechanisms may be applied. The provisioning of the assertions or any related shared secrets is beyond Rp reference point specifications.	Optional
Additional info	Additional unspecified information related to the requestor or request.	Optional

4.4.10 Error handling and common error types

The basic principle in error handling is that all errors in carrying out the procedures lead to complete abortion of the requested operation. The procedure error responses identify the error type together with more detailed information about the cause of the error.

The common error types which can be applied to all procedures contain:

Table 4.35: Common error types

Error	Description
Invalid operation	The operation is invalid or unsupported.
Invalid parameter	The given parameter of the operation is invalid.
Unauthorized operation	There was no authority for the requested operation.
Data unavailable	The requested data were not available.
Unexpected error	An unexpected error condition was met.
Authentication error	The authentication of the requestor has failed.