Devices and methods for supporting a mobile network and application sandbox

Abstract

A network entity of a mobile network (100) is disclosed for supporting a sandbox environment (110), wherein the sandbox environment (110) comprises a digital twin (120) of an application and a digital twin (130) of the mobile network (100) and wherein the digital twin (130) of the mobile network (100) is configured to exchange data packets with the digital twin (120) of the application. The network entity is configured to provide configuration data to an application server for configuring the application server to implement at least the digital twin (120) of the application of the sandbox environment (110). Moreover, the network entity is configured to receive one or more results from the application server, wherein the one or more results are based on the sandbox environment (110).

Description

[0001] DEVICES AND METHODS FOR SUPPORTING A MOBILE NETWORK AND APPLICATION SANDBOX

[0002] TECHNICAL FIELD

[0003] The present invention relates to devices and methods for communication and data processing. More specifically, the present invention relates to devices and methods for supporting a mobile network and application sandbox.

[0004] BACKGROUND

[0005] A digital twin (DT) is the real-time representation of a physical object in cyber space. DTs have been adopted in various sectors ranging from smart buildings to robotics. They are driven by large amounts of real-time and historical data that are necessary for analytics services and accurate representation of the physical object in the digital world. These data are also used to train simulation models that aim to predict the system behavior in the future.

[0006] DTs can be used to simulate a potential configuration scenario prior to the actual deployment, also known as the sandboxing technique. This offers a safe and isolated environment to perform tests for potential future actions to prevent disruptions to the physical processes in cyber physical systems (CPSs). Therefore, sandboxing based on DTs is a very powerful and useful tool for experimenting and answering “what-if’ questions, without causing any real-world damage. This can enhance CPSs by enabling predictive maintenance and fault-detection and optimizing system-level decision-making.

[0007] A reference architecture of a network DT is introduced in ITU-T Y.3090, “Digital twin network - Requirements and architecture”, Feb. 2022 that performs various services such as failure detection or traffic analysis based on the collected data and emulation. The goal of the proposed network DT is to improve the operational efficiency and reduce system downtime by identifying future malfunctions proactively thanks to the digital twinning technology. Such a design is particularly useful for cyber-physical applications, where the application lives in the physical world, hence a potential failure would lead to serious damage in its surroundings. Through the sandboxing technique, such situations can be identified in advance without affecting the physical field device.

[0008] There are a wide range of cyber-physical applications that are deployed over mobile networks (see, for instance, 3GPP, “TS 22.104 Service requirements for cyber-physical control applications in vertical domains (vl9.2.0), June 2024”). Typically, a large portion of these applications request an ultra-reliable and low-latency communication service from the network to mitigate the adverse effects of network’s imperfections on the application-level performance. As the variety in cyber-physical applications and use cases increases through the advances in computing technologies and more devices become connected through mobile networks, the efficient usage of the limited network resources become crucial to facilitate the deployment of such systems in larger scales. To that end, understanding the direct relationship between the application performance, called service experience in 3GPP, and the offered connectivity service (i.e., Quality-of-Service) is pivotal to getting rid of existing inefficiencies in the network resource utilization. In particular, in case of high network load or congestion situations, predicting the service experience for a given QoS helps to increase the network capacity by dynamically adjusting the distribution of network resources among different users. This needs to be done in a way that a potential decrease in the offered QoS leads to minimal decrease in the service experience, which has been largely neglected in the past.

[0009] SUMMARY OF THE INVENTION

[0010] It is an objective of the present disclosure to provide improved devices and methods for supporting a mobile network and application sandbox. The foregoing and other objectives are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures. In the following one or more of the following acronyms and abbreviations may be used:

[0011] AF Application Function

[0012] AS Application Server

[0013] DT Digital Twin

[0014] EAS Edge Application Server

[0015] EP Endpoint gNB gNodeB

[0016] NW Network

[0017] NWDAF Network Data Analytics Function

[0018] NEmF Network Emulation Function

[0019] NEF Network Exposure Function

[0020] PDU Protocol Data Unit

[0021] QoS Quality of Service

[0022] UE User Equipment

