Message bus for transfer of tokens

Abstract

Examples of the invention relate to a message bus for the transfer of tokens from a client device to an AI entity. The message bus (100) receives a first request (510) from an AI entity (400) associated with an AI service. The first request (510) indicates a request for a transfer of a set of tokens (120) from a client device (310) of a mobile network (300) to the AI entity (400) and a time limit associated with the transfer of the set of tokens (120). The message bus (100) therefore selects a first token transfer procedure (610) or a second token transfer procedure (620) for the transfer of the set of tokens (120) based on the time limit. The first token transfer procedure comprises the transfer of the set of tokens (120) from the client device (310) to the AI entity (400) via a control plane of the mobile network (300). The second token transfer procedure comprises the transfer of the set of tokens (120) from the client device (310) to the AI entity (300) via a user plane of the mobile network (300). Furthermore, examples of the invention also relate to an AMF, a SMF, corresponding methods and a computer program.

Description

[0001] MESSAGE BUS FOR TRANSFER OF TOKENS

[0002] TECHNICAL FIELD

[0003] Examples of the invention relate to a message bus for the transfer of tokens from a client device to an Al entity. Furthermore, examples of the invention also relate to an AMF, a SMF, corresponding methods and a computer program.

[0004] BACKGROUND

[0005] Generative artificial intelligence (Al) entities, e.g., large language model (LLM), visual language model (VLM), vison transformers (ViT) etc., need to receive input tokens from a client application in order to perform inference on their tasks. The client application is usually located on the user equipment (UE) side while the Al entity is commonly located in the cloud and interconnected via a mobile network. Thus, tokens need to travel from the UE side to the Al entity via the mobile network.

[0006] Tokens encode different information, such as the user input or sensor information collected on the UE-side, e.g., position, light detection and ranging (LIDAR) information, camera stream, etc. Examples of input that needs to be encoded in tokens and relevant application context are: text used to query a request to a chat based LLM; image of the scene viewed by a robot to be sent to a VLM or ViT; and LIDAR and other sensor information required by a robot to understand the context and what is the action to be done in that context, or to make a high-level plan of actions, usually processed by a very large LLM.

[0007] SUMMARY

[0008] An objective of examples of the invention is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

[0009] Another objective of examples of the invention is to provide a solution for transfer of tokens from a client application to an Al entity with a guaranteed transfer time when the transfer happens in a mobile network.

[0010] The above and further objectives are solved by the subject matter of the independent claims.

[0011] Further examples of the invention can be found in the dependent claims.

[0012] According to a first aspect of the invention, the above mentioned and other objectives are achieved with a message bus configured to:

[0013] receive a first request from an artificial intelligence, Al, entity associated with an Al service, the first request indicating a request for a transfer of a set of tokens from a client device of a mobile network to the Al entity and a time limit associated with the transfer of the set of tokens; and

[0014] select a first token transfer procedure or a second token transfer procedure for the transfer of the set of tokens based on the time limit, wherein

[0015] the first token transfer procedure comprises the transfer of the set of tokens from the client device to the Al entity via a control plane of the mobile network, and

[0016] the second token transfer procedure comprises the transfer of the set of tokens from the client device to the Al entity via a user plane of the mobile network.

[0017] An advantage of the message bus according to the first aspect is that - by evaluating the estimated transfer time for the set of tokens using the first or the second token transfer procedure - the message bus can decide which procedure is more convenient for the token transfer with respect to the requested time limit for the set of tokens, and thereby choose which procedure best suits the application requirements. The message bus may also consider other aspects for selecting token transfer procedure such as the message bus configuration, allocated resources, expected traffic volume for the tokens, other network conditions etc.

[0018] In an implementation form of a message bus according to the first aspect, the time limit is based on a first time instance when the client device starts transmitting the set of tokens and a second time instance when the Al entity receives the set of tokens.

[0019] An advantage with this implementation form is that the message bus has knowledge of the end-to-end time limit requirement, involving the transfer of the set of tokens from its source to the intended destination, for improved selection of token transfer procedure.

[0020] Another advantage with this implementation form, for the consumer of the set of tokens, such as LLM, VLM, and ViT, is that it can set up delivery deadlines for each set of tokens that it expects to receive from the client device. Since the message bus can estimate the time that the tokens need to traverse the network segment between the client device and the Al entity, it can decide whether the time limit can be met or not. This enables the consumer to know in advance if the tokens will be delayed more than allowed. Thus, it also enables the message bus to scale up / down the size the resources in the message bus accordingly, in order to decrease the time for a token to traverse the message bus and make sure the delay is within the consumer budget. It also enables the message bus - in case of the second token transfer procedure - to request sufficient network resources, by requesting quality-of-service (QoS) that can keep the network latency for the token delivery below the allowed limits, so that the maximum delay budget for the tokens can be fulfilled. Also, in case of the first token transfer procedure, the message bus could request the access node network to configure control plane resources that would keep the network latency for the token delivery below the allowed limits, such as a proper schedule of CG-based resources that could be used by the client device to send the tokens.

[0021] In an implementation form of a message bus according to the first aspect, the selection of the first token transfer procedure or the second token transfer procedure comprises:

[0022] select the first token transfer procedure or the second token transfer procedure meeting the time limit.

[0023] In an implementation form of a message bus according to the first aspect, the message bus is configured to:

[0024] select the first token transfer procedure or the second token transfer procedure further based on: a volume of the set of tokens, and a periodicity of the transfer of the set of tokens.

[0025] An advantage with this implementation form is that the selection of the transfer procedure within the network segment of the communication / mobile network can also be done according to these parameters. In fact, in addition to supporting different time limits, the first token transfer procedure and the second token transfer procedure may support different volume of data, since the control plane can only be used to send small tokens, but with very little initial delay, as compared to the user plane, which involves instead an initial delay due to the establishment of a packet data unit (PDU) session.

[0026] Also, periodicity plays an important role since when control plane resources are used in the first token transfer procedure, the tokens can travel in a scheduled radio resource control (RRC) messages that are periodically sent between the client device and the base station. By knowing the schedule of such messages, the message bus can evaluate whether the control plane schedule is also suitable according to the time limit.

[0027] In an implementation form of a message bus according to the first aspect, the message bus is configured to:

[0028] select the first token transfer procedure or the second token transfer procedure further based on: an operator policy for the transfer of the set of tokens, and a power consumption of the client device for the transfer of the set of tokens. An advantage with this implementation form is that the operator policy can also be used to select the first or second token transfer procedure. In fact, one part of the operator policy is the cost per unit of data transfer, in case of first or second token transfer procedure, and therefore the message bus can evaluate this parameter when choosing the relevant transfer procedure.

[0029] Moreover, the power consumption of the client device is usually higher for the user plane procedure than the control plane procedure. This adds an additional criterion for the message bus when choosing the appropriate token transfer procedure. For example, in the case of a robot connected with the generative Al via the mobile network, power consumption directly affects the operation time of the robot before next time it needs to recharge its batteries, which translates to a monetary advantage in case of prolonged operation time.

[0030] In an implementation form of a message bus according to the first aspect, the message bus is configured to:

[0031] transmit a first response to the Al entity prior to transfer the set of tokens, the first response indicating an acknowledgment of the transfer of the set of tokens within the time limit.

[0032] An advantage with this implementation form is that it enables the Al entity to know in advance if the tokens will be delayed more than allowed. This knowledge enables the Al entity to perform counteraction, for example change the foundation model that is used to perform inference according to the new delay, or change the type of input information on which the inference is supposed to take place. For example, in the case of a robot, the required time limit may be the result of a specific control loop frequency. Some robots may require the tokens to be supplied a frequency comprised between 1 Hz and 20 Hz: and some tasks may require higher control loop frequency in order to be executed. The Al entity may decide to change type of token input, for example it could choose to perform inference based on spatial information in case real time video stream tokens cannot be received within the allowed time limit. In other case it can decide to change the control loop frequency, which may result in the robot take a change of the actions that the robot can perform.

[0033] In an implementation form of a message bus according to the first aspect, the first token transfer procedure comprises: receive a second request from an access and mobility management function, AMF, the second request indicating an identity of the client device and one or more configuration parameters associated with the transfer of the set of tokens; allocate one or more token transfer resources of the message bus for the transfer of the set of tokens based on the second request and the time limit; and

[0034] transmit a second response to the AMF, the second response indicating that the message bus will transfer the set of tokens within the time limit.

[0035] An advantage with this implementation form is that the message bus can configure its internal resources and the recipient Al services for the tokens to be transferred from the client device. In fact, since the required Al services, and relevant time limits for a client device can be stored in the user profile and provided by the AMF within the second request, the message bus can use this information to set up its internal queues and contact the relevant Al services to subscribe for the tokens of the relevant client device.

[0036] Another advantage with this implementation form is that the mobile network can also know whether the message bus will fulfill the time limit for the client device. This enables the mobile network to know which of the Al services for the subscriber will be supported in that specific moment for the subscriber. Such information can be used to trigger other internal configuration in the core network, including provisioning or deprovisioning of Al services, network resource allocation decision, etc. In an implementation form of a message bus according to the first aspect, the message bus is configured to: receive the set of tokens from the client device via a network access node of the mobile network; and

[0037] forward the set of tokens to the Al entity.

[0038] An advantage with this implementation form is that, when the set of tokens is supposed to be transferred using the control plane, the message bus can decouple the producer of the tokens from the receiver of the tokens, while also implement different routing mechanism of the tokens to the different Al entities, e.g., duplicating the same token when multiple Al entities are supposed to receive the same token, or aggregating multiple sets of tokens originated in different client devices in a single batch of tokens addressed to a specific Al entity.

[0039] Another advantage with this implementation is that when the message bus is part of the core network it can be used in place of a user plane function (UPF) in both cases of a first token transfer or a second token transfer procedure, therefore reducing the latency of transmission introduced by UPF services.

[0040] In an implementation form of a message bus according to the first aspect, the second token transfer procedure comprises: receive a third request from a session management function, SMF, the third request indicating an identity of the client device and one or more configuration parameters associated with the transfer of the set of tokens,

[0041] allocate one or more token transfer resources of the message bus for the transfer of the set of tokens based on the third request and the time limit; and

[0042] transmit a third response to the SMF, the third response indicating that the message bus will transfer the set of tokens within the time limit.

[0043] An advantage with this implementation form is that when the set of tokens is supposed to be transferred using the user plane, the message bus can configure its internal resources and the recipient Al services for the tokens to be transferred from the client device. In fact, since the required Al services, and relevant time limits for a client device can be stored in the user profile and provided by the SMF within the third request, the message bus can use this information to set up its internal queues and contact the relevant Al services to subscribe for the tokens of the relevant client device.

[0044] Another advantage with this implementation form is that the mobile network can also know whether the message bus will fulfill the time limit for the client device. This enables the mobile network to know which of the Al services for the subscriber will be supported in that specific moment for the subscriber. Such information can be used to trigger other internal configuration in the core network, including provisioning or deprovisioning of Al services, network resource allocation decision, etc.

[0045] In an implementation form of a message bus according to the first aspect, the message bus is configured to:

[0046] receive the set of tokens from the client device via a GPRS tunneling protocol, GTP-U, tunnel arranged between the client device and the message bus; and

[0047] forward the set of tokens to the Al entity.

[0048] An advantage with this implementation form is that the message bus can terminate the GTP-U tunnel from the client device, instead of the UPF, providing an alternative gateway to terminate traffic originated by the mobile network, supporting the time limit, which is a guarantee per token, differently from the QoS guarantee provided by the UPF, which are instead related to the data packets. In an implementation form of a message bus according to the first aspect, the one or more configuration parameters comprises: an expected maximum size of tokens in the set of tokens, a periodicity of the transfer of the set of tokens, and one or more types of Al services used by the client device and associated with the transfer of the set of tokens.

[0049] An advantage with this implementation form is that the message bus can use this information to dimension and interconnect the internal message bus resources to fulfill the time limit, according to the configuration parameters. Furthermore, the configuration parameters can also be used to select either the first or second token transfer procedure. Since the message bus internal resources form a link from the mobile network to the Al entity, several internal resources of the message bus could be interconnected for this purpose, such as, for example several receiver queues, transmission queues and queue handler, as well as optional functions such as those performing operations on the tokens such as filtering, aggregation, etc.

