Content for  TS 23.434  Word version:  19.3.0

This functional entity acts as the SIP user agent (both client and server) for all SIP transactions.

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.

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.

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.

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

This functional entity acts as the client for all hypertext transactions.

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.

This functional entity acts as the HTTP server for all hypertext transactions.

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.

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.

This functional entity acts as the LWP server for all LWP transactions of the SEAL server.