[0023] According to a first aspect, a network entity is provided for a mobile network for supporting a sandbox environment, wherein the sandbox environment comprises a digital twin of an application (or application service) and a digital twin of the mobile network and wherein the digital twin of the mobile network is configured to exchange data packets with the digital twin of the application. The network entity according to the first aspect is configured to provide configuration data (for instance, by means of a configuration message) to an application server for configuring the application server to implement at least the digital twin of the application of the sandbox environment. Moreover, the network entity according to the first aspect is configured to receive one or more results from the application server, wherein the one or more results are derived based on the sandbox environment. As will be described in more detail in the following, the network entity according to the first aspect allows the configuration of the sandbox environment including a digital twin of an application and a digital twin of a mobile network to simulate a predicted scenario, which in return limits the search space of all possible scenarios.

[0024] In a further possible implementation form, the network entity is configured to provide the configuration data to the application server for configuring the application server to implement the digital twin of the application and the digital twin of the mobile network. This allows the network entity to provide the application server with the configuration data required to implement the sandbox environment.

[0025] In a further possible implementation form, the configuration data comprises analytics information about one or more data paths between two endpoints of the mobile network. This allows the application server to simulate a data path between two endpoints of the mobile network more accurately thanks to the availability of the analytics data, which in return renders also the results generated by the sandbox environment more accurate.

[0026] In a further possible implementation form, the network entity is configured to provide the analytics information about the one or more data paths between two endpoints of the mobile network, in response to a request from the application server. This contributes to the accuracy of the results generated by the sandbox environment as above, while also having the benefit of reducing the configuration data traffic between the mobile network and the application server thanks to the request / response pattern. In a further possible implementation form, the network entity is configured to implement the digital twin of the mobile network of the sandbox environment, wherein the digital twin of the mobile network of the sandbox environment is configured to exchange data packets with the digital twin of the application. This reduces the amount of analytics information that is required to be exposed to the application server in order to implement the DT of the mobile network.

[0027] In a further possible implementation form, the network entity is configured to provide the configuration data to the application server for configuring the application server to implement the digital twin of the application of the sandbox environment, in response to a request from the application server.

[0028] In a further possible implementation form, the network entity is configured to provide the configuration data to the application server directly and / or via a network function, in particular a Network Exposure Function.

[0029] In a further possible implementation form, the request from the application server comprises: a forwarding address to which the data packets provided by the digital twin of the mobile network are to be forwarded; a data path defined by one or more data path endpoints and / or a data path direction; and / or a QoS indication indicative of a desired QoS provided by the digital twin of the mobile network. The forwarding address provided by the application server informs the DT of the mobile network about the location of the DT of the application, i.e., the address at which the digital twin of the application resides. The data path information allows the application server to request the DT of the mobile network to behave like (i.e., emulate) a data path between two particular endpoints. The QoS indication allows the application server to request the DT of the mobile network to emulate a particular data path characterized by the provided QoS information.

[0030] In a further possible implementation form, the configuration data comprises: a network entity address to which the data packets provided by the digital twin of the application are to be transmitted; and / or a sandboxing session identifier. The address information is necessary if the DT of the mobile network is configured to receive the data packets at a third location that is different than the addresses being used to exchange the configuration information (e.g., on a third hosting device, at a specific UDP port that is different than the one used for the exchange). The sandboxing session identifier can be used to identify the target of a (re)configuration message sent by the application in the future, as well as, can assist the network to relate the simulation results to a target application if the results are announced together with the sandboxing session identifier.

[0031] In a further possible implementation form, the network entity is configured to allocate the sandboxing session identifier to the sandbox environment.

[0032] In a further possible implementation form, the network entity is implemented as a network function of the mobile network.

[0033] In a further possible implementation form, the one or more results based on the sandbox environment comprise a service experience indication indicative of the performance of the digital twin of the application and / or a Quality of Service, QoS, indication indicative of a predicted QoS provided by the digital twin of the mobile network. This allows the network to learn the relationship between the service experience and the QoS, for instance, by using artificial intelligence and machine learning. This can in return be utilized to use the network and energy resources more efficiently or repurpose the already utilized resources for better service experience.

[0034] In a further possible implementation form, the network entity is configured to receive a ServiceExperiencelnfoPerApp message (as specified in 3GPP TS 29.517, § 5.6.2.7) from the application server, wherein the ServiceExperiencelnfoPerApp message comprises the one or more results, in particular the QoS indication. In a further possible implementation form, the network entity is configured to receive from the application server together with the one or more results an application identifier indicative of the digital twin of the application. This helps the network to relate multiple results to each other that correspond to the same application.