[0050] In an implementation form of a message bus according to the first aspect, the one or more configuration parameters comprises: a mapping between an Al service and one or more Al service topic identifiers, and the message bus is configured to:

[0051] select the Al entity among two or more Al entities for the transfer of the set of tokens based on the mapping between an Al service and one or more Al service topic identifiers.

[0052] An advantage with this implementation form is that - if the tokens are marked by topic identifier - the message bus can use the topic identifier with which the token is marked to address it to the relevant Al service (s), in addition to the subscription mechanism. The use of topic identifier adds a further level of generalization in the routing of the tokens, since each client device may generate multiple set of tokens, which pertain different information, addressed to the same service, and also multiple Al services may be interested to receive selectively the tokens marked with different topic identifiers.

[0053] In an implementation form of a message bus according to the first aspect, selecting the Al entity comprises:

[0054] receive a token among the set of tokens from the client device, wherein the token is marked with an Al service topic identifier; and

[0055] select the Al entity based on the marked Al service topic identifier and the mapping between an Al service and one or more Al service topic identifiers.

[0056] In an implementation form of a message bus according to the first aspect, the one or more token transfer resources comprises one or more internal token queues and one or more token queue handlers.

[0057] An advantage with this implementation form is that the message bus can allocate multiple queue handlers to each receiving queue, in order to speed up the distribution of those tokens and therefore lower the time to traverse the message bus for the token, trying to meet the requested time limit.

[0058] In an implementation form of a message bus according to the first aspect, the message bus is configured to:

[0059] interconnect the one or more internal token queues and the one or more token queue handlers.

[0060] An advantage with this implementation form is that the message bus can reconfigure the internal queue topology according to the current routing of the tokens between the served client devices and the destination Al services. On the route where more token traffic is detected the message bus can - in order to try to meet the time limit - allocate multiple queue handlers or rather aggregate the traffic originating from more client devices in a single incoming queue. At the same time the message bus can either use dedicated output queues per Al service, or aggregate in a single queue the traffic outgoing to multiple Al services. All these decisions are based on the time limit that should be fulfilled, as well as other criteria, such as the minimization of the memory and CPU resources used in the message bus hardware. According to a second aspect of the invention, the above mentioned and other objectives are achieved with an AMF configured to:

[0061] transmit a second request to a message bus, the second request indicating an identity of a client device and one or more configuration parameters associated with a transfer of the set of tokens from a client device of a mobile network to an Al entity associated with an Al service; and

[0062] receive a second response from the message bus, the second response indicating that the message bus will transfer the set of tokens within a time limit associated with the transfer of the set of tokens.

[0063] An advantage of the AMF according to the second aspect is that the message bus can configure its internal resources and the recipient Al services for the tokens to be transferred from the client device. In fact, since the required Al services, and relevant time limits for a client device can be stored in the user profile and provided by the AMF within the second request, the message bus can use this information to set up its internal queues and resources and contact the relevant Al services to subscribe for the tokens of the relevant client device.

[0064] In an implementation form of an AMF according to the second aspect, the AMF is configured to:

[0065] retrieve the one or more configuration parameters based on a user profile of the client device.

[0066] An advantage with this implementation form is that the AMF - in the case of control plane token transfer - can instruct the client device to deploy one or more functional components with respect to the Al service in question. For example, if the Al service does not provide a tokenizer on the server side and requires a tokenizer on the client device side, the configuration parameter in the user profile can instruct the client device to deploy a tokenizer for the service in question.

[0067] In an implementation form of an AMF according to the second aspect, the one or more configuration parameters comprises: an expected maximum size of tokens in the set of tokens, a periodicity of the transfer of the set of tokens, and a type of Al service used by the client device.

[0068] An advantage with this implementation form is that the message bus can use this information to dimension and interconnect the internal message bus resources to fulfill the time limit, according to the configuration parameters. Furthermore, the configuration parameters can also be used to select either the first or second token transfer procedure. Since the message bus internal resources form a link from the mobile network to the Al entity, several internal resources of the message bus could be interconnected for this purpose, such as, for example several receiver queues, transmission queues and queue handler, as well as optional functions such as those performing operations on the tokens such as filtering, aggregation, etc.

[0069] According to a third aspect of the invention, the above mentioned and other objectives are achieved with a SMF configured to:

[0070] transmit a third request to a message bus, the third request indicating an identity of a client device and one or more configuration parameters associated with a transfer of the set of tokens from a client device of a mobile network to an Al entity associated with an Al service; and

[0071] receive a third response from the message bus, the third response indicating that the message bus will transfer the set of tokens within a time limit associated with the transfer of the set of tokens.

[0072] An advantage of the SMF according to the third aspect is that when the set of tokens is supposed to be transferred using the user plane, the message bus can configure its internal resources and the recipient Al services for the tokens to be transferred from the client device. In fact, since the required Al services, and relevant time limits for a client device can be stored in the user profile and provided by the SMF within the third request, the message bus can use this information to set up its internal queues and contact the relevant Al services to subscribe for the tokens of the relevant client device.

[0073] In an implementation form of a SMF according to the third aspect, the SMF is configured to:

[0074] retrieve the one or more configuration parameters based on a user profile of the client device.

[0075] An advantage with this implementation form is that the SMF - in the case of user plane token transfer - can instruct the client device to deploy one or more functional components with respect to the Al service in question. For example, if the Al service does not provide a tokenizer on the server side and requires a tokenizer on the client device side, the configuration parameter in the user profile can instruct the client device to deploy a tokenizer for the service in question.

[0076] In an implementation form of a SMF according to the third aspect, the one or more configuration parameters comprises: an expected maximum size of tokens in the set of tokens, a periodicity of the transfer of the set of tokens, and a type of Al service used by the client device.

[0077] An advantage with this implementation form is that the message bus can use this information to dimension and interconnect the internal message bus resources to fulfill the time limit, according to the configuration parameters. Furthermore, the configuration parameters can also be used to select either the first or second token transfer procedure. Since the message bus internal resources form a link from the mobile network to the Al entity, several internal resources of the message bus could be interconnected for this purpose, such as, for example several receiver queues, transmission queues and queue handler, as well as optional functions such as those performing operations on the tokens such as filtering, aggregation, etc.

[0078] In an implementation form of a SMF according to the third aspect, the SMF is configured to:

[0079] receive a control message from the client device, wherein the control message indicates a request to establish a GTP-U tunnel for the transfer of the set of tokens; and

[0080] configure the GTP-U tunnel for the transfer of the set of tokens from the client device to the message bus based on the control message.

[0081] An advantage with this implementation form is that the message bus can terminate the GTP-U tunnel from the client device, instead of the UPF, providing an alternative gateway to terminate traffic originated by the mobile network, supporting the time limit, which is a guarantee per token, differently from the QoS guarantee provided by the UPF, which are instead related to the data packets.

[0082] In an implementation form of a SMF according to the third aspect, the request to establish a GTP-U tunnel for the transfer of the set of tokens is a flag.

[0083] An advantage with this implementation form is that signaling of the request to establish a GTP-U tunnel can be made with low overhead.

[0084] According to a fourth aspect of the invention, the above mentioned and other objectives are achieved with a method for a message bus, the method comprises:

[0085] receiving a first request from an Al entity associated with an Al service, the first request indicating a request for a transfer of a set of tokens from a client device of a mobile network to the Al entity and a time limit associated with the transfer of the set of tokens; and selecting a first token transfer procedure or a second token transfer procedure for the transfer of the set of tokens based on the time limit, wherein

[0086] the first token transfer procedure comprises the transfer of the set of tokens from the client device to the Al entity via a control plane of the mobile network, and

[0087] the second token transfer procedure comprises the transfer of the set of tokens from the client device to the Al entity via a user plane of the mobile network.

[0088] The method according to the fourth aspect can be extended into implementation forms corresponding to the implementation forms of the message bus according to the first aspect. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the message bus.

[0089] The advantages of the methods according to the fourth aspect are the same as those for the corresponding implementation forms of the message bus according to the first aspect.

[0090] According to a fifth aspect of the invention, the above mentioned and other objectives are achieved with a method for an AMF, the method comprises:

[0091] transmitting a second request to a message bus, the second request indicating an identity of a client device and one or more configuration parameters associated with a transfer of the set of tokens from a client device of a mobile network to an Al entity associated with an Al service; and

[0092] receiving a second response from the message bus, the second response indicating that the message bus will transfer the set of tokens within a time limit associated with the transfer of the set of tokens.

[0093] The method according to the fifth aspect can be extended into implementation forms corresponding to the implementation forms of the AMF according to the second aspect. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the AMF.

[0094] The advantages of the methods according to the fourth aspect are the same as those for the corresponding implementation forms of the AMF according to the second aspect.

[0095] According to a sixth aspect of the invention, the above mentioned and other objectives are achieved with a method for a SMF, the method comprises:

[0096] transmitting a third request to a message bus, the third request indicating an identity of a client device and one or more configuration parameters associated with a transfer of the set of tokens from a client device of a mobile network to an Al entity associated with an Al service; and

[0097] receiving a third response from the message bus, the third response indicating that the message bus will transfer the set of tokens within a time limit associated with the transfer of the set of tokens.

[0098] The method according to the sixth aspect can be extended into implementation forms corresponding to the implementation forms of the SMF according to the third aspect. Hence, an implementation form of the method comprises the feature(s) of the corresponding implementation form of the SMF.

[0099] The advantages of the methods according to the sixth aspect are the same as those for the corresponding implementation forms of the SMF according to the third aspect. Examples of the invention also relate to a computer program, characterized in program code, which when run by at least one processor causes the at least one processor to execute any method according to examples of the invention. Further, examples of the invention also relate to a computer program product comprising a computer readable medium and the mentioned computer program, wherein the computer program is included in the computer readable medium, and may comprises one or more from the group of: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically erasable PROM (EEPROM), hard disk drive, etc.

[0100] Further applications and advantages of examples of the invention will be apparent from the following detailed description.

[0101] BRIEF DESCRIPTION OF THE DRAWINGS

[0102] The appended drawings are intended to clarify and explain different examples of the invention, in which:

[0103] - Fig. 1 shows a message bus according to examples of the invention;

[0104] - Fig. 2 shows a flow chart of a method for a message according to examples of the invention;

[0105] - Fig. 3 shows an AMF according to examples of the invention;

[0106] - Fig. 4 shows a flow chart of a method for an AMF according to examples of the invention;

[0107] - Fig. 5 shows a SMF according to examples of the invention;

[0108] - Fig. 6 shows a flow chart of a method for a SMF according to examples of the invention;

[0109] - Fig. 7 illustrates a first token transfer procedure and a second token transfer procedure according to examples of the invention;

[0110] - Fig. 8 shows control signaling and further details of examples of the invention;

[0111] - Fig. 9 shows a message bus for token transfer deployed within the 3GPP system according to examples of the invention;

[0112] - Figs. 10 to 14 show implementation examples of token transfer according to examples of the invention; and - Figs. 15 to 18 illustrate different timing aspects of token transfer according to examples of the invention.

[0113] DETAILED DESCRIPTION

[0114] Multiple generative Al entities may need to receive the same input tokens from a client device but those tokens are used to perform different tasks. In other cases, two generative Al entities may need to collect as input a set of tokens that is not identical but where a large set of tokens is shared. In those scenarios the tokens should not be transferred multiple times on the air interface, since this could lead to transmission inefficiency. When multiple generative Al entities need to process the same or mostly the same set of tokens, there could be different time requirements among them. The time requirements depend on the task that is performed by the generative Al entity. The multiple generative Al entities could be located in the data network, e.g., edge cloud or central cloud, or in the core network, and may need to share the same input tokens. An MNO may want to differentiate the service provided by core network generative Al by providing a more efficient token transfer towards the generative Al entities deployed within the core network.

[0115] A message bus (MB) is not only a solution for UE uplink Al data and tokens transfer, but it is needed to transport data to Al nodes in real time for inference and with synchronization requirements for training from any node in the future 6G networks. The MB may be implemented in the core network (CN) and directly integrated with radio access network (RAN) air interface on the UE side and connected to the UPF on the other side, or to a data network which connects to the Al entity.

