WO2024110004A1

WO2024110004A1 - Methods, apparatus and computer-readable media related to forwarding, receiving, and sending messages in a communications network

Info

Publication number: WO2024110004A1
Application number: PCT/EP2022/082525
Authority: WO
Inventors: Rémi ROBERT; Saranya NATARAJAN; Mukesh THAKUR
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-11-21
Filing date: 2022-11-21
Publication date: 2024-05-30

Abstract

A method is performed by a network node for forwarding a message. The method comprises: receiving a message for a first identity; determining a mapping between the first identity and a User Equipment (UE) managing the first identity; determining whether Internet Protocol (IP) Multimedia Subsystem (IMS), is available for the UE; and responsive to a determination that IMS is available for the UE, forwarding the message to the UE using IMS.

Description

METHODS, APPARATUS AND COMPUTER-READABLE MEDIA RELATED TO FORWARDING, RECEIVING, AND SENDING MESSAGES IN A COMMUNICATIONS NETWORK

Technical field

Embodiments of the present disclosure relate to communications networks, and particularly to forwarding, receiving, and sending messages in a communications network.

Background

A self-sovereign identity (SSI) ecosystem is summarized in figure 1. In the SSI ecosystem, an individual owns a self-sovereign identity, meaning that they own some digital credentials that are securely stored in and managed through an edge agent, which may be hosted by or may be a smartphone. When they want to leverage this identity in their relationship with a third party (e.g., identify & authenticate themselves, share credentials, etc.) their edge agent needs to communicate with the third party’s edge agent. For several reasons (e.g., privacy, availability, etc.), this edge-agent to edge-agent communication is not direct but often goes through intermediary cloud agents using, for example, a DIDComm protocol. This protocol is used to perform peer- to-peer messaging between edge agents, and contains details regarding message routing, including details about the intermediary cloud agents.

Internet Protocol (IP) Multimedia Subsystem (IMS) is a 3GPP standardized IP-based service engine for communication services. On top of the basic phone calls and messaging services, the IMS can host applications to provide additional services to subscribers. An example of such services is the Rich Communication Services (RCS) that aim to provide subscribers with advanced messaging capabilities. From a technical point of view, the key technology behind IMS is the Session Initiation Protocol (SIP) and associated protocols (e.g., Session Description Protocol and Message Session Relay Protocol).

In US2017/0302663A1 , some information about a network node is recorded in a blockchain (i.e., its identity). This information is leveraged by a device in a network to authenticate and control the behaviour of the node connecting to the network. Summary

There currently exist certain challenges. For example, there is currently no standard for communication between an edge agent and a cloud agent. As a result, the protocol between these components is most likely to be proprietary, which creates an undesirable coupling between the cloud and edge agents. For example, this could lead to obsolescence of the edge agent if the cloud agent is decommissioned, or lock-in for the end user.

Moreover, tackling this problem solely at the application layer is inefficient. For instance, sending a push message from a cloud agent to an edge agent would need either Operating System or Application-level solutions. Such solutions would most likely be proprietary and potentially decrease the smartphone battery life if incorrectly implemented.

Furthermore, such architecture would likely require end-users to rent cloud agent services from an additional service provider, generating additional costs for end-users. Such service providers may be difficult to find, as they need to be trusted with a potentially critical service.

According to a first aspect of the present disclosure, there is provided a method performed by a network node for forwarding a message. The method comprises: receiving a message for a first identity; and determining a mapping between the first identity and a User Equipment (UE) managing the first identity. The method further comprises: determining whether IMS is available for the UE; and responsive to a determination that IMS is available for the UE, forwarding the message to the UE using IMS.

According to a second aspect of the present disclosure, there is provided a method performed by a UE for receiving a message. The method comprises receiving, from a network node, using IMS, a message for a first identity managed by a first identity management agent hosted by the UE. The method further comprises providing the message to the first identity management agent.

According to a third aspect of the present disclosure, there is provided a method performed by a network node for forwarding a message. The method comprises: receiving, from a UE, a message for a second identity using IMS; and determining a mapping between the second identity and a next hop towards a node hosting a second identity management agent managing the second identity. The method further comprises forwarding the message to the next hop.

According to a fourth aspect of the present disclosure, there is provided a method performed by a UE for sending a message. The method comprises determining whether IMS is available for the UE. The method further comprises, responsive to determining that IMS is available for the UE, sending, to a network node, a message for a second identity managed by a second identity management agent hosted by a node.

According to a fifth aspect of the present disclosure, there is provided a network node for forwarding a message. The network node comprises processing circuitry configured to: receive a message for a first identity; and determine a mapping between the first identity and a UE managing the first identity. The processing circuitry is further configured to: determine whether IMS is available for the UE; and responsive to a determination that IMS is available for the UE, forward the message to the UE using IMS.

According to a sixth aspect of the present disclosure, there is provided a UE for receiving a message. The UE comprises processing circuitry configured to receive, from a network node, using IMS, a message for a first identity managed by a first identity management agent hosted by the UE. The processing circuitry is further configured to provide the message to the first identity management agent.

According to a seventh aspect of the present disclosure, there is provided a network node for forwarding a message. The network node comprises processing circuitry configured to: receive, from a UE, a message for a second identity using IMS; and determine a mapping between the second identity and a next hop towards a node hosting a second identity management agent managing the second identity. The processing circuitry is further configured to forward the message to the next hop.

According to an eight aspect of the present disclosure, there is provided a UE for sending a message. The UE comprises processing circuitry configured to determine whether IMS is available for the UE. The processing circuitry is further configured to, responsive to determining that IMS is available for the UE, send, to a network node, a message for a second identity managed by a second identity management agent hosted by a node. Examples provided herein may leverage existing IMS infrastructure to enable communication between cloud and edge agents. This may be a cost-effective way to create a high availability communication channel for a potentially critical service.

