Tech-invite  3GPPspace  IETFspace
◀  ▶  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.434  Word version:  19.7.0

Top   Top   Up   Prev   Next
0…   6…   8…   9…   9.3…   9.3.3…   9.3.8…   9.3.13…   9.3.20…   9.3.23…   9.4…   10…   10.3…   10.3.3…   10.3.7…   10.4…   11…   12…   13…   14…   14.3…   14.3.3…   14.3.4…   14.3.4A…   14.3.4A.5…   14.3.4A.8…   14.3.5…   14.3.9…   14.4…   15…   17…   18…   A… 
6 Generic functional model for SEAL services  6.1 General  6.2 On-network functional model description  6.3 Off-network functional model description  6.4 Functional entities description  6.4.1 General  6.4.2 Application plane  6.4.3 Signalling control plane  6.5 Reference points description  6.5.1 General reference point principle  6.5.2 Application plane  6.5.3 Signalling control plane  7 Identities 
...

 

6  Generic functional model for SEAL services  p. 31

6.1  General  p. 31

The functional model for SEAL is organized into generic SEAL service functional model and specific SEAL service functional models. The generic SEAL service functional model will be used as the reference model for the specific SEAL service functional models.
The following SEAL services are supported towards the vertical application layer:
  • Location management;
  • Group management;
  • Configuration management;
  • Identity management;
  • Key management;
  • Network resource management;
  • Data delivery;
  • Notification management;
  • Network slice capability enablement; and
  • Application data analytics enablement.
The generic functional model for the SEAL is organized into generic functional entities to describe a functional architecture which addresses the application layer support aspects for vertical applications. The on-network and off-network functional model is specified in this clause.
Up

6.2  On-network functional model description  p. 31

Figure 6.2-1 illustrates the generic on-network functional model for SEAL.
Reproduction of 3GPP TS 23.434, Fig. 6.2-1: Generic on-network functional model
Figure 6.2-1: Generic on-network functional model
Up
In the vertical application layer, the VAL client communicates with the VAL server over VAL-UU reference point. VAL-UU supports both unicast and multicast delivery modes.
The SEAL functional entities on the UE and the server are grouped into SEAL client(s) and SEAL server(s) respectively. The SEAL consists of a common set of services (e.g. group management, location management) and reference points. The SEAL offers its services to the vertical application layer (VAL).
The SEAL client(s) communicates with the SEAL server(s) over the SEAL-UU reference points. SEAL-UU supports both unicast and multicast delivery modes. The SEAL client(s) provides the service enabler layer support functions to the VAL client(s) over SEAL-C reference points. The VAL server(s) communicate with the SEAL server(s) over the SEAL-S reference points. The SEAL server(s) may communicate with the underlying 3GPP network systems using the respective 3GPP interfaces specified by the 3GPP network system.
The specific SEAL client(s) and the SEAL server(s) along with their specific SEAL-UU reference points and the specific network interfaces of 3GPP network system used are described in the respective on-network functional model for each SEAL service.
Figure 6.2-2 illustrates the functional model for interconnection between SEAL servers.
Reproduction of 3GPP TS 23.434, Fig. 6.2-2: Interconnection between SEAL servers
Figure 6.2-2: Interconnection between SEAL servers
Up
To support distributed SEAL server deployments, the SEAL server interacts with another SEAL server for the same SEAL service over SEAL-E reference point.
Figure 6.2-3 illustrates the functional model for inter-service communication between SEAL servers.
Reproduction of 3GPP TS 23.434, Fig. 6.2-3: Inter-service communication between SEAL servers
Figure 6.2-3: Inter-service communication between SEAL servers
Up
The SEAL server interacts with another SEAL server for inter-service communication over SEAL-X reference point.
Figure 6.2-4 illustrates the functional model for communication between SEAL server and VAL user database.
Reproduction of 3GPP TS 23.434, Fig. 6.2-4: Communication between SEAL server and VAL user database
Figure 6.2-4: Communication between SEAL server and VAL user database
Up
The SEAL server interacts with the VAL user database for storing and retrieving user profile over VAL-UDB reference point.
Figure 6.2-5 shows the functional model for the signalling control plane.
Reproduction of 3GPP TS 23.434, Fig. 6.2-5: Functional model for signalling control plane
Figure 6.2-5: Functional model for signalling control plane
Up