[0116] The message bus, also referred as message queue or message broker, is a network function that offers a message delivery service to other NFs, as an alternative to direct connection, to decouple the endpoints. The message bus enables an entity inside or outside of the 3GPP system, namely an NF, an AF or an application server in a data network, to send a message to other entities. A message is composed by a message header containing metadata, usually in the form of key-value pairs, and amessage payload i.e., the actual content of the message. The message bus offers a publish-subscribe pattern to the entities that use its services. Specifically, those entities can be either consumers or producers: consumers subscribe to messages of a certain type and producers create messages, also according to certain characteristics. The message bus is responsible of routing the messages from producers to consumers according to one or more message services that is provided to the served entities. The message bus implements its message delivery service by means of one or more queues, which are used to buffer the messages before delivery. Internal queues in the message bus may be duplicated or scaled, distributed over multiple nodes and additional services may be provided such as message persistence, guaranteed number of deliveries, etc. The message bus may also process the messages while they are in the queues, in order to apply some changes, in the header or in the payload.

[0117] The message bus can incorporate a message bus controller function (MB CF). The message bus can be referred to as a user plane entity (i.e., MB UP), since it is in charge of transporting the messages according the publisher-subscriber service, the MB CF can be referred to as a control plane entity. It is a network function (NF) that from one side is used to operate on the service provided by the message bus, configuring its parameters and changing its characteristics and monitors the message bus status. In this aspect the MB CF can get insights on the number of queues, topics, consumers, and analytics that refer to the operation of the message bus. From the other side, the MB CF may also interact with other control plane entities in the 3GPP network, e.g. PCF / SMF, in order to request network features or functionality in order to fulfill the requirements requested by the operation of the message bus. It is envisaged herein that the functions of MB UP and MB CF may simply be denoted message bus.

[0118] In the 3GPP system the user plane is a channel UE-gNB-UPF that provides a service for transporting data packets. In this disclosure an alternative channel is considered that may be denoted as “Data Plane”, which may be the channel between entities UE-gNB-message bus, which is alternative and independent from the user plane. The data plane is not currently part of the 3GPP system. While user plane data are routed to and from user applications connected to the UE or in the data plane via the UPF, information travelling on the data plane is intended to be transported between user applications in the UE and / or data networks (via the UPF), network functions and other entities to and from Al entities which can be located either in the 3GPP network or outside of it. Non-limiting examples of Al entities are network data analytics function (NWDAF) or a generative Al entity such as LLM / VLM or ViT which is performing training or inference within an application or a container service. A substantial difference of the data plane compared to the user plane is that while the user plane routes packets, the data plane routes entire messages from producers to consumers. Each message can be composed by one or more data packets. These messages may be used to transport sets of tokens, with a time limit guarantee which is requested by the Al entity and enforced by the message bus.

[0119] Fig. 1 shows a message bus 100 according to an example of the invention. In the example shown in Fig. 1, the message bus 100 comprises a processor 102, a transceiver 104 and a memory 106. The processor 102 is coupled to the transceiver 104 and the memory 106 by communication means 108 known in the art. The message bus 100 is configured for communications in a communication system. The communication capability may be provided with a communication interface 110.

[0120] The processor 102 may be referred to as one or more general-purpose central processing units (CPUs), one or more digital signal processors (DSPs), one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, or one or more chipsets. The memory 106 may be a read-only memory, a random access memory (RAM), or a non-volatile RAM (NVRAM). The transceiver 104 may be a transceiver circuit, a power controller, or an interface providing capability to communicate with other communication modules or communication devices, such as network nodes and network servers. The transceiver 104, memory 106 and / or processor 102 may be implemented in separate chipsets or may be implemented in a common chipset. That the message bus 100 is configured to perform certain actions can in this disclosure be understood to mean that the message bus 100 comprises suitable means and devices, such as e.g., the processor 102 and the transceiver 104, configured to perform the actions.

[0121] According to examples of the invention the message bus 100 is configured to: receive a first request 510 from an Al entity 400 associated with an Al service, the first request 510 indicating a request for a transfer of a set of tokens 120 from a client device 310 of a mobile network 300 to the Al entity 400 and a time limit associated with the transfer of the set of tokens 120: and select a first token transfer procedure 610 or a second token transfer procedure 620 for the transfer of the set of tokens 120 based on the time limit, wherein the first token transfer procedure comprises the transfer of the set of tokens 120 from the client device 310 to the Al entity 400 via a control plane of the mobile network 300, and the second token transfer procedure comprises the transfer of the set of tokens 120 from the client device 310 to the Al entity 300 via a user plane of the mobile network 300.

[0122] Furthermore, in an example of the invention, the message bus 100 comprises a transceiver configured to: receive a first request 510 from an Al entity 400 associated with an Al service, the first request 510 indicating a request for a transfer of a set of tokens 120 from a client device 310 of a mobile network 300 to the Al entity 400 and a time limit associated with the transfer of the set of tokens 120: and select a first token transfer procedure 610 or a second token transfer procedure 620 for the transfer of the set of tokens 120 based on the time limit, wherein the first token transfer procedure comprises the transfer of the set of tokens 120 from the client device 310 to the Al entity 400 via a control plane of the mobile network 300, and the second token transfer procedure comprises the transfer of the set of tokens 120 from the client device 310 to the Al entity 300 via a user plane of the mobile network 300.

[0123] Moreover, in yet another example of the invention, the message bus 100 for a communication system comprises a processor and a memory having computer readable instructions stored thereon which, when executed by the processor, cause the processor to : receive a first request 510 from an Al entity 400 associated with an Al service, the first request 510 indicating a request for a transfer of a set of tokens 120 from a client device 310 of a mobile network 300 to the Al entity 400 and a time limit associated with the transfer of the set of tokens 120: and select a first token transfer procedure 610 or a second token transfer procedure 620 for the transfer of the set of tokens 120 based on the time limit, wherein the first token transfer procedure comprises the transfer of the set of tokens 120 from the client device 310 to the Al entity 400 via a control plane of the mobile network 300, and the second token transfer procedure comprises the transfer of the set of tokens 120 from the client device 310 to the Al entity 300 via a user plane of the mobile network 300.

[0124] Fig. 2 shows a flow chart of a corresponding method 200 which may be executed in a message bus 100, such as the one shown in Fig. 1. The method 200 comprises: receiving 202 a first request 510 from an Al entity 400 associated with an Al service, the first request 510 indicating a request for a transfer of a set of tokens 120 from a client device 310 of a mobile network 300 to the Al entity 400 and a time limit associated with the transfer of the set of tokens 120: and selecting 204 a first token transfer procedure 610 or a second token transfer procedure 620 for the transfer of the set of tokens 120 based on the time limit, wherein the first token transfer procedure comprises the transfer of the set of tokens 120 from the client device 310 to the Al entity 400 via a control plane of the mobile network 300, and the second token transfer procedure comprises the transfer of the set of tokens 120 from the client device 310 to the Al entity 300 via a user plane of the mobile network 300.

[0125] Fig. 3 shows an AMF 330 according to an example of the invention. In the example shown in Fig. 3, the AMF 330 comprises a processor 332, a transceiver 334 and a memory 336. The processor 332 is coupled to the transceiver 334 and the memory 336 by communication means 338 known in the art. The AMF 330 is configured for communications in a communication system. The communication capability may be provided with a communication interface 340. The processor 332 may be referred to as one or more general-purpose CPUs, one or more DSPs, one or more ASICs, one or more FPGAs, one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, one or more chipsets. The memory 336 may be a read-only memory, a RAM, or a NVRAM. The transceiver 334 may be a transceiver circuit, a power controller, or an interface providing capability to communicate with other communication modules or communication devices. The transceiver 334, the memory 336 and / or the processor 332 may be implemented in separate chipsets or may be implemented in a common chipset. That the AMF 330 is configured to perform certain actions can in this disclosure be understood to mean that the AMF 330 comprises suitable means and devices, such as e.g., the processor 332 and the transceiver 334, configured to perform the actions.

[0126] According to examples of the invention the AMF 330 is configured to: transmit a second request 530 to a message bus 100, the second request 530 indicating an identity of a client device 310 and one or more configuration parameters associated with a transfer of the set of tokens 120 from a client device 310 of a mobile network 300 to an Al entity 400 associated with an Al service; and receive a second response 540 from the message bus 100, the second response 540 indicating that the message bus 100 will transfer the set of tokens 120 within a time limit associated with the transfer of the set of tokens 120.

[0127] Furthermore, in an example of the invention, the AMF 330 comprises a transceiver configured to: transmit a second request 530 to a message bus 100, the second request 530 indicating an identity of a client device 310 and one or more configuration parameters associated with a transfer of the set of tokens 120 from a client device 310 of a mobile network 300 to an Al entity 400 associated with an Al service; and receive a second response 540 from the message bus 100, the second response 540 indicating that the message bus 100 will transfer the set of tokens 120 within a time limit associated with the transfer of the set of tokens 120.

[0128] Moreover, in yet another example of the invention, the AMF 330 for a communication system comprises a processor and a memory having computer readable instructions stored thereon which, when executed by the processor, cause the processor to: transmit a second request 530 to a message bus 100, the second request 530 indicating an identity of a client device 310 and one or more configuration parameters associated with a transfer of the set of tokens 120 from a client device 310 of a mobile network 300 to an Al entity 400 associated with an Al service; and receive a second response 540 from the message bus 100, the second response 540 indicating that the message bus 100 will transfer the set of tokens 120 within a time limit associated with the transfer of the set of tokens 120.

[0129] Fig. 4 shows a flow chart of a corresponding method 730 which may be executed in an AMF 330, such as the one shown in Fig. 3. The method 730 comprises: transmitting 732 a second request 530 to a message bus 100, the second request 530 indicating an identity of a client device 310 and one or more configuration parameters associated with a transfer of the set of tokens 120 from a client device 310 of a mobile network 300 to an Al entity 400 associated with an Al service; and receiving 734 a second response 540 from the message bus 100, the second response 540 indicating that the message bus 100 will transfer the set of tokens 120 within a time limit associated with the transfer of the set of tokens 120.

[0130] Fig. 5 shows a SMF 350 according to an example of the invention. In the example shown in Fig. 5, the SMF 350 comprises a processor 352, a transceiver 354 and a memory 356. The processor 352 is coupled to the transceiver 354 and the memory 356 by communication means 358 known in the art. The SMF 350 is configured for communications in a communication system. The communication capability may be provided with a communication interface 360.

[0131] The processor 352 may be referred to as one or more general-purpose CPUs, one or more DSPs, one or more ASICs, one or more FPGAs, one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, one or more chipsets. The memory 356 may be a read-only memory, a RAM, or a NVRAM. The transceiver 354 may be a transceiver circuit, a power controller, or an interface providing capability to communicate with other communication modules or communication devices. The transceiver 354, the memory 356 and / or the processor 352 may be implemented in separate chipsets or may be implemented in a common chipset. That the SMF 350 is configured to perform certain actions can in this disclosure be understood to mean that the SMF 350 comprises suitable means and devices, such as e.g., the processor 352 and the transceiver 354, configured to perform the actions.

[0132] According to examples of the invention, the SMF 350 is configured to: transmit a third request to a message bus, the third request indicating an identity of a client device and one or more configuration parameters associated with a transfer of the set of tokens from a client device of a mobile network to an Al entity associated with an Al service; and receive a third response from the message bus, the third response indicating that the message bus will transfer the set of tokens within a time limit associated with the transfer of the set of tokens.

[0133] Furthermore, in an example of the invention, the SMF 350 comprises a transceiver configured to: transmit a third request to a message bus, the third request indicating an identity of a client device and one or more configuration parameters associated with a transfer of the set of tokens from a client device of a mobile network to an Al entity associated with an Al service; and receive a third response from the message bus, the third response indicating that the message bus will transfer the set of tokens within a time limit associated with the transfer of the set of tokens.