Furthermore, many end-users of devices such as UEs and smartphones may already have a mobile subscription from an operator they already trust for their communication. As a result, examples of this disclosure may provide an end-user with a trusted entity with whom they already have a relationship with, and who can provide a service with a high-level of availability, compatibility and at a reasonable cost.

Examples of this disclosure may leverage only standard technologies, fostering diversity in the SSI ecosystem.

Brief description of the drawings

For a better understanding of examples of the present disclosure, and to show more clearly how the examples may be carried into effect, reference will now be made, by way of example only, to the following drawings in which:

Figure 1 is a schematic diagram illustrating a self-sovereign identity ecosystem;

Figure 2 is a schematic flowchart showing a method in accordance with some embodiments;

Figure 3 is a schematic flowchart showing a method in accordance with some embodiments;

Figure 4 is a schematic flowchart showing a method in accordance with some embodiments;

Figure 5 is a schematic flowchart showing a method in accordance with some embodiments.

Figure 6 is a schematic diagram illustrating a system in accordance with some embodiments;

Figure 7 is a schematic diagram illustrating a system in accordance with some embodiments;

Figure 8 is a schematic diagram illustrating an exemplary RCS client architecture for implementing the embodiments herein;

Figures 9A and 9B are a signalling diagram illustrating procedures for edge agent registration, incoming message processing, and outgoing message processing;

Figure 10 is a signalling diagram illustrating a procedure for edge agent registration; and Figure 11 is a signalling diagram illustrating a procedure for incoming message processing.

Detailed description

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Examples of the present disclosure propose methods (and apparatus on which these methods may be implemented) of communication between different identity management agents, such that messages can be directed towards an owner of an identity managed by an identity management agent. An identity management agent may also be referred to in some examples as an edge agent, and may in some examples be hosted by a node or UE (e.g., a smartphone). The communication may in some examples involve messages being transmitted between network nodes which are (directly) connected to UEs hosting identity management agents, and this connection may in some examples be via IMS where IMS is available for the UE. The network nodes may be referred to as cloud agents or IMS agents.

A mapping (which may be stored in a mapping database) between an identifier associated with a UE/node hosting an identity management agent and an identity managed by the agent can in some examples be used by network nodes for routing purposes (i.e., for forwarding messages). That is, the mapping can be used by network nodes to ensure that a message intended for an owner of a first identity managed by a first identity management agent is sent to the network node hosting that first agent.

As such, in some examples, existing IMS infrastructure can be used for communication between identity management agents managing various identities, such as user or subscriber identities.

In examples of this disclosure, the sending, forwarding and receiving of messages is described. These messages may be for example identity management messages, SSI management messages, DIDComm messages and/or any other type of identity-related messages. That is, for example, messages may relate to identities such as SSIs or may be message to manage, use or authenticate identities.

Figure 2 is a schematic flowchart showing a method 200 performed by a network node for forwarding a message. The network node may be for example a core network node or a Radio Access Network (RAN) node.

The method 200 begins at step 202, with the network node receiving a message (e.g., a DIDComm message) for a first identity (e.g., an SSI). In some examples, the message may be received from a second identity, a second identity management agent managing the second identity, or a node hosting the second identity management agent managing the second identity. In some examples, the message identifies the first identity, such that the network node is made aware of the ultimate destination of the message.

In some examples, in order to manage the first identity, the UE may host a first identity management agent (e.g., an Edge Agent) that manages the first identify.

In step 204, the network node determines a mapping between the first identity and a UE managing the first identity. In some examples, the mapping may be retrieved from a mapping database. In some examples, prior to step 204, the network node may receive, from the UE, a request to register the first identity management agent, wherein the request identifies the first identity. The network node may then store a mapping between the UE and the first identity in the mapping database. Thus, in this way, for example, the network node performing the method 200 may be made aware of the UE which manages the first identity (e.g. hosts a first identity management agent managing the first identity) and therefore knows to forward messages for the first identity to the UE.

For example, the network may store (in the mapping database) a mapping between an identifier associated with the UE and the first identity. The identifier associated with the UE may be for example an international mobile subscriber identity (IMSI), a Mobile Station Integrated Services Digital Network (MSISDN), and/or a Globally Routable User Agent Uniform resource identifier (GRUU).

In some examples, the network node further performs an authentication procedure with an identity service providerto authenticate the first identity (e.g., after receiving a request to register the first identity management agent). Such a step may in some examples aid in preventing hijacking of the messages by an impersonator.

In step 206, the network node determines whether IMS is available for the UE. In some examples, this may comprise determining whether the UE is registered for IMS, and/or whether a UE registration for IMS has expired. In some examples, this may comprise querying a presence server to determine whether IMS is available for the UE.

Responsive to a determination that IMS is available for the UE, in step 208, the network node forwards the message to the UE using IMS.

On the other hand, in some examples, the network node may choose any of the following options for handling the message responsive to a determination that IMS is not available for the UE. For example, the network node may forward the message to the UE via a Short Message Service (SMS) or Multimedia Messaging Service (MMS). The network node may also store the message for the first identity until IMS is available for the UE, and forward the message to the UE using IMS (once it is available). The network node may also send a notification to the UE to cause the UE to establish IMS connectivity, and forward the message to the UE using IMS (once the IMS connectivity is established). For example, the notification may indicate to the UE that a message is waiting to be delivered to the UE for the first identity, and this may prompt the UE to establish IMS connectivity in order to receive the message.

Figure 3 is a schematic flowchart showing a method 300 performed by a UE for receiving a message.