[0035] According to a second aspect, a method is provided for operating a network entity of a mobile network for supporting a sandbox environment, wherein the sandbox environment comprises a digital twin of an application and a digital twin of the mobile network and wherein the digital twin of the mobile network is configured to exchange data packets with the digital twin of the application, wherein the method comprises: providing configuration data (for instance, by means of a configuration message) to an application server for configuring the application server to implement at least the digital twin of the application of the sandbox environment; and receiving one or more results from the application server, wherein the one or more results are based on the sandbox environment, e.g. obtained with the sandbox environment.

[0036] The method according to the second aspect can be performed by the network entity according to the first aspect. Thus, further features of the method according to the second aspect result directly from the functionality of the network entity according to the first aspect, as well as its different implementation forms described above and below.

[0037] According to a third aspect a computer program product is provided, comprising program code which causes a computer or a processor to perform the method according to the second aspect, when the program code is executed by the computer or the processor.

[0038] Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.

[0039] BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In the following, embodiments of the present disclosure are described in more detail with reference to the attached figures and drawings, in which:

[0041] Fig. la shows a schematic diagram illustrating a sandbox environment including a digital twin of a mobile network implemented by a network entity according to an embodiment and a digital twin of an application implemented by an application server;

[0042] Fig. lb shows a schematic diagram illustrating a sandbox environment implemented by an application server and including a digital twin of a mobile network and a digital twin of an application, wherein the sandbox environment is configured by a network entity according to an embodiment;

[0043] Fig. 2a shows a schematic diagram illustrating a configuration stage of the sandbox environment of figure la;

[0044] Fig. 2b shows a schematic diagram illustrating a configuration stage of the sandbox environment of figure lb;

[0045] Fig. 3a shows a schematic diagram illustrating an operation stage of the sandbox environment of figure la;

[0046] Fig. 3b shows a schematic diagram illustrating an operation stage of the sandbox environment of figure lb; Fig. 4 shows a schematic diagram illustrating a reporting stage of the sandbox environment of figures la and lb;

[0047] Fig. 5 shows a schematic diagram illustrating a cyber-physical system in the area of industrial network automation and cloud robotics as an application scenario for the sandbox environment according to an embodiment;

[0048] Figs. 6a-d show schematic diagrams illustrating exemplary user plane paths, the analytics which can be used to configure the sandbox environment to implement the digital twin of the mobile network, involving UEs, gNBs, UPFs and an application server;

[0049] Fig. 7 shows a schematic diagram illustrating an embodiment for implementing the sandbox environments of figures 6a-d;

[0050] Fig. 8a shows a signalling diagram illustrating in more detail the configuration stage of the sandbox environment of figure la;

[0051] Fig. 8b shows a signalling diagram illustrating in more detail the configuration stage of the sandbox environment of figure lb;

[0052] Fig. 9 shows a signalling diagram illustrating in more detail a sandbox environment according to a further embodiment;

[0053] Fig. 10 shows a schematic diagram illustrating in more detail a sandbox environment according to a further embodiment;

[0054] Fig. 11 shows a schematic diagram illustrating in more detail the architecture of a network entity according to an embodiment in the form of a Network Emulation Function for supporting a sandbox environment;

[0055] Figs. 12a-c show signalling diagrams illustrating in more detail the reporting stage of the sandbox environment according to different embodiments; and

[0056] Fig. 13 shows a flow diagram illustrating steps of a method according to an embodiment for operating a network entity for supporting a sandbox environment.

[0057] In the following, identical reference signs refer to identical or at least functionally equivalent features.

[0058] DETAILED DESCRIPTION OF THE EMBODIMENTS

[0059] In the following description, reference is made to the accompanying figures, which form part of the disclosure, which illustrates specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0060] For instance, it is to be understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and / or aspects described herein may be combined with each other, unless specifically noted otherwise.

[0061] Figure la shows a schematic diagram illustrating a sandbox environment 110 including a digital twin of a mobile network 130 implemented by a network entity according to an embodiment and a digital twin of an application 120 implemented by an application server. According to a variant illustrated in figure lb the sandbox environment 110 is implemented by an application server and includes the digital twin of a mobile network 130 and the digital twin of the application 120. As will be described in more detail in the following, the embodiments shown in figure la and lb provide a framework that allows the joint simulation of deployment scenarios by the network 130 and the (vertical) application 120. The simulation result is provided by the application to the network (i.e., 6G system) to be used for predicting the service experience for the QoS of interest proactively. Although the embodiments shown in figures la and lb (as well as some of the embodiments shown in the further figures) comprise a mobile network 100 in the form of a 6G system 100, it will be appreciated that in other embodiments the mobile network 100 may be a different mobile network 100, such as a 5g mobile network 100.