[0134] Moreover, in yet another example of the invention, the SMF 350 for a communication system comprises a processor and a memory having computer readable instructions stored thereon which, when executed by the processor, cause the processor to: transmit a third request to a message bus, the third request indicating an identity of a client device and one or more configuration parameters associated with a transfer of the set of tokens from a client device of a mobile network to an Al entity associated with an Al service; and receive a third response from the message bus, the third response indicating that the message bus will transfer the set of tokens within a time limit associated with the transfer of the set of tokens.

[0135] Fig. 6 shows a flow chart of a corresponding method 750 which may be executed in a SMF 350, such as the one shown in Fig.

[0136] 5. The method 750 comprises: transmitting 752 a third request to a message bus, the third request indicating an identity of a client device and one or more configuration parameters associated with a transfer of the set of tokens from a client device of a mobile network to an Al entity associated with an Al service; and receiving 754 a third response from the message bus, the third response indicating the message bus will transfer the set of tokens within a time limit associated with the transfer of the set of tokens.

[0137] Tokens may be considered as the basic units of input and output in a generative Al entity such as a language model, a large language model or a video language model etc. Tokens are a type of traffic that can be transferred in the data plane. In this disclosure we refer to uplink token transfer from an application connected to the UE to a generative Al entity. During training and inference, the LLM processes input as a sequence of tokens, each representing a specific word or symbol in the input text. In case of multimodal LLMs, tokens can transport embedding of image, video or other content. In the English language, a token typically represents about 4 characters or roughly three-quarters of a word. Tokens are not uniformly sized or consistent across different languages. Tokenization is based on a language-specific vocabulary. It may be assumed that tokenization is performed on the producer side, according to a vocabulary that is accessed by the producer and that can periodically be updated e.g., by downloading it from a server. However, the benefits of examples of the invention are still provided in case the tokenization and / or the embedding are performed in the network side e.g., in the generative Al entity.

[0138] Embeddings are numerical representations of real- world objects that ML and Al systems use to understand complex knowledge domains like humans do. Embedding enables to capture the semantics of the input in order to be understood by the Al entity. In general, embeddings are vector-representations of tokens. Therefore, it may in examples of the invention be assumed that the producer will first perform tokenization and secondly embedding the token, the result is placed in a message that is transmitted via the message bus 100.

[0139] Furthermore, Fig. 7 illustrates the first token transfer procedure and the second token transfer procedure according to examples of the invention. In these and further examples of the invention, details related to examples of the invention will be fully or partially described in a 3GPP context which means that the mobile network 300 is a 3GPP mobile network. Therefore, 3GPP terminology, definitions, expressions and system architecture may be used. Thus, the client device 310 may thus be denoted UE and a network access node 320 may be denoted gNB. It may however be noted that examples of the invention are not limited thereto.

[0140] In Fig. 7, the two different token transfer procedures 610, 620 selected by the message bus 100 are illustrated.

[0141] In the first token transfer procedure 610, the set of tokens 120 emanating from the UE 310 is transferred via the control plane of the mobile network 300. Thus, the set of tokens 120 arrives at the message bus 100 via the control plane of mobile network 300.

[0142] The control plane transports the tokens using a radio resource control (RRC) protocol. 3GPP has specified several procedures for RRC transport, namely random access (RA) based small data transfer (SDT) (with or without context relocation) and carrier grant (CG)-based SDT. As specified by 3GPP, the payload from the UE 310 is added to the RRC resume request in case of RA based SDT, or in the CG-based push transmission carrying the RRC resume request, which is sent by the UE 310 according to the timing advance (TA) timer and configuration received by the gNB 320. These procedures may be modified in examples of the invention as follows:

[0143] • Payload is explicitly marked as Al data tokens, so that the gNB 320 receiving the payload can route it towards the message bus 100, instead of the UPF.

[0144] • Pay load is also optionally marked with a topic identifier, which can be used to route the tokens to a specific Al service or list of Al services, according to the matching information received by the message bus 100 from the mobile network, either via the AMF 330 or SMF 350.

[0145] • Before transferring the tokens, the gNB 320 sends a message to the AMF 330, where the message carries the user identity and the configuration loaded from the UDM, including the list of the Al services and the match information between the token identifiers and the relevant Al services.

[0146] • The message bus 100 uses this information between the token identifiers and the relevant Al services to allocate the necessary resources in the internal queues and contact the Al services to trigger subscribe procedure, if not already done, in order to make sure that those tokens can correctly be received by the relevant Al services.

[0147] The message bus 100 upon receiving the set of tokens 120 forwards the set of tokens 120 to the Al entity 400.

[0148] In the second token transfer procedure 610, the set of tokens 120 emanating from the UE 320 is instead transferred via the user plane of the mobile network 300. Thus, the set of tokens 120 arrives at the message bus 100 via the user plane of the mobile network 300. The user plane is the link that carries the network traffic after the establishment of a PDU session, from the mobile network towards the data network. In 3GPP 5G networks this refers to the protocol stack on N3 interface using the GTP-U protocol to tunnel user data between the access network and the core network, i.e., between the gNB 320 and the UPF. In the context of this disclosure, the user plane may be referred to as the link established between the gNB 320 and the message bus 100, for which we assume to use the same protocol stack as N3 interface in 5G, therefore using GTP-U to tunnel the tokens between the gNB 320 and the message bus 100. GTP-U is defined in 3GPP TS 29.281. The message bus 100 upon receiving the set of tokens 120 forwards the set of tokens 120 to the Al entity 400.

[0149] Fig. 8 shows control signaling and further details for providing deeper understanding of examples of the invention.

[0150] The transfer of tokens 120 may be initiated by the Al entity 400 sending a first request message 510 to the message bus 510. The first request message 510 is among other things a request for a transfer of a set of tokens 120 from a UE 310 of a mobile network 300 to the Al entity 400 and a time limit associated with the transfer of the set of tokens 120.

[0151] The message bus 100 processes the request by calculating or estimating whether the time limit can be fulfilled or not for the transfer of the set of tokens 120. The time limit may be based on a first time instance T1 when the UE 310 starts transmitting the set of tokens 120 and a second time instance T2 when the Al entity 400 receives the set of tokens 120.

[0152] If the answer is positive, the message bus 100 transmit a first response 520 to the Al entity 400 prior to transfer the set of tokens 120. The first response 520 indicates an acknowledgment (ACK) of the transfer of the set of tokens 120 within the time limit. Thus, the Al entity 400 is informed about the fact that the relevant tokens for the Al entity 400 will be received with a maximum delay that is less than the maximum time limit

[0153] The message bus 100, as previously mentioned, selects either the first 610 or the second 620 token transfer procedure depending on the time limit. Thus, in examples of the invention, the selection of the token transfer procedure comprises selecting the first token transfer procedure 610 or the second token transfer procedure 620 meeting the time limit. This means that the message bus 100 can estimate the total transfer time from the UE 310 to the Al service and determine whether it will be less or greater than the maximum time limit, and inform whether the time limit can be verified with any of the token transfer procedures.

[0154] However, the message bus 100 may use further information and data for selecting the token transfer procedure.

[0155] Thus, in examples of the invention, the message bus 100 selects the first token transfer procedure 610 or the second token transfer procedure 620 further based on a volume of the set of tokens 120, and a periodicity of the transfer of the set of tokens 120.

[0156] The volume is important to determine whether the size of the set of tokens can fit the pay load of a control message, which is usually limited to a few hundred bytes, depending on the network configuration.

[0157] The periodicity of the transfer of the tokens is important to determine whether the periodicity of CG-based SDT message carrying the payload, e.g., CG-based physical uplink shared channel (PUSCH) transmission carrying RRC resume request, matches the periodicity of the transfer of the tokens since some Al application require tokens to be sent periodically for inference. For example, if the periodicity of CG-based SDT is a multiple of the periodicity of the transfer of the set of tokens, then the message bus 100 may be able to fulfill the time limit.

[0158] In further examples of the invention, the message bus 100 selects the first token transfer procedure 610 or the second token transfer procedure 620 further based on an operator policy for the transfer of the set of tokens 120, and a power consumption of the client device 310 for the transfer of the set of tokens 120.

[0159] The operator policy may determine the rate for the charging of the user plane messages, and the message bus 100 may take this into account when choosing the first 610 or second 620 transfer procedure. The power consumption of the UE 310 is higher in the case of the user plane transfer procedure. The message bus 100 may therefore want to keep the power consumption of the UE 310 lower and choose a control plane transfer procedure that matches the other requirements (e.g. time limit) of the Al service.

[0160] It may be noted that all the above information and data may be used for selecting the token transfer procedure, i.e., the volume, periodicity, operator policy and power consumption. Also, further information and data may be used for selecting the token transfer procedure such as the number of established PDU session for the UE 310, since there is a maximum number of PDU sessions that each UE can have; the amount of allocated user plane resources for the UE 310 or in the gNB 320; and the type of the UE since some UEs may not support all of the control plane procedure herein employed.

[0161] The first token transfer procedure 610 comprises the transfer of tokens via the control plane which involves signaling between the message bus 100 and an AMF 330. Therefore, the message bus 100 receives a second request 530 from the AMF 330 in this procedure. The second request 530 indicates an identity (ID) of the UE 310 and one or more configuration parameters associated with the transfer of the set of tokens 120. The message bus 100 upon reception of the second request 530 allocates one or more token transfer resources of the message bus 100 for the transfer of the set of tokens 120 based on the content of the second request 530 and the time limit received previously from the Al entity 400 in the initiation step. Thereafter, the message bus 100 transmits a second response 540 to the AMF 330, where the second response 540 indicates that the message bus 100 will transfer the set of tokens 120 within the time limit.

[0162] The AMF 330 when receiving the second response 540 assumes that the message bus 100 has correctly configured the Al services that are supposed to receive the tokens originating at the UE 310 and that the transfer of these tokens will happen correctly and within the time limit. Therefore, the AMF 330 confirms to the gNB 320 that the transfer of tokens according to control plane can happen correctly. Otherwise, if the second response 540 includes some error notification, such as issues in supporting the required time limit, the AMF 330 can signal the error to the gNB 320 or trigger some other action within the core network or the radio access network in order to correct the issue which would prevent the Al services from running correctly.

[0163] It is also noted that when the control plane is used, the set of tokens are received by the message bus 100 from the UE 310 via a network access node 320 such as a gNB of the mobile network 300. The message bus 100 forwards the set of tokens 120 to the Al entity 400.

[0164] The second token transfer procedure 620 on the other hand comprises the transfer of tokens via the user plane which instead involves signaling between the message bus 100 and a SMF 350. The signaling in this second procedure is basically the same as in the first procedure regarding the message content. This means that the message bus 100 receives a third request 550 from a SMF 350. The third request 550 indicates an identity of the UE 310 and one or more configuration parameters associated with the transfer of the set of tokens 120. As described above the message bus 100 thus allocates one or more token transfer resources of the message bus 100 for the transfer of the set of tokens 120 based on the third request 550 and the time limit. The message bus 100 then transmits a third response 560 to the SMF 350, where the third response 560 indicates that the message bus 100 will transfer the set of tokens 120 within the time limit.

[0165] The actual transfer of the tokens is different in the user plane procedure compared to the control plane procedure since the message bus 100 in the user plane procedure receives the set of tokens 120 from the UE 310 via a GPRS tunneling protocol (GTP-U) tunnel 380 arranged between the client device 310 and the message bus 100 as shown in Fig . 8. The message bus 100 thereafter forwards the set of tokens 120 to the Al entity 400. For both the first token transfer procedure 610 and the second token transfer procedure 620 the configuration parameters may comprise:

[0166] • An expected maximum size of tokens in the set of tokens 120, and / or

[0167] • A periodicity of the transfer of the set of tokens 120, and / or

[0168] • One or more types of Al services used by the UE 310 and associated with the transfer of the set of tokens 120.

[0169] The expected maximum size of tokens refers to the total volume in bytes of the set of tokens. This parameter is important in order to understand whether the tokens can be sent using the pay load of the control plane transfer procedure.

[0170] The periodicity of the transfer of the set of tokens refers to how often the set of tokens will be sent by the application in the UE 310. This parameter is important in order to understand whether the periodicity of RA-type control plane procedure can match the periodicity of the token transfer.

[0171] The Al services used by the UE 310 is a list of service names with the associated internet protocol (IP) address or fully qualified domain name of the Al service which is supposed to receive and process the tokens originated by the application in the UE 310. The Al service can be provided by a software program connected with a generative Al foundation model, such as an LLM, VLM, ViT or other type of model.