The method begins at step 302, with the UE receiving, from a network node, using IMS, a message (e.g., a DIDComm message) for a first identity (e.g., an SSI) managed by a first identity management agent hosted by the UE. In some examples, the network node may be a core network node or a RAN node. In some examples, the message originates from a second identity management agent, which may in some examples be hosted by a node different to the network node from which the message is received.

In step 304, the UE provides the message to the first identity management agent. In some examples, the message identifies the first identity, such that the UE is made aware of the ultimate destination of the message. In some embodiments, prior to step 302, the UE receives, from the network node, a notification, such as for example a notification that a message for the first identity is waiting to be delivered to the UE via IMS. Responsive to receiving the notification, the UE may establish IMS connectivity with the network node.

Additionally or alternatively, prior to step 302, the UE may send, to the network node, a registration request to register the first identity management agent. The request may identify the first identity.

Figure 4 is a schematic flowchart showing a method 400 performed a network node for forwarding a message.

The method begins at step 402, with the network node receiving, from a UE, a message (e.g., a DIDComm message) for a second identity (e.g., an SSI) using IMS. In some examples, the network node may be a core network node or a RAN node. In some examples, the message identifies the second identity, such that the network node is made aware of the ultimate destination of the message.

At step 404, the network node determines a mapping between the second identity and a next hop towards a node hosting a second identity management agent managing the second identity. The next hop may in some examples be an intermediary network node of a chain of network nodes along a network path, wherein the final node of the chain is the ultimate destination of the message (i.e., the node hosting the second identity management agent). In some examples, however, the next hop may be the node hosting the second identity management agent. In some examples, the network node may be the node hosting the second identity management agent or the node managing the second identity. In such examples, the next “hop” may simply be the second identity management agent.

In some examples, the network node further receives, from an identity service provider, an association between the node managing the second identity and the second identity. As such, in some examples, determining the mapping between the second identity and the next hop towards a node managing the second identity may comprise determining the mapping based on the association. In step 406, the network node forwards the message to the next hop.

Figure 5 is a schematic flowchart showing a method 500 performed by a UE for sending a message.

The method begins at step 502, with the UE determining whether IMS is available for the UE. This may comprise, for example, determining whether the UE is registered for IMS, and/or whether a UE registration for IMS has expired. This may in some examples comprise querying a presence server.

Responsive to determining that IMS is available for the UE, in step 504, the UE sends, to a network node, a message (e.g., a DIDComm message) for a second identity (e.g., an SSI). The second identity is managed by a second identity management agent (e.g., an Edge Agent) hosted by a node.

The network node and/or the node hosting the second identity management agent may be a core network node or a RAN node.

In some examples, the message identifies the second identity, such that the node is made aware of the ultimate destination of the message.

The following provides particular detailed examples of the above general concepts, for illustrative purposes.

In the context of a self-sovereign identity ecosystem, in some examples, a user may be expected to interact with other entities’ edge agents (or identity management agents) using their own edge agent (or identity management agent, e.g., hosted by their UE or mobile phone). For some of these interactions, it is desirable for these agent-to-agent interactions to be performed in real time and to be resilient.

For instance, when registering to a website, a user may enter their identity identifier on the website, and the website’s agent may send an information request message (e.g., through the DIDComm protocol) to the user’s edge agent. The user can then verify and accept the request through an application on their mobile phone to complete the registration. In order to preserve the user’s privacy, the request from the website’s agent is not typically sent directly to the edge agent. Instead, it goes through the user’s cloud agent (e.g. an IMS agent, or the network node referred to above with reference to figures 2-5). The IMS agent can then forward the request to the edge agent on the UE/mobile phone.

When a user has mobile data enabled on their mobile phone, and IMS is available for the mobile phone, an IMS agent is able to effectively forward DIDComm messages over IP, leveraging the existing IMS session. When the user does not have mobile data enabled, the IMS agent is able to use a fallback transport mechanism (for instance SMS or MMS) in order to deliver the DIDComm message to the UE. Similarly, the UE is also able to respond using this fallback transport or, if possible, enable mobile data and then respond using the IP transport (e.g. in response to a notification from the IMS agent that a message is waiting to be delivered).

Further, in some examples taking advantage of existing multi-device capabilities of the IMS applications, the IMS agent could also possibly deliver the DIDComm message not only to one device, but to all the UEs/mobile devices on which the user has installed an edge agent.

In order to achieve the above, proposed examples define a component acting as a gateway between the existing “internet” transports for the DIDComm protocol and new “telco” transports available within the mobile networks. Such components would implement the following methods:

• Registration of a subscriber edge agent (e.g. hosted by a UE), creating a mapping between their self-sovereign identities and their subscriber identifiers within the mobile network

• Identification of the actions to take upon the reception of an incoming DIDComm messages from the self-sovereign identity ecosystem

• Adaptation and transmission of the DIDComm message to the appropriate edge agent residing in a UE

In further detail, the present disclosure describes a node, and associated methods, for an IMS implementation of a cloud agent (e.g., an IMS agent,) in a SSI ecosystem. This node allows for the flexible and effective transport of DIDComm messages destined to an edge agent running on a UE, in a standard way. This node may be an example of the network node performing the method 200 of figure 2 and/or or the method 400 of figure 4 in some examples.

An example of the operation of this node can be summarized as follows:

1) Registration of the edge agent: the cloud agent (e.g., the IMS agent) authenticates a subscriber identity (e.g., an International Mobile Subscriber Identity (IMSI)) indicated in a registration request coming from the edge agent application in the UE, authenticates an identity (e.g., an SSI) of the edge agent owner, and creates a mapping between these identities.