[0062] As illustrated in figures la and lb, the sandbox environment 110 consists of two logical sub-components, namely, firstly, the application DT 120 (that has the model of the physical application and, thus, can closely approximate its behavior) and, secondly, the network emulator 130, i.e. the DT of the network that receives data packets from the application DT 120 and forwards them back to the application DT 120 after certain operations, which may be implementation specific. As already described above, according to embodiments disclosed herein there are two deployment options for the network emulator 130, referred herein to as option A and option B. According to option A illustrated in figure la the network emulator 130 is deployed in the mobile network 100, while according to option B illustrated in figure lb the network emulator 130 is implemented outside of the network 100, e.g., in the application layer, together with the application DT 120.

[0063] Figures 2a, b, 3a, b and 4 illustrate more details about the sandbox environment options A and B. More specifically, figures 2a, b illustrate a configuration stage of the sandbox environment 110 prior to executing the sandbox environment 110, i.e. prior to running the simulation. The configuration of the sandbox environment 110 requires signaling between the application and the network 100 (e.g. 6G system) to configure the network emulator 130 correctly. This is represented by the first dashed arrow between the application 120 and the 6G system 100 in figures la and lb. Depending on the deployment option, the details of the configuration step (e.g., direction of messages, content of messages, and the like) may differ.

[0064] For option A illustrated in figures la and 2a, according to which the sandboxing (scenario simulation) is performed by the application and network jointly, the configuration stage is intended to setup a sandboxing session, during which the application 120 sends packets to the network 130 and receives them back after certain in-network processing. Therefore, according to an embodiment, the configuration stage comprises a message from the application 120 to a network entity, in particular a network function, to request the establishment of a new sandboxing session. This configuration message may contain one or more of the following information elements: a forwarding address, i.e.,fivdAddr, (e.g., an IP address and a destination port) to which the packets should be forwarded by the receiving network entity upon reception (during sandboxing session); a data path characterized by two endpoints (EPs), i.e., IDs of EPl, and EP2, (e.g., between two UEs, between a UE and an edge application server (EAS), between a UE and a remote application server (AS)) and direction (e.g., UL, DL, both); and / or a particular QoS (e.g., 5QI, packet error rate statistics, packet delay statistics, ... ) that is requested to emulate during the sandboxing session.

[0065] For option B illustrated in figures lb and 2b, the configuration stage characterizes the interaction between the application 120 and the network (e.g., a network function within the 6G core network), where the application 120 requests the network to expose analytics information about a particular data path. This data path may be defined by two endpoints (EPs) (e.g., between two UEs, between a UE and an edge application server (EAS), between a UE and a remote application server (AS)), and direction (e.g., EPl-to-EP2, EP2-to-EPl, both). If the request is accepted, the network (e.g., a network function such as the NWDAF) may send a message to the application 120 (e.g., via the application function) that contains the requested analytics information, as illustrated in figure 2b. If the request is accepted, the network sends a message to the application (e.g., via the application function) that may contain one or more of the following information elements: the result of the sandbox session configuration request ( e.g., accept); the address of the network function (e.g., the network emulator) that the application should send data packets during the sandboxing session, i.e., sbAddr (e.g., an IP address and a UDP port); and / or a session ID of the sandboxing session that will be used for the announcement of results in a later third stage.

[0066] Figures 3a, b illustrate in more detail an operation stage of the sandbox environment 110, i.e. actually running the simulation for option A and option B. For option A illustrated in figure 3a, i.e. when the network emulator 130 is located within the network 100, the application 120 and network 100 may exchange data packets in order to perform joint sandboxing together. According to an embodiment, this is handled by network entity that is able to receive data packets (e.g., in the form of IP packets, or Ethernet frames) from the application 120 and send them back (i.e., forward) to the application 120 after certain processing. This network entity is herein referred to as the network emulation function (NEmF) 130. The application 120 may use the sbAddr as destination for sending data packets to carry out the sandboxing. Upon the reception of a data packet during the sandboxing session, the NEmF 130 applies internal processing to the packets, which can be in the form of discarding, delaying, or duplicating it before sending it back to the application 120. An alternative option is that the NEmF 130 adds a metadata to the received packets before forwarding them to the application 120, that could indicate a particular network effect (discard, delay, duplicate, and the like).