[0172] Moreover, a selection of an Al entity among a plurality of Al entities by the message bus 100 is also considered in examples of the invention. The selection may be based on a mapping between an Al service and one or more Al service topic identifiers. Thus, the mentioned configuration parameters may also comprise a mapping between an Al service and one or more Al service topic identifiers. With these mappings between an Al service and one or more Al service topic identifiers, the message bus 100 selects an Al entity 400 among two or more Al entities 400, 400' for the transfer of the set of tokens 120.

[0173] More specifically, each token may be marked by an Al service topic identifier which the message bus 100 can use to select the right Al entity 400. In such examples, the message bus 100 receives a token marked with an Al service topic identifier, and selects the Al entity 400 based on the marked Al service topic identifier and the mapping between an Al service and one or more Al service topic identifiers.

[0174] Moreover, the internal token transfer resources of the message bus 100 important for correct transfer and handling of tokens are internal token queues and token queue handlers.

[0175] The internal token queues are memory structures that are used within the message bus 100 to store the tokens received from the UE 310 and also waiting to be routed towards the Al services. The message bus 100 may decide that a set of tokens has to traverse more than one internal token queue, depending on the volume of traffic of tokens and also on internal resources availability. It should also be considered that the message bus 100 may perform further processing on the tokens while they get routed from the producers towards the consumers, such as aggregating more than one token from multiple UEs into a single set of tokens, or copying and distributing one or more tokens to more than one Al service.

[0176] The token queue handlers are software programs or program threads that pops tokens from a queue and route them for further processing, or for sending them forward towards the consumers.

[0177] Finally, the message bus 100 for meeting the time limit interconnects the one or more internal token queues and the one or more token queue handlers with each other in order to create a suitable route of the tokens from the producers towards the consumer, that can fulfill the needed processing and also the time limit. Since queue handlers pop messages from the queues, adding more queue handlers can speed up message processing and reduce the time the message is waiting in the queue. For example, in the event that one of the queues is receiving more traffic than the others it is possible that that a single queue handler may not be capable of processing the messages within the allowed time, in order to fulfill the time limit. In such case the message bus 100 may decide to allocate more than one queue handler to that queue so that they can parallelize the message processing and bring down the time to process the message to an acceptable level, with respect to the time limit.

[0178] Fig. 9 shows an exemplary 3GPP system architecture in which examples of the invention may be implemented. The following nodes are part of the conventional systems: UE 310, gNB 320, AMF 330, user plane function (UPF), SMF 350. The term NF refers to any NF in the core network or any application function (AF) in the data network. The term generative Al refers to any application server either in the core network or in the data network (DN) which deploys a generative Al model such as an LLM, VLM, ViT or equivalent.

[0179] The message bus user plane (MB UP) and message bus control function (MB CF), sometimes denoted message bus 100 (MB) only, are defined in previous sections of the disclosure and are newNFs. Also, the interfaces to and from the message bus 100 and between the MB UP and the MB CF are new in Fig. 9. The non-3GPP entities are UE application (UE App) and the Gen Al.

[0180] In examples of the invention, the UE 310 needs to mark the data / token to be transmitted uplink explicitly as Al data / tokens in order to be sent by the UE 310 on a different data plane to the message bus 100, which provides a different service from the UPF:

[0181] • Small volume tokens: in case the TE needs to stay in RRC_INACTIVE state and the tokens need to be sent using RRC to the gNB 310 and then relayed to the message bus 100.

[0182] • Large volume tokens: the data plane can be mapped to a radio bearer, packet data unit (PDU) session terminated to the message bus 100, with associated quality of service (QoS), in order to have allocated and diversified resources from the rest of the user plane, which is used to send the tokens.

[0183] “Small volume tokens” is a set of tokens or Al data for which the total pay load is lower than or equal to the threshold defined for small data transfer in the 3GPP network. This threshold is defined by the parameter sdt-DataVolumeThreshold defined in cl. 5.27.1 of TS 38.321 or equivalent. If the payload of the set of tokens exceeds such threshold, those tokens are considered “large volume tokens”.

[0184] The UE 310 may mark Al data to be sent as small data transmission (SDT) using the existing command +CSODCP as specified in cl. 10.1.43 of TS 27.007 or equivalent, and using a new value for the Al data to be set in the <type_of_user_data> field as shown in the Table below.

[0185] <> <> <> <> < <>

[0186] > < <> <>

[0187] <> <> <> <>

[0188]

[0189] <> <> <>

[0190]

[0191] The following changes or equivalent may be required: <type_of_user_data>: where the integer type indicates whether the user data that is transmitted is regular or exceptional where:

[0192] 0 = Regular data.

[0193] 1 = Exception data.

[0194] 2 = Al data.

[0195] After the UE application has marked the data as Al data / tokens, the UE 310 starts a modified SDT procedure for data uplink. Assuming that the UE 310 is registered on the public land mobile network (PLMN) and has established a primary packet data protocol (PDP) context for data transmission, the UE 310 may request a secondary PDP context for the transmission of large Al data or tokens. The UE 310 may request a secondary PDP context, e.g., using command +CGDSCONT (“define secondary PDP context”) as specified in cl. 10.1.2 of TS 27.007 or equivalent, and specifies that this secondary PDP context is for the transfer of Al data / tokens. Plow the UE 310 specifies this is for Al data / tokens is an implementation issue, and here are a few non-limiting alternatives:

[0196] • Values bigger than 1 in <IM_CN_Signalling_Flag_Ind>,

[0197] • Specific standardized value in <cid>,

[0198] • Specific standardized value in <p_cid>, and

[0199] • An additional flag to be added to + CGDSCONT.

[0200] The result of the previous operation is that a request for Al data channel setup is sent by the UE 310 to the gNB 320.

[0201] Fig. 10 shows an implementation example of small Al data upload with UE context relocation. As specified in TS 38.321, when triggering mobile originated (MO) SDT, the SDT procedure initiated for MO-SDT can be performed either by one of the following:

[0202] a) Random access (RA) procedure with 2-step RA type,

[0203] b) 4-step RA type (i.e., RA-SDT), and

[0204] c) Configured grant Type 1 (i.e., CG-SDT).

[0205] Case a) and b) are covered in Fig. 10 while case c) is covered in Fig. 11.

[0206] In case a) and b), pre-conditions for the UE 310 to send SDT is that:

[0207] • Downlink reference signal received power (RSRP) is above a configured threshold as in clause 18 of TS 38.300.

[0208] • A valid SDT resource is available as specified in clause 5.27.1 of TS 38.321.

[0209] The SDT procedure is initiated by the UE 310 with a transmission over random access channel (RACH) configured via system information as in TS 38.300 cl. 18.0. For RACH, the network can configure 2-step and / or 4-step RA resources for MO-SDT. When both 2-step and 4-step RA resources for MO-SDT are configured, the UE 310 may select the RA type according to clause 9.2.6 of TS 38.300. The details of 2-step and 4-step RACH are not shown as they are not relevant.

[0210] For SDT procedure over RACH, if the UE 310 accesses a gNB other than the last serving gNB, the UL SDT data / signaling is buffered at the receiving gNB, and the receiving gNB triggers the Xn application protocol (XnAP) to retrieve UE context procedure. The receiving gNB indicates SDT to the last serving gNB and the last serving gNB decides whether to relocate the UE context or not. In case the last serving gNB decides to relocate the UE context as shown in Fig. 10, the procedure is described as follows: In case without UE context relocation steps 0-5 as in TS 38.300 and RA-based SDT with UE context relocation excluding step 6.

[0211] In case with UE context relocation steps 0-4 as in TS 38.300 and RA-based SDT with UE context relocation.

[0212] In both of the above cases it is assumed that the UE application has marked the uplink SDT data to the gNB 320 as Al data. The procedure continues with the following steps in Fig. 10:

[0213] Step 6: The receiving gNB 320, since there is Al data to transmit, starts a SDT based data channel request using the control plane. For this reason, the gNB 320 sends a specific message over a N2 interface to the AMF 330 that triggers a data channel setup in the control plane. The message sent by the gNB 320 may be denoted Start SDT based data channel request message.

[0214] Step 7: Upon receiving the message from the gNB 320 to setup the data channel, the AMF 330 performs message bus 100 selection by contacting the NRF in step 7. The result of this selection is that message bus instances are known to the AMF 330.

[0215] Step 8: The AMF 330 invokes on the message bus 100 a service to start Al data services for the user and the UE 320 to the message bus 100 passing also the reference of the discovered message bus by transmitting Start Al service request message comprising UE ID and message bus. This step also involves that the references of the serving message bus 100 are stored in the unified data management (UDM) for the subscriber (not shown in the Fig. for simplicity). The AMF 330 may also perform a UDM query for the subscriber to know the Al data configured for this subscriber, and pass this information to the message bus 100. The message bus 100 may use this information to configure the message bus 100 and support time requirements for those services.

[0216] Step 9: The message bus 100 configures for the UE Al data services. This step can be used to provide message bus dimensions for the internal queues and support the time requirements. This may include the generative Al subscribing to relevant content for the UE 310 in question, needed in order for the message bus 100 to be able to deliver the message to the generative Al.

[0217] Step 10: The message bus 100 has finished configuring itself and Al services for the subscriber, and sends a start Al services response message back to the AMF 330.

[0218] Step 11 : Upon receiving the start Al services response message, the AMF 330 sends a start SDT based data channel response back to the receiving gNB 320.

[0219] Step 12: The UL SDT data, which has been marked as Al data, is delivered from the receiving gNB 320 to the message bus 100.

[0220] Step 13: If the token matches the subscription pattern of the generative Al subscription, e.g., it refers to the topic for which generative Al has a subscription, or the token is directly addressed to the generative Al, the message bus 100 delivers the token to the generative Al, according to the generative Al subscription. The message bus 100 may store the token if no generative Al has subscription matching this content, or may also duplicate the token in case more than one generative Al is a subscriber of the relevant token topic.

[0221] Fig. 11 shows a procedure for the control plane in case the UE 310 is using SDT with configured grant Type 1 (i.e., CG-SDT). The overall procedure for CG-based Small Al data upload is defined in Fig. 11 is a logical simplified representation of TS 38.401. Preconditions for the procedure is that the UE is in RRC connected state.

[0222] Steps 0-2 as of 8.18.2-1 of TS 38.401 may be applied in Fig. 11.

[0223] Furter, the UE 310 goes in RRC inactive state and TA is valid. At this point new pay load for Al data is available, as the result of UE application performing the procedure described in Fig. 10. The UE 310 sends the Al data in the body of the physical uplink shared channel (PUSCH) transmission, which is marked as Al data to the gNB 320. This procedure reduces signaling overhead as compared to RACH based SDT, decreases the latency of setting up a PDU session and GTP tunnel and reduces UE power consumption since the UE 310 is in RRC inactive state. It also reduces radio resource allocation, since the transmission will happen only during the scheduled PUSCH.

[0224] Steps 3 to 10 in Fig. 11 are described as follow:

[0225] Step 3: As in step 6 in Fig. 10.

[0226] Step 4: As in step 7 in Fig. 10.

[0227] Step 5: As in step 8 in Fig. 10.

[0228] Step 6: As in step 9 in Fig. 10.

[0229] Step 7: As in step 10 in Fig. 10.

[0230] Step 8: As in step 11 in Fig. 10.

[0231] Step 9 and 9a: as in step 12 in Fig.10.

[0232] Step 10: Upload of Al data is performed from the gNB 320 to the user plane of the message bus 100 (MB UP) instead of via the UPF.

[0233] Fig. 12 shows a flow for a user plane procedure in case of large Al data / tokens. The procedure to set up a data channel for large Al data and token transfer is derived from a modification of TS 23.502 cl. 4.3.2.2.1 and is shown in Fig. 12. Precondition for this procedure is the following: the UE 310 is registered on the PLMN, and it is assumed that the message bus 100 and the MB CF are discovered by via NRF query; and the UE 310 has subscribed to at least one in-net Al service. The generative Al that hosts Al services for the user can also be discovered via NRF.