2) Incoming message(s) processing: the cloud agent processes an incoming message (e.g., a DIDComm message), and identifies the edge agent it is destined to (e.g., the agent responsible for managing the SSI identity). Then, using the mapping created in the registration step, the cloud agent identifies the UE hosting the edge agent. Based on the state of this UE (i.e., its connectivity status or IMS availability status), the cloud agent identifies an action to take (e.g., store or forward the message, decide which transport to use for the delivery, etc.).

3) Message delivery: In this step, the cloud agent adapts and delivers the incoming message(s) to the UE hosting the edge agent. The original message is then reconstructed by the UE, where applicable, and passed to the edge agent.

Figure 6 illustrates components of a system operating in accordance with some embodiments. For example, the system may include one or more of the following components:

- A third party agent 602: This may be an example of the second identity management agent referred to above in some examples. This may be a Trust over IP agent supporting standard protocols. In some examples, it may either be a sender of a message ultimately destined to an edge agent, or a recipient of a message sent by the edge agent. This node may exchange DIDComm messages with the IMS agent over existing “internet” DIDComm transports (e.g., HTTP, WebSocket). This component may correspond to the right-hand side cloud agent in figure 1 .

- An IMS Agent 604: This may be an example of the network node performing the method 200 or 400 in some examples. In a Trust over IP context, this node may operate as a cloud/routing agent. It exposes a stable endpoint that others can use to send a message to an edge agent to which the IMS agent is connected (which lacks such a stable endpoint). In some examples, in order to forward an incoming message (e.g., a DIDComm message) to the edge agent, this node is able to establish a mapping between the recipient of the incoming message and the telecom identity of the UE hosting this edge agent. The IMS agent may store and fetch this mapping with the help of a mapping database (discussed below). The IMS agent may communicate with an edge agent hosted on the UE through standard protocols for both registration and (DIDComm) message delivery. This component may correspond to the left-hand side cloud agent in figure 1 .

- A mapping database 606: This node may be used to contain: mappings between identities in a Trust over IP domain; and the identity of the UE/subscriber holding a corresponding edge agent in a mobile network.

- An edge agent 608: This may be an example of the UE (or a function of the UE) performing the method 300 and/or 500 of figure 3 and/or 5. This node may operate as a standard edge agent in a Trust over IP context. It may be hosted on a UE. In some examples, in addition to existing protocols such as for example internet protocols and/or Trust over IP (TolP) protocols, this node also leverages telco interfaces (e.g., 3GPP standards) to support more efficient message delivery. This component may correspond to the left-hand side edge agent in figure 1 .

Figure 7 illustrates, in further detail to figure 6 discussed above, components of a system operating in accordance with some embodiments. For example, in addition to the previously discussed components, the system may include one or more of the following components: a Mobile Network 702; and a UE 704 running the Edge Agent and using standard interfaces to communicate with the IMS agent.

The mobile network 702 may comprise an IMS 706, and an IMS agent may be implemented as an IMS application, interfacing with other IMS applications and functions. Below is a discussion of one or more components relating to the IMS which may be implemented in the mobile network:

- An IMS Agent 708 (e.g. the network node performing the method 200 or 400 in some examples): this may be hosted by the IMS, and may be implemented as an IMS Application Server. This server may also be connected to a mapping database used to store the mappings between telco and SSI/TolP identities. This mapping database may be a new node (possibly internal to the application server) or it could be implemented as an addition to an existing node (for instance a Home Subscriber Server (HSS)). Presence node 710 (e.g. the presence server referred to above): the aim of this node is to provide the IMS agent with real-time information regarding the status of the UE. The goal is to provide input for the IMS agent to decide which transport to use when delivering an incoming message to the UE. For instance, the IMS agent may send the message over SIP to a UE that is currently connected to the IMS, or it may choose to send a notification over SMS for a UE that has not been connected for a given length of time. The presence node may leverage existing IMS functions to keep track of the status of the UE (e.g., the presence server already used in the standard RCS applications).

- SIP/IP Core 712: This represents the standard IMS node(s) that can be used to send messages to the UE (e.g., using the SIP, SDP, and/or MSRP protocols).

In the mobile network 702, beyond the IMS 706 that is hosting the agent 708, two components that may interact with it are:

- an SMS Gateway 714: This node is responsible for transmitting data to the UE using legacy telecom protocols, exemplified in figure 7 as SMS. In practice this could be any non-IP-based protocol in use for communication between a UE and the mobile network.

- an Authentication Server 716: This node is responsible for the authentication of the UE (or rather of the associated subscription), when communicating with the agent application within the IMS. For example, this node may implement a Generic Bootstrapping Architecture (GBA) protocol (more particularly a Bootstrapping Server Function (BSF) function).

In figure 7, a 3GPP Client node 718 is making the interface between the clients for the standard 3GPP communication channels (SIP with the IMS, SMS) and the edge agent 720. Depending on the standard interface it exposes to the edge agent 720, this task could include some processing of the messages, or be limited to simple forwarding.

The 3GPP Client functionality may be included in the edge agent 720, with the agent taking care of processing the low-level messages to recover the DIDComm messages (and opposite).

The 3GPP client 718 may be implemented in one of the following fashions: - As a user installable application, assuming that the device Operating System (OS) exposes an open interface that it can use to communicate with the IMS agent. In such a case, the client may be either part of the edge agent (e.g., as a plugin or “driver”) or be a separate application.

- As a system application, provided as part of the OS. In such a case, the 3GPP client exposes an interface that can be used by any edge agent software in the UE.

In some examples, there may be two options to implement these components: low-level implementation (over the raw IMS stack, e.g., the IMS stack shown in figure 8) or high- level implementation (over an existing IMS messaging application, such as RCS).

Low-level

In this option, the IMS agent 708 is a standalone IMS application server, using the standard IMS protocol suite (SIP, MSRP) and core services. The 3GPP client 718 is an application running in the UE which uses the IMS Stack implemented by the Operating System of the UE to communicate with the server over the standard IMS protocol suite. Only the Operating System on the UE 722 is used to implement a standard IMS stack.