[0067] Since the packets that are received by the NEmF 130 and sent by the application 120 may contain the address of the NEmF 130 as the destination address and the application’s address as the source address, before forwarding a packet back to the application 120, the NEmF 130 may modify the source and destination addresses accordingly. If the JwdAddr is provided in the first step, i.e. , SANDBOX SESSION CONFIG, (illustrated in figure 2a) then the NEmF 130 may overwrite the destination address and port of the data packet with the information provided in the JwdAddr. If this is not the case, the source address and port information of the received packet may be used as the default destination address. The NEmF 130 may change the source address by overwriting it with its own address.

[0068] Once the sandboxing session is completed, i.e. the simulation has been run, the application 120 provides the collected data and analytics about the service experience during the sandboxing session to the network 100. The procedure illustrated in more detail in figure 4 is common and applicable to both of the considered deployment options A and B. The results are sent by the application 120 to the mobile network 100, e.g., the 6G system 100, and may comprise one or more of the following elements: an application identifier, appID, which allows the network 100 to identify the particular application 120 or process that the results are valid for (this is important to allow the network 100 to relate multiple of such results provided for the same application 120, so that it can be stored and retrieved correctly); the service experience, svcExpr, which is the performance (e.g.,, in the form of a mean opinion score) measured during the sandboxing session (this is already supported by 5G Release 19 and allows the application 120 to provide the measured performance to the network 100 for a past time period); and / or the quality of service, QoS, under which the service experience was measured, which may be provided together with service experience. This is particularly essential for the deployment option B, since the results are generated external to the network 100.

[0069] Thus, embodiments disclosed herein enable the application 120 and the network 100 to collaboratively simulate a target scenario prior to deployment (e.g., service experience under target QoS). The simulation for a target QoS allows the application 120 to reduce the ‘search space’ (in QoS) that needs to be explored to generate a QoS-to-service experience map and also increase the accuracy by focusing on the exploration around the “operation point”.

[0070] Embodiments disclosed herein are particularly applicable to industrial network automation and cloud robotics, which can be classified as cyber-physical systems (CPSs). An example for such a CPS is illustrated in figure 5, where a service robot 510 might be controlled via the network 100 by a robot control application 520. As will be appreciated, one of the key features of a cyber-physical system is that the system comprises physical components that “live” in the real (i.e., physical) world, such as sensors, plant / process, actuators, and the like. Therefore, it is important to simulate potential scenarios in the digital (i.e., cyber) world before deploying them on the physical field devices. In a typical deployment scenario, the communication endpoints, e.g., the service robot 510 and a controller 520 exchange data packets through the communication network 100, which can be a 6G mobile network 100, to perform a control task. This can include the navigation of the robot from a point A to B or remote control of robot’s hardware components (e.g., robot arms).

[0071] There are various scenarios that define the topology of the user plane path, as illustrated in figures 6a-d. For instance, in the UE-to-remote application server communication illustrated in figure 6a, a UE device 620 (e.g. the service robot 510) sends and receives data packets to and from an application server 660 (via a gNB 630, a UPF 640 and a DN 650), where the controller process is running.

[0072] For the UE-to-edge application server communication illustrated in figure 6b, the controller may be deployed on an edge server 660. This is also a common deployment scenario especially for time-critical applications, where the end-to-end delays and packet losses are reduced compared to the “remote application server” embodiment illustrated in figure 6a.

[0073] For the UE-to-UE (same cell) communication scenario illustrated in figure 6c, both communication endpoints are located in the access network, e.g., an industrial application client running on a mobile terminal is communicating with another application that is also running on a mobile terminal. In contrast to the two embodiments illustrated in figures 6a and 6b, a data packet needs to traverse the air interface twice, during its transmission from the source to the destination. The topology illustrated in figure 6c foresees that both UEs 620 are located in the same cell. The UE-to-UE (different cell) communication scenario illustrated in figure 6d is similar to the scenario of figure 6c with the only difference that the communication endpoints are located in different cells.

[0074] As will be appreciated, more deployment options (e.g., sidelink, intermediate UPFs, roaming, and the like) may be defined in addition to the exemplary scenarios illustrated in figures 6a-d. One key consideration, however, is that in order to perform sandboxing, the network 100 should be configured to obtain the statistics of the entire end-to-end data path in order to configure the sandboxing tool with the accurate information, which in turn allows the simulation of the exact scenario of interest.

[0075] An overall deployment scenario according to an embodiment is illustrated in figure 7, where the service data flow is established between an application server 660 and the field device 620 within the RAN 100a. As described above, the network entity 130 in the form of the NEmF 130 for supporting the sandbox environment may be either implemented in the CN 100b of the mobile network 100 or on the applications server 660, which also implements the digital twin of the application.