6.3  Off-network functional model description  p. 34

Figure 6.3-1 illustrates the generic off-network functional model for SEAL.
Reproduction of 3GPP TS 23.434, Fig. 6.3-1: Generic off-network functional model
Figure 6.3-1: Generic off-network functional model
Up
In the vertical application layer, the VAL client of UE1 communicates with VAL client of UE2 over VAL-PC5 reference point. A SEAL client of UE1 interacts with the corresponding SEAL client of UE2 over SEAL-PC5 reference points. The UE1, if connected to the network via Uu reference point, can also act as a UE-to-network relay, to enable UE2 to access the VAL server(s) over the VAL-UU reference point.
The specific SEAL client(s) along with their specific SEAL-PC5 reference points are described in the respective off-network functional model for each SEAL service.
Up

6.4  Functional entities description  p. 34

6.4.1  General  p. 34

Each subclause is a description of a functional entity corresponding to SEAL and does not imply a physical entity.

6.4.2  Application plane  p. 34

6.4.2.1  General  p. 34

Entities within the application plane of a VAL system provide application control and media specific functions to support one or more VAL services.

6.4.2.2  VAL client  p. 34

The VAL client provides the client side functionalities corresponding to the vertical applications (e.g. V2X client). The VAL client supports interactions with the SEAL client(s).

6.4.2.3  VAL server  p. 35

The VAL server provides the server side functionalities corresponding to the vertical applications (e.g. V2X application servers). The VAL server acts as CAPIF's API invoker as specified in TS 23.222.

6.4.2.4  SEAL client  p. 35

The SEAL client provides the client side functionalities corresponding to the specific SEAL service. The SEAL client(s) supports interactions with the VAL client(s). The SEAL client also supports interactions with the corresponding SEAL client between the two UEs.

6.4.2.5  SEAL server  p. 35

The SEAL server provides the server side functionalities corresponding to the specific SEAL service. The SEAL server supports interactions with the VAL server(s). The SEAL server acts as CAPIF's API exposing function as specified in TS 23.222. The SEAL server also supports interactions with the corresponding SEAL server in distributed SEAL deployments.

6.4.2.6  VAL user database  p. 35

This functional entity contains information of the user profile associated with a VAL service that is served by the VAL service provider at the application plane.
Each VAL service may have a corresponding user database e.g. MCPTT user database as defined in TS 23.379, MCVideo user database as defined in TS 23.281 and MCData user database as defined in TS 23.282.
Up

6.4.3  Signalling control plane  p. 35

6.4.3.1  SIP entities  p. 35

6.4.3.1.1  Signalling user agent  p. 35
This functional entity acts as the SIP user agent (both client and server) for all SIP transactions.
6.4.3.1.2  SIP AS  p. 35
The SIP AS functional entity supports the following functions on behalf of the VAL service:
  • influencing and impacting the SIP session; and
  • supporting event subscription and event notification.
6.4.3.1.3  SIP core  p. 35
6.4.3.1.3.1  General  p. 35
The SIP core contains a number of sub-entities responsible for registration, service selection and routing in the signalling control plane.
The SIP core shall be either:
  1. compliant with TS 23.228, i.e. the SIP core is a 3GPP IP multimedia core network subsystem; or
  2. a SIP core, which internally need not comply with the architecture of TS 23.228, but with the reference points that are defined in subclause 6.5.3 (if exposed), compliant to the reference points defined in TS 23.002.