High-level

In this option, the IMS agent is not an IMS application server. Instead, it is an Application Function that uses the IMS through an exposure Application Programming Interface (API) provided by an IMS application server (e.g., the RCS API Gateway). In this context, the IMS agent does not itself use the standard IMS protocols; instead it just relies on the API exposed by the IMS application server.

The 3GPP client 718 is in some examples an application running on the UE, and it does not directly leverage the UE IMS stack. Instead, it relies on the API exposed by an IMS application client running on the UE 722 (e.g., the service API provided by the RCS). Hence, for this high-level option, such an application is available and running on the UE.

For instance, an addon to the standard RCS application may be used which leverages the standard Presence service to check the connectivity status of the UE and uses the Instant Messaging service to deliver the DIDComm messages. In such a context, the RCS application in the mobile network may expose an API (for instance a REST API) allowing the IMS agent to access the needed capabilities (e.g., check UE presence status, send instant messages, and/or receive instant messages). Similarly, on the UE, the 3GPP Client 718 would leverage the service exposed through the Service API (shown for example in Figure 8) by the RCS enablers application. In the UE, the application would separate the DIDComm messages from the regular messages and transmit them to the edge agent 720 instead of the messaging application.

Figure 8 is a schematic diagram illustrating an exemplary RCS client architecture for implementing the embodiments herein. The architecture comprises an IMS Stack 801 which contains a protocol suite (Session Initiation Protocol [SIP], Message Session Relay Protocol [MSRP], Real-Time Protocol [RTP]/Real-Time Control Protocol [RTCP], Hyper-Text Transfer Protocol [HTTP], etc.) and core services (IMS Session Management, Registration, etc).

The architecture further comprises Rich Communication Services (RCS) Enablers 803, comprising the functionality to enable RCS-based Chat, Video and Image sharing, File Transfer and other RCS services. The functionality of the RCS enabler 803 is governed by GSMA RCS specifications. Access to aforesaid functional layers (functional layers are RCS Enabler 803 and IMS Stack 801) is mediated by a RCS Services API or service API 805 (shown in Figure 8). The service API 805 is an interface used by client applications and services to access the functional layers. The RCS Core Applications or OEM UX 807 are typically embedded applications that provide an end-user’s access to the RCS services. The OEM UX 807 makes use of the Services API 805 to programmatically invoke operations that are interactively fulfilled by core applications of OEM UX 807.

The architecture is also enabled to provide an application and service extension interface 809 to make direct use of the Service API 805, enabling programmatic access to the RCS services. Thus, third party applications having appropriate permission can access the service API 805 through the application and service extension interface 809. The RCS Service API is scoped so as to make access by Third Party Applications possible subject to those applications having the appropriate permission. Transport API implementation 811 is a standard interface that enables programmatic control of functional layers to support flexible allocation of device resources 812 to support application demands and native services 814. Figures 9A and 9B are a signalling diagram illustrating example procedures for edge agent registration, incoming message processing, and outgoing message processing.

Edge Agent Registration: The aim of this method is forthe edge agent to register towards the IMS agent. As a result of this step, the IMS agent is able to discriminate incoming DIDComm messages that are destined to the edge agent and route them to the UE hosting it.

Parts of this procedure may be repeated, potentially at different times, to cover for the multiple identities that the edge agent might maintain over time. The registration may need to be repeated to map each of these identities to the subscriber identity.

The edge agent registration procedure may comprise the following steps illustrated in figures 9A and 9B:

901. The Edge Agent submits a registration request destined to the IMS Agent through the interface exposed by the 3GPP Client. The registration request contains the following information: the SSI identities for which messages should be forwarded to the edge agent, and proof of the ownership of these identities by the edge agent.

902. The 3GPP Client, Authentication Server and Edge Application Server executes authentication procedures (e.g., GBA, Authentication and key management for applications (AKMA)) allowing the edge application server to authenticate the mobile subscription used by the UE. The 3GPP client uses the materials from the authentication procedures and sends the registration request to the Agent Application Server.

903. Based on the authentication materials the Agent Application Server fetches the telco identity of the subscriber (e.g., IMSI, MSISDN). Optionally, the Agent Application Server could obtain more information about the subscriber (e.g., to check that the subscriber is entitled to use the service). Such information could for instance be included in the GBA User Security Settings (GUSS).

Based on the registration request, the Agent Application Server verifies that the edge agent is responsible for managing the requested SSI identities and extracts them. 904. The mapping between the identities extracted in step 3 are stored in the mapping database. They are stored such that it is possible to retrieve the telco identities based on any of the SSI identities (e.g., using an SSI identifier such as the DID as an index in the database).

905. The Agent Application Server sends a confirmation message to the 3GPP client.

906. The 3GPP client confirms the registration to the edge agent.

907. The IMS agent is registered as a cloud agent paired with the edge agent in the SSI/TolP ecosystem (e.g., via standard TolP cloud agent registration procedures). This allows for DIDComm messages to be sent to the edge agent, via the IMS agent.

Incoming Message Processing: The aim of this method is for the IMS agent to efficiently forward an incoming DIDComm message to the UE hosting the recipient’s edge agent. The incoming message processing procedure may comprise the following steps, as illustrated in figures 9A and 9B:

908. A third-party agent sends a DIDComm message to the Agent Application Server. Assuming correct registration of the IMS Agent in the TolP ecosystem, this is a “forward” DIDComm message destined to the IMS agent, that embeds an encrypted message destined to the edge agent.

909. Based on this outer message, the Agent Application Server extracts the identifier of the SSI that is the recipient of the embedded message.