[0076] Figure 8a shows a signalling diagram illustrating in more detail the configuration stage of the sandbox environment of figure la, i.e. for option A. In this embodiment, the application by means of the AF 810 initiates a sandboxing session by sending the Nnemf EmSession Create request to the network emulation function (NEmF) 830 either directly or via the network exposure function (NEF), as illustrated by steps 2a and 2b of figure 8a. The message contains JwdAddr as explained above as well as information about the two endpoints that characterize the actual data path. Each of the endpoint IDs, namely, ep-1, ep-2 as denoted in figure 8a, may be in the form of a UE ID, an IP address, a MAC address, AS ID, and the like. As will be appreciated, Nnemf EmSession Create request is the name of the message that the NEmF 830 receives. If the first message in step 2a of figure 8a goes via the NEF 820, then the name of this first message is Nnef EmSession Create request, while the name of the second message from the NEF 820 to the NEmF 830 is Nnemf EmSession Create request.

[0077] Upon the reception of a creation request, the NEmF 830 configures the network path between the AS and itself so that the sandboxing session data packets can be sent between the AS and the NEmF 830 (i.e., between fwdAddr and sbAddr). This requires the selection of the UPF and its configuration with the packet detection rules (PDRs) and data forwarding rules. The goal is to achieve that the UPF identifies the received PDUs that belong to the sandboxing session and forwards these to the NEmF 830 (for the AS-to-NemF direction), as illustrated in steps 3 and 4 of figure 8a.

[0078] Having received the endpoints of the actual data path (characterized by endpoint 1 and endpoint 2), the NEmF 830 collects relevant analytics to be able to emulate the particular path. For instance, this may include requesting Redundant Transmission Experience and / or DN Performance analytics from the NWDAF 850.

[0079] After the network internal procedures, e.g., collection of relevant analytics from the NWDAF 850, the NEmF 830 responds to the application 810 with the result of the configuration request. The response message also contains a sbAddr that the NEmF is listening for incoming packets from the AS. Also, it may contain a session ID that is assigned by the NEmF 830. Here, it is assumed that the AF may have discovered the NEmF 830 before the Nnemf EmSession Create request message. If the discovery procedure contains the exchange of sbAddr and / or fwdAddr, these fields may be removed from the relevant messages mentioned above.

[0080] As will be appreciated, the order of steps 3, 4 and 5 of figure 8a may be swapped. Moreover, steps la, lb, 5a and 5b may be performed more than once, e.g. once for endpoint 1 and once for endpoint 2. The frequency depends on the particular user plane topology explained in the context of figures 6a-d above.

[0081] Figure 8b shows a signalling diagram illustrating in more detail the configuration stage of the sandbox environment of figure lb, i.e. option B, further involving an OAM 860, a SME 870, and an AMF 880. In this embodiment, the application, i.e. the application function 810 may request a new type of analytics from the network 100, i.e., E2E Data Path analytics, i.e., the end- to-end (between two endpoints) network characteristics. This message is sent from the AF 110 (either via the NEF or directly) to the NWDAF 850. The request message may contain the corresponding analytics ID and the information about the two points. The request may indicate the direction of the requested path, EPl-to-EP2, EP2-to-EPl, or both. The endpoints may be defined by a UE ID, AS ID, or IP / MAC addresses.

[0082] After receiving the analytics information request (see step 4a of figure 8b), the NWDAF 850 collects the relevant information to generate / calculate the requested analytics. This may include redundant transmission experience related analytics collection (as defined in TS 23.288, cl 6.13) and / or the DN performance analytics collection as defined in (TS.288, cl. 6.14)). In an embodiment, the analytics information response may contain a combination of packet delay statistics (avg, min, max, variance), packet loss rate (avg, max, variance), data rate (avg, max, variance), packet duplication rate and out-order-statistics (whether packets can arrive not in the order they were sent, and how often this occurs, and the like). Here it is assumed that the AF 810 is authorized to request the E2E Data Path Analytics.