[0234] The steps in Fig. 12 are as the following:

[0235] Steps 0-7: As in steps l-7a,7b of TS 23.502 cl. 4.3.2.2.1, with the following modifications: In step 3 the AMF 330 provides a data plane flag to the SMF 350. In step 4, the UDM provides also the profile for Al services to the SMF 350. The UDM response to the SMF 350 includes the profile containing the Al services that the UDM is storing for this subscription, which includes IP address and port or fully qualified domain name (FQDN) for the LLMs or generative Al entities providing Al services for this subscription. For Al data sessions, these PCC rules may include default policy to be applied. Default policy is overridden by settings required for fulfilling message delivery time requirements, whenever those time requirements are specified.

[0236] Step 8: The SMF 350 performs message bus selection by contacting the NRF. The result of this selection is that message bus instances are known to the SMF 350. The AMF 330 may be responsible for message bus discovery in case of small Al data transfer while the SMF 350 is responsible for message bus discovery in case of large Al data transfer. This is because in case of small data transfer there is no SMF 350 involved since the UE-gNB data transfer happens using RRC control plane, and also because in large Al data transfer SMF 350 needs to allocate the necessary session resources depending on the Al services and Al requirements, as described below.

[0237] Step 9: After the SMF 350 has found out which instances of message bus 100 are serving the subscriber, from the SMF 350 to the message bus 100 a new message NsmfDataPlaneSetupRequest which includes the reference of the message bus 100 instance discovered in step 8, the profile for Al services retrieved in step 4 and the subscriber ID.

[0238] Step 10: Internally in the message bus 100 from the MB CF to the MB UP, the MB CF issues the request to setup Al services for the subscriber, including the subscriber ID and the message bus configuration that is determined according to the profile for Al services retrieved from step 9. This may include the queue dimensioning according to the time requirements associated with the Al services.

[0239] Step 11 : Optionally the MB CF may perform discovery of the generative Al entities that need to serve the subscriber via the message bus 100 communication. In that case the setup of those services is done in step 14, passing also the reference of the subscriber and of the message bus 100, to which the generative Al entity needs to send subscription. Step 12: Optionally the MB CF may also setup the Al services in the UE 310, by starting production and transmission of relevant Al data. In this step the MB CF may also configure the UE 310, such as deploying the tokenizer or the embedding in the UE 310, or configure the local device for these functions to be run in the Gen Al entity on the network side.

[0240] Step 13 : As above, from the AMF 330 to the UE 310, the AMF 330 provides the configuration messages received from MC BF in step 12 to the UE 310.

[0241] Step 14: If the MB CF has discovered generative Al entities for the subscriber to be configured, in this step the MB CF requests those generative Al entities to start the services for the subscriber, e.g., issuing a subscribe request for Al data or requesting relevant time requirements.

[0242] Step 15: From the MB CF to the SME 350, the MB CF responds to the SMF 350 that it has finished configuring Al services for the subscriber, starting and configuring all the required entities in the network, in the generative Al server entity e.g., LLM and in the UE 310. The MB CF in this message also includes the requested QoS for the data plane channel, which is derived according to the Al services and time requirements.

[0243] Step 16: Upon receiving the NsmfDataPlaneSetup response, the SMF 350 verifies that the QoS requirements requested by the MB CF can be enforced in the data plane and are consistent with the policy received by the PCF. If this check is successful, the SMF 350 issues an NsmfDataPlaneSetupConfirm. In case changes to the QoS of the data channel are required, the SMF 350 issues a PDU session modification to the data plane, according to the procedure defined in TS 23.502 clause 4.3.3.2. The NsmfDataPlaneSetupConfirm is sent only after the data plane session QoS is established according to the QoS requirements received in step 15. If the SMF 350 determines that those requirements cannot be fulfilled under current network conditions, it returns an NsmfDataPlaneSetupConfirm with an error code to the MB CF, and the MB CF in this way is informed that time requirements for token delivery cannot be fulfilled and it should either propose a different Al configuration or abort the services. The decision is implementation specific.

[0244] Step 17: From the SMF 350 to the message bus 100, the SMF 350 sends a DataPlane session establishment request to setup the data channel between the UE 310 and the message bus 100. This step is the equivalent of step 10a of TS 23.502 and may be used for packet detection, enforcement and reporting rules to be installed on the message bus 100 for the data plane session, for IP address allocation from the message bus 100 or other configuration requested on the message bus 100.

[0245] Step 18: From the message bus 100 to the SMF 350, the message bus 100 acknowledges the previous request with a DataPlane session establishment response. This step is the equivalent of step 10b of TS 23.502.

[0246] Steps 19 to 22 in Fig. 12 are as steps 11-14 of TS 23.502, so that the gNB 320 and RAN may setup the proper GTP tunnel and reserve resources according the required QoS.

[0247] After step 22 in Fig. 12, the UE 310 and the message bus 100 can exchange messages according to the established QoS that fulfills the message time requirements. In case Al data services have been established, e.g., with relevant generative Al entities on the network side. The message bus 100 may also start transferring those UE-generated tokens towards those Al data services.

[0248] If the token matches the subscription pattern of one or more generative Al subscription, e.g., the token refers to the topic for generative Gen Al has a subscription, or the token is directly addressed to the generative Al, the message bus 100 delivers the token to the generative Al according to the generative Al subscription. The message bus 100 may store the token if no generative Al has subscription matching this content, or may also duplicate the token in case more than one generative Al is a subscriber of the relevant token topic. In Fig. 12 there are two generative Al that are subscribed to the token. Therefore, the message bus 100 delivers the token to the first generative Al in step 22 and the second generative Al in step 23. Fig. 13 shows a flow diagram for generative Al which is applicable for both the user plane and the control plane procedures. The novel procedure defined is used by a generative Al entity for an Al data service to request timely message delivery to the message bus 100, and for the message bus 100 to enforce such timely token delivery through configurations on the UE client, on the message bus 100 and on the data plane, regardless this is based on control plane for small Al data transfer or on GTP channel in case of large Al data transfer. Preconditions for this procedure are the following: the UE 310 is registered on the PLMN network; the UE 310 has an active data channel, either as data channel session or UE connected via control plane; and the UE 310 has subscribed to at least one Al data service either in-net or in data network.

[0249] The steps in Fig. 13 are the following:

[0250] Step 1 : The generative Al entity e.g. , LLM, VLM, ViT or other deep learning neural network - either in the data network or in the core network - issues a subscribe request for an Al data service to the MB CF. In case the generative Al entity is in the data network, the subscribe request may be sent via NEF. The request may include a service delivery of type one-to-one, aggregation or topic. This request needs to include a max delay requested for the tokens related to the Al data service. The maximum delay is to be intended between the time the token has been sent by the producer in the UE application and the time it reaches the consumer in the generative Al entity.

[0251] Step 2: Upon reception of the subscribe request, the MB CF performs discovery of the message bus 100 that needs to serve this request. If the request is for a one-to-one service involving the UE 310 (the UE is the producer of the Al data that the generative Al entity is subscribing to), the request shall include the subscriber identity (ID). In this case the MB CF needs to know the UE state in order to understand the characteristics for the connectivity service involving the UE 310 and determine whether the requested maximum delay (also denoted max_delay) received in step 1 can be fulfilled. For this reason, the MB CF performs a NEF / PCF discovery to know which NEF / PCF is serving the requested UE. This discovery can be done through a query to the NRF by sending an Nnrf_NFDiscovery request as specified in clause 5.2.7.3 of TS 23.502.

[0252] Steps 3 and 4: Once the PCF / NEF has been discovered in step 2, from the MB CF to PCF / NEF a message is sent to query the UE state and know whether the UE 310 is in RRC_INACTIVE or RRC_CONNECTED state. The details of this query are not provided, but it is assumed that PCF / NEF can query this information from the AMF 330, which can be discovered by the PCF / NEF. The AMF 330 in turn can query this information from the gNB 320 over N2 interface. This query can also be used by the MB CF to retrieve the QoS of the data plane session - if present - for the UE 310 in question and - in case of SDT Al data transfer - the PUSCH characteristics such as periodicity and resources allocated. In case the maximum delay involves multiple UE producers, the state query needs to be performed for all the UE producers involved. The MB CF can perform the calculations to calculate the transfer time of the token across the network and the message bus 100 and determine whether the requested max_delay can be fulfilled.

[0253] Step 5 : Once the MB CF has determined whether the requested max_delay can be fulfilled, it also determines if changes are needed in order to provide fulfillment or whether the requested max_delay should be refused to the consumer. The determined changes are described in the next optional step. The MB CF can perform none, one or many of the following steps in order to try to fulfill the requested max_delay .

[0254] Step 6a: The MB CF may scale up or down the internal queues of the message bus 100, in order to introduce parallelism and decrease the time to traverse the queue.

[0255] Step 6b: In case data plane session is present, the MB CF may request a specific QoS, e.g., decrease the packet delay budget or increase the guaranteed flow bit rate (GFBR), for the data plane session. In this case it can send a Nnef_AF session with QoS request to the NEF by specifying that the requested QoS applies to a data plane session, by setting the data plane flag.

[0256] Step 7b: The NEF responds with a Nnef_AF session with QoS response. Step 6c: In case the UE 310 is in RRC_INACTIVE and CM-CONNECTED state, the MB CF may request the gNB 320 to update the timer for SDT transmission (CG-based). It is assumed that this operation can be done via the AMF 330.

[0257] Step 7c: The gNB 320 can acknowledge the request of the step above.

[0258] Step 6d: The MB CF can request a change of the threshold sdt-Data Volume to the gNB 320 in order to determine the maximum data volume that can be sent over the control plane.

[0259] Step 7d: The gNB 320 replies with an update for sdt-DataVolumeThreshold response. It is assumed that this operation can be done via the AMF 330.

[0260] Step 8: After performing zero or more of the operations described in steps 6a, 6b / 7b, 6c / 7c, 6d / 7d, the MB CF can send a subscribe response message back to the consumer. In case the max_delay_requested cannot be fulfilled, the MB CF can include a max_delay_accepted in the response, where max_delay_accepted > max_delay_requested.

[0261] Fig. 14 shows configuration of Al services for a UE 310. The user of the UE 310 may trigger this via a web portal or by requesting a new service to a customer service which is implementation specific. The result of this action is the activation of this procedure. The procedure ends with a new generative Al entity set up as consumer of Al data in the message bus service where the UE 310 is the producer.

[0262] The procedure is described in Fig. 14 and the steps are the following:

[0263] Step 1 : An application, a web portal or a network management system can request the setup of an Al service to the NEF. The request needs to include the fully qualified domain name (FQDN) or IP address and port of the generative Al entity, the type of subscription (i.e., one to one, topic, aggregate) and the related parameters (i.e., in case of one to one the subscriber identity, in case of topic the topic string, in case of aggregate the information required to aggregate the tokens from several subscriber into a single token delivered to the consumer). Time requirements may also be added for the delivery of the messages to the consumers, i.e., the generative Al. The result of this operation is that the Al service information is stored in the UDM subscription for the subscribers interested by this Al service.

[0264] Step 2: The NEF issues a setup Al service request to the UDM, including the related parameters, as described in step 1.

[0265] Step 3: The UDM issues a setup Al service response to the NEF.

[0266] Step 4: The NEF issues a setup Al service response to the initial entity creating the request in step 1.

[0267] Step 5: The application, web portal or network management needs to activate the Al service, after the setup, on the generative Al entity by a request sent to the generative Al entity.

[0268] Step 6: The request in step 5 triggers the generative Al entity to issue a subscribe message to the MB CF.

[0269] Step 7: The MB CF configures the MB UP. If the request in step 6 includes time requirements, the MB CF uses this time requirements to configure the queues in the message bus 100 or execute the operations described previously. Step 8: The MB CF may trigger the involved UEs to establish a related connectivity, either using control plane or using data plane session. This can be done by triggering related service requests on the NEF.

[0270] Step 9: The NEF triggers related UE operations as described in step 8.

[0271] Step 10: From the message bus 100 to the UE 310, the message bus 100 requests UE configuration, e.g., which Al data should be produced, which frequency, if tokenizer and embedding is to be deployed on the client, etc.