910. Using the identifier extracted in step 9, the Agent Application Server fetches the corresponding telco subscriber identifier from the mapping database.

911. Using the subscriber identifier, the Agent Application Server fetches the subscriber status from the presence server. The status can include information such as the current state of the connectivity between the UE and IMS or some historical value for this state. 912. The Agent Application Server leverages the subscriber status from the previous step to identify the transport to use to deliver the DIDComm message to the UE. In addition to the status information, this decision may also be based on some additional information regarding the capabilities of the UE, some policies set by the edge agent, and/or the existence of an established session between the UE and Agent Application Server.

If the DIDComm message is to be delivered over the IMS (IP), the following steps may be performed, as illustrated in figures 9A and 9B:

913. The DIDComm message is adapted for delivery over the IMS using SIP, MSRP (or a new protocol). The adaptation may include deciding which protocol to use based on the size of the message, splitting the message, adding metadata around the message, changing the encoding, and/or compressing it.

914. The adapted DIDComm message is sent to the SIP/IP Core which is responsible for forwarding it to the 3GPP Client. In practice, this could be either sent as a standalone message, or require the establishment of a session and the exchange of multiple messages between UE and Agent Application Server.

915. The message is forwarded to the 3GPP client.

Else, if the message is to be delivered over a legacy protocol (exemplified here with SMS), the following the following steps may be performed, as illustrated in figures 9A and 9B:

916. The DIDComm message is adapted for delivery through the legacy protocol. The adaptation may include, for instance, the choice of the delivery protocol (e.g., MMS or SMS) and/or splitting the message.

917. The adapted DIDComm message is sent to a gateway responsible for sending the message to the 3GPP client on the UE over the legacy protocol.

918. The message is forwarded to the 3GPP client. Else, if the message is to be stored, and a notification to be sent to the 3GPP client over a legacy protocol, the following the following steps may be performed, as illustrated in figures 9A and 9B:

919. The DIDComm message is stored in the message database

920. A notification message, notifying the end-user of the availability of a DIDComm message, is prepared.

921 . The notification is sent to the legacy protocol gateway

922. The notification is forwarded to the 3GPP client on the UE.

923. The notification is sent to the edge agent, which notifies the end-user.

924. After the UE reconnects to the IMS (possibly triggered by the reception of the notification), the DIDComm message is delivered over the IMS following step 13-15, with an additional preparation step for fetching the message from the message database.

The procedure may then comprise the following steps, as illustrated in figures 9A and 9B:

925. The 3GPP client processes the received messages to recover the initial DIDComm message. This step may, for instance, include concatenating multiple message fragments, removing added metadata, changing the encoding, and/or decompressing.

926. The DIDComm message is transmitted to the edge agent.

Outgoing Message Processing: This method is an extension of the TolP stack. The outgoing message processing procedure may comprise the following steps, as illustrated in figures 9A and 9B:

927. The edge agent sends a DIDComm message to the 3GPP Client. In addition to the message, this could also include additional information. For instance, this additional information may include a request to keep the session open between the 3GPP client and the Agent Application Server in anticipation of answer message from the third-party agent (i.e., in order to optimize the return path for an answer from the third party agent).

928. The message is adapted for delivery. This step may include the choice of a transport (here we exemplify only delivery over the IMS) and/or fragmentation of the message.

929. The message is sent using the chosen delivery channel.

930. The message is forwarded to the agent application server.

931. The agent application server recovers the DIDComm message. This could include, for instance, concatenating multiple messages. The agent application server then acting as a regular cloud/routing agent decides the action to take with the message.

932. The DIDComm message is sent to a third-party agent over the internet DIDComm transport. The recipient of the message may also be served by this edge agent and the message may be sent back through the telco transport to the recipient UE.

Figure 10 is another signalling diagram illustrating an example of a procedure for edge agent registration. The procedure may comprise the following steps, as illustrated in figure 10:

1001. The IMS agent authenticates the UE hosting the edge agent using standard 3GPP protocols (e.g., AKMA or GBA). This step may also be leveraged for the UE to authenticate the IMS agent and establish a secure channel.

1002. The edge agent sends a registration request to the IMS Agent, requesting it to act as its cloud agent. The request may contain information such as the consent and authorization provided to the cloud agent, as well as the SSI identities (e.g., DIDs) for which the IMS agent will forward messages to the edge agent. Additionally, the request may also contain some parameters configuring the operation of the cloud agent (e.g., authorize delivery over SMS). 1003. Based on the authentication performed in step 1 , the IMS agent extracts the subscriber identity of the UE (e.g., I MSI , MSISDN). This may be any identifier allowing for the IMS Agent to uniquely identify the UE or associated subscriber.

1004. The IMS Agent extracts the SSI identities and verifies that the edge agent is their rightful owner. This verification may involve some interactions with the public ledger in the SSI ecosystem.

1005. The IMS agent stores the mapping between the SSI identities and the subscriber identity in an internal database (i.e., the mapping database). The data is stored in such a fashion that it is possible to recover the subscriber identity based on any of the SSI identities associated with it. The database may also store the parameters configuration the cloud agent and included in the registration request.

1006. The IMS agent confirms the creation of the cloud agent, and optionally returns data for the edge agent to update the agent policy registry.

1007. The edge agent updates the agent policy registry on the shared ledger in the SSI ecosystem to authorize the cloud agent.

Figure 11 is a signalling diagram illustrating an example of a procedure for processing incoming messages. The procedure may comprise the following steps, as illustrated in figure 11 :

1101. A third-party agent sends a DIDComm message to the IMS agent. Assuming correct registration of the IMS agent in the SSI ecosystem, this is a “forward” DIDComm message destined to the IMS agent, that embeds an encrypted message destined to the edge agent.