[0083] Figure 9 shows a variant of the embodiment shown in figure 8b. The main difference of the variant shown in figure 9 is that instead of requesting the E2E Data Path Analytics ID, which includes statistics between two endpoints (source and destination) in the network 100, the AF 810 reuses the existing analytics and mechanisms defined by the current 3GPP framework of standards. Particularly, the Redundant Transmission Experience and DN Performance analytics that are available at the NWDAF 850 may be requested and the E2E analytics may be calculated by the application 810 itself. This requires however the application to know the topology of the data path so that it may request the right analytics for each components of the data path separately. This information may not be exposed to the application. Nevertheless, the corresponding analytics (red. trans, exp. and dn perf.) may be extended to contain the pkt duplication and out-of-order statistics as well for more accurate information about the path.

[0084] Figure 10 shows a schematic diagram illustrating a more detailed embodiment of the sandbox environment illustrated in figure la, i.e. option A. According to the embodiment illustrated in figure 10, once the NEmF 830 has been configured correctly in the way described above, the actual execution of the sandboxing starts. This means, the application server 660 (remote or edge) starts sending data packets to the NEmF 830 (IP or Ethernet). The data packets are passing through a data network (in case of a remote app. server) and subsequently through a user plane function, UPF, 640 in the core network 110b. Upon the reception of the data packets, the NEmF 830 processes these before forwarding them back to the application server 660 (via the UPF 640, DN, . . . ). This processing may involve one or more of the following operations on the data packets: storing the data packets temporarily; discarding one or more of the data packets; duplicating one or more of the data packets; reordering the data packets; modifying the header (e.g., IP, Ethernet) of one or more of the data packets; and / or modifying the payload (if content is readable) of one or more of the data packets. The payload modification operation may, for instance, comprise emulating bit errors or it may also be due to an agreed protocol within the sandbox environment stretching between the network and the application. For instance, a particular field may mark the packet with certain information that is to be interpreted by the application DT. For instance, in order to tell the application that the data packet is supposed to be delayed or duplicated by a certain amount of time, without actually delaying or duplicating it in real-time.

[0085] As will be appreciated, in the embodiment illustrated in figure 10, the NEmF 830 is a user plane core network function in addition to the UPF 640, which does not exist in the 5G architecture. In other words, when the UPF 640 receives a DL PDU, e.g., via the N6 interface, it does not forward it via the N3 (to a gNB) or via the N9 (to an I-UPF) interfaces. On the contrary, the PDU is sent via the interface between the UPF 640 and the NEmF 830. This introduces a new reference point (interface) into the UPF 640, towards a network function that is part of the user plane but is not a (I-)UPF, in addition to N3 and N9.

[0086] Figure 11 shows a schematic diagram illustrating in more detail the architecture of the NEmF 830 according to an embodiment. As illustrated in figure 11, the NEmF 830 may comprise or implement multiple processing blocks enforcing a particular networking effect, such as discarding, delaying and the like. This relates to the previous embodiment of figure 10, where the NEmF 830 receives packets via the UPF 640. As further illustrated in figure 11, the NEmF 830 may operate multiple parallel active sandboxing sessions (i.e., emulation sessions) 11 lOa-c addressed to by a filter 1120. In this case, the packets may be treated in an isolated manner.

[0087] Figures 12a-c show signalling diagrams illustrating in more detail the reporting stage of the sandbox environment of figures la and lb according to different embodiments. In the embodiment shown in figure 12a the communication of the sandboxing results is implemented via the AF 810 to the NWDAF 850. According to an embodiment this may be implemented by extending the ‘service experience’ (QoE) framework of the current 5G framework of standards to accommodate a new field. According to this new message, the application provides a (predicted) service experience for a given QoS (as a tuple). To realize this, as an example, ServiceExperiencelnfoPerApp message as specified in 3GPP TS 29.517, § 5.6.2.7 may be extended to carry an additional field with the QoS information.

[0088] In the embodiments shown in figures 12b and 12c the communication of the sandboxing results between the AF 810 and the NWDAF 850 traverses an intermediate function, e.g., NEF, 820 or the NEmF 830. According to an embodiment, the service experience may be provided together with the session ID that was agreed in the session configuration step between the NEmF 830 and the application server. In the embodiment illustrated in figure 12c, the NEmF 830 may be configured to extract the session QoS based on the collected data throughout the session and inform the NWDAF 850 through an interface between the NEmF 830 and the NWDAF 850 (as illustrated in figure 12c). As will be appreciated, the embodiment of figure 12c relates to option A.