The data related to the functions of the SIP core, e.g. for data for application service selection, the identity of the serving registrar or authentication related information may be provided by the PLMN operator responsible for the bearer plane. In this case, the SIP database that is the source of the data may be part of the HSS. Alternatively, this data may be provided by the VAL service provider. In this case, the source of the data may be the VAL service provider's SIP database.
Up
6.4.3.1.3.2  Local inbound / outbound proxy  p. 36
The local inbound / outbound proxy functional entity acts as both an inbound proxy and an outbound proxy for all SIP transactions. This functional entity can provide the following functions:
  • NAT traversal;
  • Resource control;
  • Route/forward requests and responses to the user agents;
  • SIP signalling security; and
  • Depending on the PLMN operator policy, discovery and address resolution, including E.164 numbers.
6.4.3.1.3.3  Registrar finder  p. 36
The registrar finder functional entity is responsible for:
  1. Identifying the serving registrar / application service selection functional entity. The serving registrar / application service selection functional entity is identified using information provided either by the PLMN operator's own SIP database or the VAL service provider's SIP database, and optionally using the PLMN operator's internal information e.g. network topology, registrar availability.
    1. Registrar finder and registrar in the VAL service provider domain: registrar finder in the VAL service provider's domain uses the information from the VAL service provider's SIP database to identify the serving registrar in the VAL service provider domain.
    2. Registrar finder and registrar in the PLMN operator domain: registrar finder uses information from PLMN operator's SIP database to identify the serving registrar in the PLMN operator domain.
    3. Registrar finder in PLMN operator domain and registrar in VAL service provider domain: registrar finder uses information from the VAL service provider's SIP database to identify the serving registrar in the VAL service provider domain.
  2. Providing discovery and address resolution, including E.164 numbers.
Up
6.4.3.1.3.4  Registrar / application service selection  p. 36
The registrar / application service selection functional entity provides the following functions:
  • Registrar function (with integral provision of a location server) and also acts as an inbound proxy (with access to the integral location server), and outbound proxy for all SIP transactions where application service selection is required. It registers the user and maintains the association of the location and identity of the user in a location service. It provides notifications of the registration states.
  • Supports authentication for identities provided within SIP signalling. Both the registrar (with integral location server) and authentication functions are supported by access either to the public network's own SIP database or the VAL service provider's SIP database.
  • Can provide the application service selection for all SIP transactions, possibly based on application service selection information stored by either the public network's own SIP database or the VAL service provider's SIP database.
  • Performs SIP signalling security.
Up
6.4.3.1.4  Diameter proxy  p. 37
This functional entity acts as a proxy agent for Diameter messaging as specified in RFC 6733.
The Diameter proxy, when used on the AAA-2 interface, is collocated with the migration management server.
Other instances of the Diameter proxy may also be present in the SIP core / IMS.

6.4.3.2  SIP database  p. 37

6.4.3.2.1  General  p. 37
The SIP database contains information concerning the SIP subscriptions and corresponding identity and authentication information required by the SIP core, and such information as application service selection.
In deployment scenarios where the PLMN operator provides the SIP core, this database is provided by the HSS.
In deployment scenarios where the VAL service provider provides the SIP core, the SIP database may be provided by the VAL service provider.
Access to the data residing in the SIP database is restricted to the SIP core entities that are specifically serving the subscriber/user whose data are stored, i.e. registrars and registrar finders can access SIP databases only when they are part of the same trust domain for the data being provided.
The SIP database is responsible for storing the following user related information:
  • signalling plane user identities: Numbering and addressing information;
  • signalling plane security information: SIP core access control information for authentication and authorization;
  • VAL UE Location information at inter-system level: the SIP database supports the user registration, and stores inter-system location information, etc.; and
  • signalling plane subscription profile (including initial filter criteria).
The SIP database also generates signalling plane security information for mutual authentication, communication integrity check and ciphering.
Based on this information, the SIP database is also responsible to support the call control and session management entities of the SIP core.
The SIP database consists of the following functionalities:
  • support for control functions of the SIP core such as the Registrar and Registrar finder. This is needed to enable subscriber usage of the SIP core services. This functionality is independent of the access network used to access the SIP core; and
  • authentication functionality required by the SIP core to authenticate the VAL UE.