1102. Based on this outer message, the IMS agent identifies the SSI that is the recipient of the embedded message (i.e., the SSI identity)

1103. The IMS agent fetches the subscriber identity corresponding to this SSI identity in its mapping database. In addition to just the subscriber identity, the IMS agent may also retrieve the parameters governing its operation as a cloud agent for this user.

1104. Based on the recipient, and the result of the query to the mapping database, the IMS agent decides whether to forward (if a subscriber ID was found in the mapping database) or drop (if the query returned no entry) the DIDComm message.

1105. Leveraging the presence server, the IMS agent fetches the connectivity status of the UE. By leveraging other exposure functions from the mobile network, the IMS agent can fetch additional information about the current situation of the UE (e.g., geographic location).

1106. Based on the configuration parameters, and the connectivity status of the UE, the IMS agent decides on how to handle the message: a. If the UE is registered towards the IMS: i. The IMS agent sends the message over the IMS to the UE; b. Otherwise: i. If allowed by the configuration:

1 . The IMS agent sends the message over a fallback protocol (e.g., SMS) to the UE; ii. Otherwise:

1 . The IMS agent stores the message in the message database;

2. Optionally, depending on the configuration, the IMS agent; sends a notification to the UE; and

3. Optionally, the IMS agent sends the message over IP connectivity once the UE reconnects.

The remaining steps 1107-1115 are self-explanatory and/or are similar to similar steps described above.

The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended embodiments. The word “comprising” does not exclude the presence of elements or steps other than those listed in an embodiment or claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the embodiments. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1 . A method (200) performed by a network node for forwarding a message, the method comprising: receiving (202) a message for a first identity;

- determining (204) a mapping between the first identity and a User Equipment, UE, managing the first identity;

- determining (206) whether Internet Protocol, IP, Multimedia Subsystem, IMS, is available for the UE; and responsive to a determination that IMS is available for the UE, forwarding (208) the message to the UE using IMS.

2. The method according to claim 1 , wherein the UE hosts a first identity management agent that manages the first identify.

3. The method according to any one of claims 1-2, wherein determining whether IMS is available for the UE comprises determining whether the UE is registered for IMS, and/or whether a UE registration for IMS has expired.

4. The method according to any one of claims 1-3, wherein, responsive to a determination that IMS is not available for the UE, the method further comprises any one of:

- forwarding the message to the UE via a Short Message Service, SMS, or Multimedia Messaging Service, MMS;

- storing the message for the first identity until IMS is available for the UE, and forwarding the message to the UE using IMS; and

- sending a notification to the UE to cause the UE to establish IMS connectivity, and forwarding the message to the UE using IMS.

5. The method according to any one of claims 1-4, further comprising: receiving, from the UE, a request to register the first identity management agent, wherein the request identifies the first identity; and

- storing a mapping between the UE and the first identity in a mapping database.

6. The method according to claim 5, further comprising: performing an authentication procedure with an identity service provider to authenticate the first identity.

7. The method according to any one of claims 5-6, wherein storing the mapping between the UE and the first identity in the mapping database comprises storing a mapping between an identifier associated with the UE and the first identity in the mapping database.

8. The method according to any one of claims 5-7, wherein the identifier associated with the UE is an international mobile subscriber identity, IMSI, a Mobile Station Integrated Services Digital Network, MSISDN, and/or a Globally Routable User Agent Uniform resource identifier, GRUU.

9. The method according to any one of claims 1 -8, wherein the first identity is a selfsovereign identity, SSI.

10. The method according to any one of claims 1-9, wherein the message identifies the first identity.

11. The method according to any one of claims 1-10, wherein the message comprises a DIDComm message.

12. The method according to any one of claims 1-11 , wherein the message is received from a second identity, a second identity management agent managing the second identity, or a node hosting the second identity management agent managing the second identity.

13. The method according to any one of claims 1-12, wherein the network node is a core network node or a Radio Access Network, RAN, node.

14. A method (300) performed by a user equipment, UE, for receiving a message, the method comprising: receiving (302), from a network node, using Internet Protocol, IP, Multimedia Subsystem, IMS, a message for a first identity managed by a first identity management agent hosted by the UE; and providing (304) the message to the first identity management agent.

15. The method according to claim 14, further comprising: receiving, from the network node, a notification; and responsive to receiving the notification, establishing IMS connectivity.

16. The method according to any one of claims 14-15, further comprising:

- sending, to the network node, a registration request to registerthe first identity management agent, wherein the request identifies the first identity.

17. The method according to any one of claims 14-16, wherein the first identity is a self-sovereign identity, SSI.

18. The method according to any one of claims 14-17, wherein the message identifies the first identity.

19. The method according to any one of claims 14-18, wherein the message comprises a DIDComm message.

20. The method according to any one of claims 14-19 wherein the message originates from a second identity management agent.

21. The method according to any one of claims 14-20, wherein the network node is a core network node or a Radio Access Network, RAN, node.

22. A method (400) performed by a network node for forwarding a message, the method comprising: receiving (402), from a User Equipment, UE, a message for a second identity using Internet Protocol, IP, Multimedia Subsystem, IMS;

- determining (404) a mapping between the second identity and a next hop towards a node hosting a second identity management agent managing the second identity; and

- forwarding (406) the message to the next hop.

23. The method according to claim 22, further comprising: receiving, from an identity service provider, an association between the node managing the second identity and the second identity; wherein determining a mapping between the second identity and the next hop towards a node managing the second identity comprises determining the mapping based on the association.

24. The method according to any one of claims 22-23, wherein the second identity is a self-sovereign identity, SSI.

25. The method according to any one of claims 22-24, wherein the message identifies the second identity.

26. The method according to any one of claims 22-25, wherein the message comprises a DIDComm message.