[0089] Figure 13 shows a flow diagram illustrating a method 1300 according to an embodiment for operating a network entity of the mobile network 100 for supporting the sandbox environment 110. As already described above, the sandbox environment 110 comprises the digital twin 120 of an application and the digital twin 130 of the mobile network 100, wherein the digital twin 130 of the mobile network 100 is configured to exchange data packets with the digital twin 120 of the application. The method 1300 comprises a step 1301 of providing configuration data to an application server for configuring the application server to implement at least the digital twin 120 of the application of the sandbox environment 110. Moreover, the method 1300 comprises a step 1303 of receiving one or more results from the application server, wherein the one or more results are based on the sandbox environment 110.

[0090] The person skilled in the art will understand that the "blocks" ("units") of the various figures (method and apparatus) represent or describe functionalities of embodiments of the present disclosure (rather than necessarily individual "units" in hardware or software) and thus describe equally functions or features of apparatus embodiments as well as method embodiments (unit = step).

[0091] In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described embodiment of an apparatus is merely exemplary. For example, the unit division is merely logical function division and may be another division in an actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

[0092] The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

[0093] In addition, functional units in the embodiments of the invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.

Claims

CLAIMS1. A network entity of a mobile network (100) for supporting a sandbox environment (110), wherein the sandbox environment (110) comprises a digital twin (120) of an application and a digital twin (130) of the mobile network (100) and wherein the digital twin (130) of the mobile network (100) is configured to exchange data packets with the digital twin (120) of the application, wherein the network entity is configured to: provide configuration data to an application server for configuring the application server to implement at least the digital twin (120) of the application of the sandbox environment (110); and receive one or more results from the application server, wherein the one or more results are based on the sandbox environment (110).

2. The network entity of claim 1, wherein the network entity is configured to provide the configuration data to the application server for configuring the application server to implement the digital twin (120) of the application and the digital twin (130) of the mobile network (100).

3. The network entity of claim 1 or 2, wherein the configuration data comprises analytics information about one or more data paths between two endpoints of the mobile network (100).

4. The network entity of any one of the preceding claims, wherein the network entity is configured to provide the analytics information about the one or more data paths between two endpoints of the mobile network (100), in response to a request from the application server.

5. The network entity of claim 1, wherein the network entity is configured to implement the digital twin (130) of the mobile network (100) of the sandbox environment (110), wherein the digital twin (130) of the mobile network (100) of the sandbox environment (110) is configured to exchange data packets with the digital twin (120) of the application.

6. The network entity of claim 5, wherein the network entity is configured to provide the configuration data to the application server for configuring the application server to implement the digital twin (120) of the application of the sandbox environment (110), in response to a request from the application server.

7. The network entity of claim 6, wherein the network entity is configured to provide the configuration data to the application server directly and / or via a network function.

8. The network entity of claim 6 or 7, wherein the request from the application server comprises: a forwarding address to which the data packets provided by the digital twin (130) of the mobile network (100) are to be forwarded; a data path defined by one or more data path endpoints and / or a data path direction; and / or a QoS indication indicative of a desired QoS provided by the digital twin (130) of the mobile network (100).

9. The network entity of any one of claims 6 to 8, wherein the configuration data comprises: a network entity address to which the data packets provided by the digital twin (120) of the application are to be transmitted; and / or a sandboxing session identifier.

10. The network entity of claim 9, wherein the network entity is configured to allocate the sandboxing session identifier to the sandbox environment (110).

11. The network entity of any one of claims 6 to 10, wherein the network entity is implemented as a network function of the mobile network (100).

12. The network entity of any one of the preceding claims, wherein the one or more results based on the sandbox environment (110) comprise a service experience indication indicative of the performance of the digital twin (120) of the application and / or a QoS indication indicative of a predicted QoS provided by the digital twin (130) of the mobile network (100).

13. The network entity of claim 12, wherein the network entity is configured to receive a ServiceExperiencelnfoPerApp message from the application server, wherein the ServiceExperiencelnfoPerApp message comprises the one or more results.

14. The network entity of claim 12 or 13, wherein together with the one or more results the network entity is configured to receive an application identifier indicative of the digital twin (120) of the application from the application server.

15. A method (1300) for operating a network entity of a mobile network (100) for supporting a sandbox environment (110), wherein the sandbox environment (110) comprises a digital twin (120) of an application and a digital twin (130) of the mobile network (100) and wherein the digital twin (130) of the mobile network (100) is configured to exchange data packets with the digital twin (120) of the application, wherein the method (1300) comprises: providing (1301) configuration data to an application server for configuring the application server to implement at least the digital twin (120) of the application of the sandbox environment (110); and receiving (1303) one or more results from the application server, wherein the one or more results are based on the sandbox environment (110).

Images