Up
6.4.3.2.2  SIP database logical functions  p. 38
The SIP database provides the following logical functions:
  1. mobility management;
    • provides the UE mobility through the SIP core.
  2. registrar assignment support;
    • provides to the registrar finder the required capabilities for VAL services based on VAL service provider requirements on a per-user basis, (e.g. whether a particular registrar within the PLMN operator's network (e.g. a registrar reserved for VAL service use or a registrar in a secure location) or a registrar within the VAL service provider network is assigned.
  3. call and/or session establishment support;
    • provides the call and/or session establishment procedures in the SIP core. For terminating traffic, it provides information on which registrar currently hosts the user.
  4. user security information generation;
    • provides generation of user authentication, integrity and ciphering data for the SIP core.
  5. signalling plane security support;
    • provides authentication procedures to access VAL services by storing the generated data for authentication, integrity and ciphering at the signalling plane and by providing these data to the appropriate registrar.
  6. user identification handling;
    • provides the appropriate relations among all the identifiers uniquely determining the signalling plane identities in the SIP core e.g. IMS public identities.
  7. access authorisation; and
    • provides authorisation of the user for mobile access when requested by the registrar e.g. by checking that the user is allowed to roam to that visited network.
  8. service authorisation support.
    • provides basic authorisation for terminating call/session establishment and service invocation. The SIP database may update the registrar with filter criteria to trigger the VAL server(s).
Up

6.4.3.3  HTTP entities  p. 38

6.4.3.3.1  HTTP client  p. 38
This functional entity acts as the client for all hypertext transactions.
6.4.3.3.2  HTTP proxy  p. 38
This functional entity acts as a proxy for hypertext transactions between the HTTP client and one or more HTTP servers. The HTTP proxy terminates a TLS session on HTTP-1 with the HTTP client of the VAL UE allowing the HTTP client to establish a single TLS session for hypertext transactions with multiple HTTP servers that are reachable by the HTTP proxy.
The HTTP proxy terminates the HTTP-3 reference point that lies between different HTTP proxies. It may provide a topology hiding function from HTTP entities outside the trust domain of the VAL system.
The HTTP proxy shall be in the same trust domain as the HTTP clients and HTTP servers that are located within a VAL service provider's network. There can be multiple instances of an HTTP proxy e.g. one per trust domain.
Up
6.4.3.3.3  HTTP server  p. 39
This functional entity acts as the HTTP server for all hypertext transactions.

6.4.3.4  LWP entities |R17|  p. 39

6.4.3.4.1  LWP client  p. 39
This functional entity acts as the light-weight protocol client for all transactions of the SEAL client executing in a constrained UE. A SEAL client executing in an unconstrained UE may choose to use the LWP client if it is available.
6.4.3.4.2  LWP proxy  p. 39
This functional entity acts as a proxy for transactions between the LWP client and one or more LWP servers. The LWP proxy typically terminates a secure transport protocol (e.g. DTLS, TLS or secure WebSocket) session on LWP-1 reference point with the LWP client of the VAL UE allowing the LWP client to establish a single secure session for transactions with multiple LWP servers that are reachable by the LWP proxy.
The LWP proxy can act as a cross-protocol LWP-HTTP proxy to enable LWP clients to access resources on HTTP servers via the LWP-HTTP-2 reference point.
The LWP proxy terminates LWP-3 reference point that lies between different LWP proxies. It may provide a topology hiding function from LWP entities outside the trust domain of the VAL system.
The LWP proxy can also terminate LWP-HTTP-3 reference point for interworking with another HTTP proxy. In this role it provides cross-protocol mapping and may provide a topology hiding function from HTTP entities outside the trust domain of the VAL system.
The LWP proxy shall be in the same trust domain as the LWP clients and LWP servers that are located within a VAL service provider's network. There can be multiple instances of a LWP proxy e.g. one per trust domain.
Up
6.4.3.4.3  LWP server  p. 39
This functional entity acts as the LWP server for all LWP transactions of the SEAL server.

6.4.3.5  LWP usage |R17|  p. 39

LWP is a generic representation of a light-weight protocol for use in constrained environments. Realizations of the light-weight protocol (LWP) functional entities and reference points to a particular protocol are defined in the annexes of this specification.
LWP is a representation of a protocol to be used by the SEAL service enablers on their respective SEAL-UU reference points when the SEAL client is executing in a constrained UE. In this case the SEAL client should use the LWP-1 reference point with the LWP proxy and should use either the LWP-2 or the LWP-HTTP-2 reference point for transport and routing of the related signalling with the SEAL server.
A SEAL client executing in a non-constrained UE may choose to use the LWP-1 reference point with the LWP proxy and may use either the LWP-2 or the LWP-HTTP-2 reference point for transport and routing of the related signalling with the SEAL server.
LWP may be used for interactions between SEAL servers on their respective SEAL-E reference points. For this usage the SEAL-E reference point shall use the LWP-1 and either the LWP-2 or the LWP-3 reference point depending on the trust relationship between the interacting SEAL servers.
Up

6.5  Reference points description  p. 40

6.5.1  General reference point principle  p. 40

The protocols on any reference point that is exposed for VAL service interoperability with other SIP core or other IMS entities in other systems shall be compatible with the protocols defined for the corresponding reference point defined in TS 23.002.

6.5.2  Application plane  p. 40

6.5.2.1  General  p. 40

The reference points for the generic functional model for SEAL are described in the following subclauses.

6.5.2.2  VAL-UU  p. 40

The interactions related to vertical application layer support functions between VAL client and VAL server are supported by VAL-UU reference point. This reference point is an instance of Uu reference point as described in TS 23.401 and TS 23.501.

6.5.2.3  VAL-PC5  p. 40

The interactions related to vertical application layer support functions between the VAL clients of two UEs are supported by VAL-PC5 reference point. This reference point is an instance of PC5 reference point as described in TS 23.303.

6.5.2.4  SEAL-UU  p. 40

The interactions between a SEAL client and the corresponding SEAL server are generically referred to as SEAL-UU reference point. The specific SEAL service reference point corresponding to SEAL-UU is specified in the specific SEAL service functional model.

6.5.2.5  SEAL-PC5  p. 40

The interactions between the SEAL clients of two VAL UEs are generically referred to as SEAL-PC5 reference point. The specific SEAL service reference point corresponding to SEAL-PC5 is specified in the specific SEAL service functional model.

6.5.2.6  SEAL-C  p. 40

The interactions between the VAL client(s) and the SEAL client(s) within a VAL UE are generically referred to as SEAL-C reference point. The specific SEAL service reference point corresponding to SEAL-C is specified in the specific SEAL service functional model.

6.5.2.7  SEAL-S  p. 40

The interactions between the VAL server and the SEAL server are generically referred to as SEAL-S reference point. The specific SEAL service reference point corresponding to SEAL-S is specified in the specific SEAL service functional model.

6.5.2.8  SEAL-E  p. 41

The interactions between the SEAL servers of the same type are generically referred to as SEAL-E reference point. The specific SEAL service reference point corresponding to SEAL-E is specified in the specific SEAL service functional model.

6.5.2.9  SEAL-X  p. 41

6.5.2.9.1  General  p. 41
The interactions between the SEAL servers of different type are generically referred to as SEAL-X reference point. The specific SEAL server interactions corresponding to SEAL-X are described in the following subclauses.
6.5.2.9.2  Reference point SEAL-X1 (between the key management server and the group management server)  p. 41
The SEAL-X1 reference point, which exists between the key management server and the group management server, provides a means for the key management server to provide security related information (e.g. encryption keys) to the group management server.
The SEAL-X1 reference point shall use the HTTP-1 and HTTP-2 reference points and may use the HTTP-3 reference point for transport and routing of security related information to the group management server.
6.5.2.9.3  Reference point SEAL-X2 (between the group management server and the location management server)  p. 41
The SEAL-X2 reference point enables the group management server to interact with the location management server.
The SEAL-X2 reference point supports:
  • the group management server to create a location-based group with the help from the location management server.
6.5.2.9.4  Reference point SEAL-X3 (between the group management server and the configuration management server) |R18|  p. 41
The SEAL-X3 reference point enables the group management server to interact with the configuration management server.
The SEAL-X3 reference point supports:
  • the group management server to retrieve VAL service data from the configuration management server.

6.5.2.10  Reference point VAL-UDB (between the VAL user database and the SEAL server)  p. 41

The VAL-UDB reference point, which exists between the VAL user database and the SEAL server, is used for:
  • storing the user profile data in the specific VAL user database; and
  • obtaining the user profile from the specific VAL user database for further configuration in the UE;
  • updating the user profile data in the specific VAL user database; and
  • deleting the user profile data from the specific VAL user database.

6.5.3  Signalling control plane  p. 42

6.5.3.1  General  p. 42

The reference points for the SIP and HTTP signalling are described in the following subclauses.

6.5.3.2  Reference point SIP-1(between the signalling user agent and the SIP core)  p. 42

The SIP-1 reference point, which exists between the signalling user agent and the SIP core for establishing a session in support of VAL service, shall use the Gm reference point as defined in TS 23.002 (with necessary enhancements to support VAL service requirements and profiled to meet the minimum requirements for support of VAL service). The SIP-1 reference point fulfils the requirements of the GC1 reference point specified in TS 23.468. The SIP-1 reference point is used for:
  • SIP registration;
  • authentication and security to the service layer;
  • event subscription and event notification;
  • communication of the TMGI for multicast operation;
  • overload control;
  • session management; and
  • media negotiation.
Up

6.5.3.3  Reference point SIP-2 (between the SIP core and the SIP AS)  p. 42

The SIP-2 reference point, which exists between the SIP core and the SIP AS for establishing a session in support of VAL service, shall use the ISC and Ma reference points as defined in TS 23.002. The SIP-2 reference point is used for:
  • notification to the VAL service server(s) of SIP registration by the VAL UE;
  • authentication and security to the service layer;
  • event subscription and event notification;
  • communication of the TMGI for multicast operation;
  • session management; and
  • media negotiation.
Up

6.5.3.4  Reference point SIP-3 (between the SIP core and SIP core)  p. 42

The SIP-3 reference point, which exists between one SIP core and another SIP core for establishing a session in support of VAL service, shall use the Mm and ICi reference points as defined in TS 23.002. The SIP-3 reference point is used for:
  • event subscription and event notification;
  • session management; and
  • media negotiation.

6.5.3.5  Reference point HTTP-1 (between the HTTP client and the HTTP proxy)  p. 42

The HTTP-1 reference point exists between the HTTP client and the HTTP proxy. Between the VAL UE and the HTTP proxy, the HTTP-1 reference point shall use the Ut reference point as defined in TS 23.002 (with necessary enhancements to support specific VAL service requirements). The HTTP-1 reference point is based on HTTP (which may be secured using e.g. SSL, TLS).

6.5.3.6  Reference point HTTP-2 (between the HTTP proxy and the HTTP server)  p. 43

The HTTP-2 reference point, which exists between the HTTP proxy and the HTTP server, is based on HTTP (which may be secured using e.g. SSL, TLS).

6.5.3.7  Reference point HTTP-3 (between the HTTP proxy and HTTP proxy)  p. 43

The HTTP-3 reference point, which exists between the HTTP proxy and another HTTP proxy in a different network, is based on HTTP (which may be secured using e.g. SSL, TLS).

6.5.3.8  Reference point AAA-1 (between the SIP database and the SIP core)  p. 43

The AAA-1 reference point, which exists between the SIP database and the SIP core, is used by the SIP core to retrieve signalling plane data from the SIP database. The AAA-1 reference point utilises the Cx reference point as defined in TS 23.002.
In some deployment scenarios the registrar and SIP database are located in the VAL service provider's network while the registrar finder is in the PLMN operator's network and the AAA-1 reference point is an inter-network interface.
Up

6.5.3.9  Reference point AAA-2 (between the SIP core and Diameter proxy)  p. 43

The AAA-2 reference point, which exists between the SIP core / IMS and Diameter proxy for SIP registration during migration, shall use the Cx reference point as defined in TS 23.002. The AAA-2 reference point is used for:
  • authentication and security to the service layer for migration;

6.5.3.10  Reference point LWP-1 (between the LWP client and the LWP proxy) |R17|  p. 43

The LWP-1 reference point exists between the LWP client and the LWP proxy.

6.5.3.11  Reference point LWP-2 (between the LWP proxy and the LWP server) |R17|  p. 43

The LWP-2 reference point exists between the LWP proxy and the LWP server.

6.5.3.12  Reference point LWP-3 (between the LWP proxy and LWP proxy) |R17|  p. 43

The LWP-3 reference point exists between the LWP proxy and another LWP proxy in a different network.

6.5.3.13  Reference point LWP-HTTP-2 (between the LWP proxy and the HTTP server) |R17|  p. 43

The LWP-HTTP-2 reference point exists between the LWP proxy and the HTTP server. HTTP-2 and LWP-HTTP-2 reference points are equivalent.

6.5.3.14  Reference point LWP-HTTP-3 (between the LWP proxy and the HTTP proxy) |R17|  p. 43

The LWP-HTTP-3 reference point exists between the LWP proxy and another HTTP proxy in a different network. HTTP-3 and LWP-HTTP-3 reference points are equivalent.

7  Identities  p. 44

7.1  User identity (User ID)  p. 44

The VAL user presents the user identity to the identity management server during a user authentication transaction, to provide the identity management client a means for VAL service authentication. In general, since identity management is a common SEAL service, it uses a set of credentials (e.g. biometrics, secureID, username/password) that may not necessarily be tied to a single VAL service. The user credentials uniquely identifies the VAL user to the identity management server.
Up

7.2  VAL user identity (VAL user ID)  p. 44

The VAL user ID is a unique identifier within the VAL service that represents the VAL user. For example, the VAL user ID may be a URI. The VAL user ID is used for authentication and authorization purposes for providing the VAL service towards the VAL user via the VAL UE. The VAL user ID also indicates the VAL service provider with whom the VAL user has a VAL service agreement. The VAL user may have VAL service agreement with several VAL service providers and thus will have obtained unique VAL user ID per VAL service provider. The VAL user ID can be used to access any SEAL service.
Based on the service agreement, VAL user ID may be mapped to a VAL UE ID.
Up

7.3  VAL UE identity (VAL UE ID)  p. 44

The VAL UE ID is a unique identifier within the VAL service that represents the VAL UE. For example, the VAL UE ID for V2X service is mapped to the StationID as specified in ETSI TS 102 894-2 [25]. The VAL UE ID is used to address the VAL UE in order to send VAL messages or to access SEAL services.
Based on the service agreement, GPSI (as specified in TS 23.003) may be used as VAL UE identity.
Up

7.4  VAL service identity (VAL service ID)  p. 44

The VAL service ID is a unique identifier that represents the VAL service. A VAL server provides a list of VAL services towards the VAL users or VAL UE. Each VAL service is uniquely identified by a VAL service ID, which is an identifier of the VAL application providing that VAL service. The VAL service ID can be used for policy mapping, QoS handling for VAL communication and VAL message distribution. For example, an identifier of a V2X service, e.g. ITS-AID or PSID specified in ETSI TS 102 965 [26] and ISO TS 17419 [27], can be used as a V2X service ID.
Up

7.5  VAL group identity (VAL group ID)  p. 44

The VAL group ID is a unique identifier within the VAL service that represents a set of VAL users or VAL UE according to the VAL service. The set of VAL users may belong to the same or different VAL service providers. It indicates the VAL application server where the group is defined.

7.6  VAL system identity (VAL system ID)  p. 44

The VAL system ID is a globally unique identifier representing a VAL system.

7.7  VAL Stream ID |R17|  p. 44

A VAL Stream ID is an identity used by the VAL server to identify a VAL stream.

Up   Top   ToC