27. The method according to any one of claims 22-26, wherein the node is a core network node or a Radio Access Network, RAN, node.

28. A method (500) performed by a User Equipment, UE, for sending a message, the method comprising:

- determining (502) whether Internet Protocol, IP, Multimedia Subsystem, IMS, is available for the UE; and responsive to determining that IMS is available for the UE, sending (504), to a network node, a message for a second identity managed by a second identity management agent hosted by a node.

29. The method according to claim 28, wherein the message identifies the second identity.

30. The method according to any one of claims 28-29, wherein the second identity is a self-sovereign identity, SSI.

31. The method according to any one of claims 28-30, wherein the message comprises a DIDComm message.

32. The method according to any one of claims 28-31 , wherein:

- the network node is a core network node or a Radio Access Network, RAN, node; and/or

- the node is a core network node or a RAN node.

33. A network node for forwarding a message, the network node comprising processing circuitry configured to: receive (202) a message for a first identity;

- determine (204) a mapping between the first identity and a User Equipment, UE, managing the first identity;

- determine (206) whether Internet Protocol, IP, Multimedia Subsystem, IMS, is available for the UE; and responsive (208) to a determination that IMS is available for the UE, forward the message to the UE using IMS.

34. The network node according to claim 33, wherein the UE hosts a first identity management agent that manages the first identify.

35. The network node according to any one of claims 33-34, wherein being configured to determine whether IMS is available for the UE comprises being configured to determine whether the UE is registered for IMS, and/or whether a UE registration for IMS has expired.

36. The network node according to any one of claims 33-35, wherein, responsive to a determination that IMS is not available for the UE, the network node further comprises processing circuitry configured to perform any one of:

37. The network node according to any one of 33-36, further comprising processing circuitry configured to: receive, from the UE, a request to register the first identity management agent, wherein the request identifies the first identity; and

- store a mapping between the UE and the first identity in a mapping database.

38. The network node according to claim 37, further comprising processing circuitry configured to: perform an authentication procedure with an identity service provider to authenticate the first identity.

39. The network node according to any one of claims 37-38, wherein being configured to store the mapping between the UE and the first identity in the mapping database comprises being configured to store a mapping between an identifier associated with the UE and the first identity in the mapping database.

40. The network node according to any one of claims 37-39, wherein the identifier associated with the UE is an international mobile subscriber identity, IMSI, a Mobile Station Integrated Services Digital Network, MSISDN, and/or a Globally Routable User Agent Uniform resource identifier, GRUU.

41 . The network node according to any one of claims 33-40, wherein the first identity is a self-sovereign identity, SSI.

42. The network node according to any one of claims 33-41 , wherein the message identifies the first identity.

43. The network node according to any one of claims 33-42, wherein the message comprises a DIDComm message.

44. The network node according to any one of claims 33-43, wherein the message is received from a second identity, a second identity management agent managing the second identity, or a node hosting the second identity management agent managing the second identity.

45. The network node according to any one of claims 33-44, wherein the network node is a core network node or a Radio Access Network, RAN, node.

46. A user equipment, UE, for receiving a message, the network node comprising processing circuitry configured to: receive (302), from a network node, using Internet Protocol, IP, Multimedia Subsystem, IMS, a message for a first identity managed by a first identity management agent hosted by the UE; and provide (304) the message to the first identity management agent.

47. The UE according to claim 46, further comprising processing circuitry configured to: receive, from the network node, a notification; and responsive to receiving the notification, establish IMS connectivity.

48. The UE according to any one of claims 46-47, further comprising processing circuitry configured to:

- send, to the network node, a registration request to register the first identity management agent, wherein the request identifies the first identity.

49. The UE according to any one of claims 46-48, wherein the first identity is a selfsovereign identity, SSI.

50. The UE according to any one of claims 46-49, wherein the message identifies the first identity.

51. The UE according to any one of claims 46-50, wherein the message comprises a DIDComm message.

52. The UE according to any one of claims 46-51 wherein the message originates from a second identity management agent.

53. The UE according to any one of claims 46-52, wherein the network node is a core network node or a Radio Access Network, RAN, node.

54. A network node for forwarding a message, the network node comprising processing circuitry configured to: receive (402), from a User Equipment, UE, a message for a second identity using Internet Protocol, IP, Multimedia Subsystem, IMS;

- determine (404) a mapping between the second identity and a next hop towards a node hosting a second identity management agent managing the second identity; and

- forward (406) the message to the next hop. The network node according to claim 54, further comprising processing circuitry configured to: receive, from an identity service provider, an association between the node managing the second identity and the second identity;

- wherein being configured to determine a mapping between the second identity and the next hop towards a node managing the second identity comprises being configured to determine the mapping based on the association. The network node according to any one of claims 54-55, wherein the second identity is a self-sovereign identity, SSI. The network node according to any one of claims 54-56, wherein the message identifies the second identity. The network node according to any one of claims 54-57, wherein the message comprises a DIDComm message. The network node according to any one of claims 54-58, wherein the node is a core network node or a Radio Access Network, RAN, node. A User Equipment, UE, for sending a message, the UE comprising processing circuitry configured to:

- determine (502) whether Internet Protocol, IP, Multimedia Subsystem, IMS, is available for the UE; and responsive to determining that IMS is available for the UE, send (504), to a network node, a message for a second identity managed by a second identity management agent hosted by a node. The UE according to claim 60, wherein the message identifies the second identity. The UE according to any one of claims 60-61 , wherein the second identity is a self-sovereign identity, SSI. The UE according to any one of claims 60-62, wherein the message comprises a DIDComm message. The UE according to any one of claims 60-63, wherein:

- the network node is a core network node or a Radio Access Network, RAN, node; and/or - the node is a core network node or a RAN node.