[0272] Step 11 : From the UE 310 to the message bus 100, the UE 310 acknowledges receiving the message with a response sent to the message bus 100.

[0273] The consumption of the Al data tokens by generative Al entities is not specified in this procedure. Previously it was proposed a novel solution for a consumer (generative Al) of a message bus service to request timely delivery of tokens through a message bus 100, according to a consumer provided deadline, or maximum delay. The MB UP and MB CF of the message bus 100 may perform calculations on the time to traverse the network and the message bus 100 according to the current QoS and current message bus conditions and determine whether the requirement of max_delay can be fulfilled. This section provides implementation examples on how the message bus 100 can verify the support of the max_delay and put in place actions to modify network and message bus configuration in order to fulfill the max_delay .

[0274] Fig. 15 shows examples of different delays in token delivery from the producer of the token (in this case UE) to the consumer (in this case generative Al) when the delivery happens via the mobile network. Figs. 16 to 18 show and illustrate examples of token delivery within the scope of examples of the invention for three different cases of token delivery i.e.:

[0275] • Fig 16 shows the case of so called “one2one” token delivery service, where one token from a UE is intended to be received by one generative Al consumer.

[0276] • Fig 17 shows the case of so called “aggregator” token delivery service, where the tokens from multiple UEs are intended to be aggregated together according to some rule by the message bus 100 and received in aggregated form by one generative Al consumer.

[0277] • Fig 18 shows the case of so called “one2many” token delivery service, according to a topic where one token from a UE is intended to be received by many generative Al consumers: all the generative Al consumers that subscribe to the specific topic.

[0278] The guarantee for max delay is requested by the generative Al. The max delay is referred to the token(s) received by the generative Al. In Fig. 15 it is shown how the delay on generative All (Gen Al) is different from the delay on generative AI2 (Gen AI2), since before the delivery to Gen AI2 the message bus 100 must wait to receive first the tokens from UE1 and UE2 and then aggregate both in the token(s) that are sent to Gen AI2.

[0279] Al data and token processing:

[0280] • According to the new proposed architecture, the MB UP is the termination point of the data traffic associated with the data plane, whether this traffic travels on control plane, or whether a dedicated bearer is established.

[0281] • It is responsibility of the MB CF, i.e., the CP function of the message bus, to setup the data plane channel between the UE 310 and the MB UP, via the RAN, according to the timing requirements of the producers and of the consumers

[0282] In the example shown in Fig. 15, it is assumed that a message bus 100 has two consumers, i.e., Gen All and Gen AI2, and two producers, i.e., UE1 and UE2. The two consumers receive the Al data from both producers, but with different values of max_delay, which is, respectively: Gen All has strict real time requirement with maximum delay on token reception dl for tokens of UE1 and UE2: and Gen AI2 has strict real time requirement with maximum delay on token reception d2. Such requirement is not on the token as originated by the producers but for the aggregated tokens of UE1 and UE2. In summary, the message bus 100 thus has to deliver:

[0283] • Tokens from UEl to Gen All within delay on Gen All < dl; and

[0284] • Aggregated tokens from UE1 and UE2 to Gen AI2 within delay on Gen All < d2.

[0285] Before sending the tokens to Gen AI2, the message bus 100 must first receive the tokens from both UE1 and UE2, then it shall aggregate the tokens. Therefore, in this example it is assumed d2 > dl . The message bus 100:

[0286] • Receives the time requirements from the consumers, i.e., d, which is the maximum delay (max_delay) allowed on a token. Value d may be different per type of token received and type of service.

[0287] • Provides three types of services: a one2one token delivery service, a topic token delivery service and an aggregation token delivery service used in most analytics.

[0288] • Negotiates with PCF / SMF, the bearer for the data plane connection, requesting PDB and GFBR according to dl and d2. • Dimensions internal entities in the MB UP.

[0289] • Decides to set up the data plane channel, depending on the signaling received from the UE 310, by interacting with the PCF / SMF.

[0290] • Decides which optional services should be provided on the token delivery while trying to fulfill the max_delay. For example, persistence could be a service that the message bus 100 could decide to disable if it makes the delay higher than maximum delay allowed.

[0291] The end-to-end (end2end) token delivery time guarantee is requested by the consumer and applies to every single token that is received by the consumer. It is possible to calculate this time value E2E TIME as:

[0292] E2E TIME = T (UE-RAN) + T (RAN-MSGBUS-I) + T (TRAVERSE MSG BUS) + T (MSGBUS-O - GEN Al), where parameter T(UE-RAN) depends on the QoS of the RAN, while parameter T(RAN-MSGBUS-I) mostly depends on the core network and the transport network. Parameter T (TRAVERSE MSG BUS) depends on the specific service that is provided by the message bus 100 and on the performance of the message bus 100 itself, which may depend on the internal queue configurations. Parameter T(MSGBUS-O - GEN Al) depends on the segment between the message bus 100 and the generative Al consumer.

[0293] How the UE 310, message bus 100, and the generative Al entities process tokens during the token transfer depends firstly on the type of service that the message bus 100 is providing. Three types of token delivery services may be assumed as previously mentioned, i.e., a one-to-one token delivery service, a topic token delivery service, and an aggregation token delivery service, which are listed in the Figs.

[0294] Fig. 16 describes the architecture and the token processing by the message bus 100 in case of one-to-one token delivery service which involves tokens produced by one producer to be addressed directly to one single consumer. In this case it may be assumed that the message bus 100 receives the token from the sender, and places the token in a sender queue. Each sender can be allocated a dedicated queue for better scalability. The sender with higher throughput may also be allocated several queues. Optionally, the message bus 100 can provide persistence service for the queue, which means that the queue is replicated in a persistent memory that - in case of faults in the message bus 100 - guarantees that no tokens are lost. A broker or queue handler sequentially picks the tokens from a sender queue and pushes the tokens in a receiver queue. The receiver queue is addressed to one specific consumer (generative Al). The message bus 100 can allocate more than one broker to a queue, or can allocate a broker to more than one queue. These different dimensioning enable the message bus 100 to scale / up or down the time that each token takes to traverse the whole route from the sender to the receiver.

[0295] Fig. 17 describes the architecture and the token processing by the message bus 100 in case of aggregation type of delivery service which involves tokens produced by several producers to be aggregated and then addressed as a single token to one single consumer. This is the case for inferences or predictions that need to be done on the data collected over a large number of producers, and such inference or prediction cannot be done unless all the data from all the different producers is collected. In this case it is assumed that the message bus 100 receives the token from the sender, and places it in a sender queue. Each sender can be allocated a dedicated queue for better scalability . The sender with higher throughput may also be allocated several queues. Optionally the message bus 100 can provide persistence service for the queue, which means that the queue is replicated in a persistent memory that - in case of faults in the message bus 100 - guarantees that no tokens are lost. One or more broker(s) pick the tokens that are supposed to be aggregated together from one of the sender queues and places the tokens in an aggregator queue. An aggregator is responsible for picking the tokens to be aggregated and aggregate them together in an aggregated token. The aggregated token is finally placed in the recipient queue, in order to be routed to the destination generative Al. Also, in this case the message bus 100 can dimension the number of sender and receiver queues, the number of aggregators, the number of aggregation queues and the number of brokers and whether or not to provide persistence to scale up or down the delay of each token in traversing the message bus 100.

[0296] Fig. 18 describes the architecture and the token processing by the message bus 100 in case of topic type of delivery service. In the topic token delivery service, the token is published to a topic, and any consumer who subscribes to that topic will receive the token. This is the case when there is the need to enable 1: n relationships between publishers and subscribers, allowing subscribers to select particular tokens from a published token stream where n is an integer. In a similar fashion as already described for the other delivery types, and according to the architecture described in Fig. 18, the topic type of delivery involves the token to first traverse a sender queue. When the token reaches the top of the queue a broker will pick the token from the sender queue and insert the token into a topic queue. Here the token will wait for a copier to make a copy of the token for each of the consumers who subscribed to the specific topic. And then it will be placed in a sender queue, waiting to be sent to the intended generative Al recipient. In this case, the message bus 100 can dimension - in addition to the queues - also the brokers and the copiers in order to minimize the time that the token takes to traverse the message bus 100.

[0297] When supporting timely token data delivery, the message bus 100 needs to calculate the time for a single token towards a consumer to traverse the message bus 100 in each type of token delivery service. This calculation is exemplified below, depending on the delivery service, assuming N number of producers and M number of consumers. Two different queues are also assumed, i.e., one for the consumer, in the input of the message bus 100 and one for the producer, in the output of the message bus 100. It is also assumed that the message bus 100 is providing persistence, which adds some delay e.g., due to storage on a hard drive.

[0298] According to the architecture options shown in Fig. 16 to 18 it is possible to determine the time that a token takes to traverse the message bus 100, as exemplified below.

[0299] In case of one-to-one delivery service, the time value T (TRAVERSE MSG BUS) is given by:

[0300] T (TRAVERSE MSG BUS) = Tsender_queue + Tpersistence + Tone2one_routing + Tconsumer_queue, where:

[0301] • T (TRAVERSE MSG BUS) is the total time it takes for the token from the time instance the token enters the message bus 100 to the time instance when the token leaves towards its destination.

[0302] • Tsender_queue is the time the token stays in the sender queue.

[0303] • Tpersistence is the time that message bus 100 takes to store the token in persistent memory in case persistence has to be provided. This is typically done before or while the token is pushed in the sender queue.

[0304] • Tone2one_routing is the time it takes for the broker to pick the token from the sender queue and insert the token into the receiver queue.

[0305] • Tconsumer_queue is the time the token stays in the sender queue before being actually transmitted towards the receiver.

[0306] It is noted that the formula depends on the actual architecture implemented by the message bus 100. By an opportune dimension of the resources for each of the elements in the architecture, the message bus 100 can calculate the time to traverse the message bus 100 and reduce the components in the formula to try to fit into the max delay requested by the consumer. In case of aggregation delivery service, assuming tokens are aggregated sequentially as they arrive, the time value T (TRAVERSE MSG BUS) is given by:

[0307] T (TRAVERSE MSG BUS) = max ( Tsendeiyqueue, + Tpersistence; + Tsender2aggregator_routingj) +

[0308] i=l...N

[0309] i=i...N Taggregation i + Tconsumer_queue,

[0310] where the term max ( Tsendeiyqueue, + Tpersistence; + Tsender2aggregator_routing;) is explained as follows.

[0311] i=l...N

[0312] Assuming that the aggregated token is composed of N number of tokens produced by N number of different UEs, and assuming that all of the N tokens have been delivered to the message bus 100, since the aggregated token cannot be prepared by the message bus 100 unless all the N needed tokens are received and are ready to be aggregated, the first addendum of the time to traverse the message bus 100, i.e., max ( Tsender_queue; + Tpersistence; + Tsender2aggregator_routing;), is obtained i=l...N

[0313] by the maximum (across all of the N tokens) of the sum of the time the token i, where i is an integer value from 1 to N, stays in its sender queue, the time needed for its persistence and the time needed to route the token from its sender queue to the aggregation queue. The second addendum, i.e., I=I...N Taggregationi;is the sum of the time needed to aggregate all the N tokens. The third addendum, i.e., Tconsumer_queue, is the time that the aggregated token stays in the consumer queue before being sent to the actual consumer.

[0314] In case of topic delivery service, the time value T (TRAVERSE MSG BUS) is given by:

[0315] T (TRAVERSE MSG BUS) = Tsender_queue + Tpersistence + Tone2topic_routing + Zi=i...MTcopy , + Tconsumer_queue,

[0316] where Tone2topic_routing is the time it takes to route the message from the sender queue to the topic queue and eventually being processed by the topic queue, Zi=i...MTcopy , is the time taken to make M number of copies of the original token, each of the copy being addressed to one of the M number of consumers.

[0317] When subscribing to a token delivery service, the generative Al can request a guaranteed max_delay to the message bus for the E2E TIME value. The message bus 100 can estimate the value of the E2E TIME according to the above formulas and decide whether it can agree or not. In order to meet the requested guaranteed max_delay, the message bus 100 can:

[0318] • Decrease the value T (UE-RAN) of the senders by acting on quality-of-service (QoS) e.g., acting on PDB and GFBR.

[0319] • Decrease the values T (RAN-MSGBUS-I) and T (MSGBUS-O - GEN Al) which are propagation delays, depending on the relative location of the UE 310 in relation to the message bus 100, and the location of the generative Al with respect of the message bus 100, assuming no further routers or nodes are arranged in the token transfer chain. • Minimize the value T (TRAVERSE MSG BUS) by acting on the number of brokers, copiers and aggregators, and the central processing units (CPU) resources allocated to them.

[0320] Considering the products involved and the possible forms of the products for sales are fully considered, we need to make some considerations related to the message bus 100, including MB UP and MB CF, which are currently not part of a 3GPP core network (CN) and, if introduced as examples of the invention are foreseeing, they may be candidate for standardization.

[0321] We believe that MB UP and MB CF of the message bus 100 can be in the future standalone and distinct NFs. However, it is possible that core network vendors may implement them in different forms when placing them on the market. The MB CF could be deployed together with the SME 350, since it manages a data session and interacts with the SMF 350 and in some aspect similarly as the SMF 350 when the data plane session is set up. Alternatively, the MB CF could be also bundled with AMF 330, in case only the SDT functionality is provided. Other options include colocation with PCF and NEE Finally, it could be deployed together with a NWDAF, especially if the NWDAF will evolve to include generative Al. The MB UP could be deployed together with UPF, or it could be deployed in the same node as the Gen Al or of the NWDAF. The MB UP and MB CF of the message bus 100 could be realized with a software modification of an existing message bus, such as Apache Kafka. Furthermore, any method according to examples of the invention may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as previously mentioned a ROM, a PROM, an EPROM, a flash memory, an EEPROM, or a hard disk drive.

[0322] Moreover, it should be realized that the message bus 100, the AMF 330 and the SMF 350 comprise the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing or implementing examples of the invention. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, TCM encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

[0323] Therefore, the processors) of the message bus 100, the AMF 330 and the SMF 350 may comprise, e.g., one or more instances of a CPU, a processing unit, a processing circuit, a processor, an ASIC, a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

[0324] A network access node herein may also be denoted as a radio network access node, an access network access node, an access point (AP), or a base station (BS), e.g., a radio base station (RBS), which in some networks may be referred to as transmitter, “gNB”, “gNodeB”, “eNB”, “eNodeB”, “NodeB” or “B node”, depending on the standard, technology and terminology used. The radio network access node may be of different classes or types such as e.g., macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby the cell size. The radio network access node may further be a station, which is any device that contains an IEEE 802.11-conformant media access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). The radio network access node may be configured for communication in 3GPP related long term evolution (LTE), LTE-advanced, fifth generation (5G) wireless systems, such as new radio (NR) and their evolutions, as well as in IEEE related Wi-Fi, worldwide interoperability for micro wave access (WiMAX) and their evolutions.

[0325] A client device herein may be denoted as a user device, a user equipment (UE), a mobile station, an internet of things (loT) device, a sensor device, a wireless terminal and / or a mobile terminal, and is enabled to communicate wirelessly in a wireless communication system, sometimes also referred to as a cellular radio system. The UEs may further be referred to as mobile telephones, cellular telephones, computer tablets or laptops with wireless capability. The UEs in this context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and / or data, via a RAN, with another communication entity, such as another receiver or a server. The UE may further be a station, which is any device that contains an IEEE 802.11-conformant MAC and PHY interface to the WM. The UE may be configured for communication in 3GPP related LTE, LTE-advanced, 5G wireless systems, such as NR, and their evolutions such as 6G networks, as well as in IEEE related Wi-Fi, WiMAX and their evolutions.

[0326] Finally, it should be understood that the invention is not limited to the examples described above, but also relates to and incorporates all examples within the scope of the appended independent claims.

Claims

CLAIMS1. A message bus (100) configured to:receive a first request (510) from an artificial intelligence, Al, entity (400) associated with an Al service, the first request (510) indicating a request for a transfer of a set of tokens (120) from a client device (310) of a mobile network (300) to the Al entity (400) and a time limit associated with the transfer of the set of tokens (120); andselect a first token transfer procedure (610) or a second token transfer procedure (620) for the transfer of the set of tokens (120) based on the time limit, whereinthe first token transfer procedure comprises the transfer of the set of tokens (120) from the client device (310) to the Al entity (400) via a control plane of the mobile network (300), andthe second token transfer procedure comprises the transfer of the set of tokens (120) from the client device (310) to the Al entity (300) via a user plane of the mobile network (300).

2. The message bus (100) according to claim 1, wherein the time limit is based on a first time instance (Tl) when the client device (310) starts transmitting the set of tokens (120) and a second time instance (T2) when the Al entity (300) receives the set of tokens (120).

3. The message bus (100) according to claim 1 or 2, wherein the selection of the first token transfer procedure (610) or the second token transfer procedure (620) comprises:select the first token transfer procedure (610) or the second token transfer procedure (620) meeting the time limit.

4. The message bus (100) according to claim 3, configured to:select the first token transfer procedure (610) or the second token transfer procedure (620) further based on: a volume of the set of tokens (120), and a periodicity of the transfer of the set of tokens (120).

5. The message bus (100) according to claim 3 or 4, configured to:select the first token transfer procedure (610) or the second token transfer procedure (620) further based on: an operator policy for the transfer of the set of tokens (120), and a power consumption of the client device (310) for the transfer of the set of tokens (120).

6. The message bus (100) according to any one of the preceding claims, configured to:transmit a first response (520) to the Al entity (300) prior to transfer the set of tokens (120), the first response (520) indicating an acknowledgment of the transfer of the set of tokens (120) within the time limit.

7. The message bus (100) according to any one of the preceding claims, wherein the first token transfer procedure (610) comprises:receive a second request (530) from an access and mobility management function, AMF, (330), the second request (530) indicating an identity of the client device (310) and one or more configuration parameters associated with the transfer of the set of tokens (120);allocate one or more token transfer resources of the message bus (100) for the transfer of the set of tokens (120) based on the second request (530) and the time limit; andtransmit a second response (540) to the AMF (330), the second response (540) indicating that the message bus (100) will transfer the set of tokens (120) within the time limit.

8. The message bus (100) according to claim 7, configured to:receive the set of tokens (120) from the client device (310) via a network access node (320) of the mobile network (300); andforward the set of tokens (120) to the Al entity (400).

9. The message bus (100) according to any one of the preceding claims, wherein the second token transfer procedure (620) comprises:receive a third request (550) from a session management function, SMF, (350), the third request (550) indicating an identity of the client device (310) and one or more configuration parameters associated with the transfer of the set of tokens (120),allocate one or more token transfer resources of the message bus (100) for the transfer of the set of tokens (120) based on the third request (550) and the time limit; andtransmit a third response (560) to the SMF (350), the third response (560) indicating that the message bus (100) will transfer the set of tokens (120) within the time limit.

10. The message bus (100) according to claim 9, configured to:receive the set of tokens (120) from the client device (310) via a GPRS tunneling protocol, GTP-U, tunnel (380) arranged between the client device (310) and the message bus (100); andforward the set of tokens (120) to the Al entity (400).

11. The message bus (100) according to any one of claims 7 to 10, wherein the one or more configuration parameters comprises: an expected maximum size of tokens in the set of tokens (120), a periodicity of the transfer of the set of tokens (120), and one or more types of Al services used by the client device (310) and associated with the transfer of the set of tokens (120).

12. The message bus (100) according to any one of claims 7 to 11, wherein the one or more configuration parameters comprises: a mapping between an Al service and one or more Al service topic identifiers, and wherein the message bus (100) is configured to:select the Al entity (400) among two or more Al entities (400, 400') for the transfer of the set of tokens (120) based on the mapping between an Al service and one or more Al service topic identifiers.

13. The message bus (100) according to claim 12, wherein selecting the Al entity (400) comprises:receive a token among the set of tokens (120) from the client device (310), wherein the token is marked with an Al service topic identifier; andselect the Al entity (400) based on the marked Al service topic identifier and the mapping between an Al service and one or more Al service topic identifiers.

14. The message bus (100) according to any one of claims 7 to 13, wherein the one or more token transfer resources comprises one or more internal token queues and one or more token queue handlers.

15. The message bus (100) according to claim 14, configured to:interconnect the one or more internal token queues and the one or more token queue handlers.

16. An AMF (330) configured to:transmit a second request (530) to a message bus (100), the second request (530) indicating an identity of a client device (310) and one or more configuration parameters associated with a transfer of the set of tokens (120) from a client device (310) of a mobile network (300) to an Al entity (400) associated with an Al service; andreceive a second response (540) from the message bus (100), the second response (540) indicating that the message bus (100) will transfer the set of tokens (120) within a time limit associated with the transfer of the set of tokens (120).

17. The AMF (330) according to claim 16, configured to:retrieve the one or more configuration parameters based on a user profile of the client device (310).

18. The AMF (330) according to claim 16 or 17, wherein the one or more configuration parameters comprises: an expected maximum size of tokens in the set of tokens (120), a periodicity of the transfer of the set of tokens (120), and a type of Al service used by the client device (310).

19. An SMF (350) configured to:transmit a third request (550) to a message bus (100), the third request (550) indicating an identity of a client device (310) and one or more configuration parameters associated with a transfer of the set of tokens (120) from a client device (310) of a mobile network (300) to an Al entity (400) associated with an Al service; andreceive a third response (560) from the message bus (100), the third response (560) indicating that the message bus (100) will transfer the set of tokens (120) within a time limit associated with the transfer of the set of tokens (120).

20. The SMF (350) according to claim 19, configured to:retrieve the one or more configuration parameters based on a user profile of the client device (310).

21. The SMF (350) according to claim 19 or 20, wherein the one or more configuration parameters comprises: an expected maximum size of tokens in the set of tokens (120), a periodicity of the transfer of the set of tokens (120), and a type of Al service used by the client device (310).

22. The SMF (340) according to any one of claims 19 to 21, configured to:receive a control message (570) from the client device (310), wherein the control message (570) indicates a request to establish a GTP-U tunnel for the transfer of the set of tokens (120); andconfigure the GTP-U tunnel (380) for the transfer of the set of tokens (120) from the client device (310) to the message bus (100) based on the control message (570).

23. The SMF (340) according to claim 22, wherein the request to establish a GTP-U tunnel for the transfer of the set of tokens (120) is a flag.

24. A method (200) for a message bus (100), the method (200) comprising:receiving (202) a first request (510) from an artificial intelligence, Al, entity (400) associated with an Al service, the first request (510) indicating a request for a transfer of a set of tokens (120) from a client device (310) of a mobile network (300) to the Al entity (400) and a time limit associated with the transfer of the set of tokens (120); andselecting (204) a first token transfer procedure (610) or a second token transfer procedure (620) for the transfer of the set of tokens (120) based on the time limit, whereinthe first token transfer procedure comprises the transfer of the set of tokens (120) from the client device (310) to the Al entity (400) via a control plane of the mobile network (300), andthe second token transfer procedure comprises the transfer of the set of tokens (120) from the client device (310) to the Al entity (300) via a user plane of the mobile network (300).

25. A method (730) for an AMF (330), the method (730) comprising:transmitting (732) a second request (530) to a message bus (100), the second request (530) indicating an identity of a client device (310) and one or more configuration parameters associated with a transfer of the set of tokens (120) from a client device (310) of a mobile network (300) to an Al entity (400) associated with an Al service; andreceiving (734) a second response (540) from the message bus (100), the second response (540) indicating that the message bus (100) will transfer the set of tokens (120) within a time limit associated with the transfer of the set of tokens (120).

26. A method (750) for an SMF (350), the method (750) comprising:transmitting (752) a third request (550) to a message bus (100), the third request (550) indicating an identity of a client device (310) and one or more configuration parameters associated with a transfer of the set of tokens (120) from a client device (310) of a mobile network (300) to an Al entity (400) associated with an Al service; andreceiving (754) a third response (560) from the message bus (100), the third response (560) indicating that the message bus (100) will transfer the set of tokens (120) within a time limit associated with the transfer of the set of tokens (120).

27. A computer program with a program code for performing a method according to claim 25 or 26 when the computer program runs on a computer.

Images