Data communication method for maintaining connection to virtual endpoint mesh network during switching between multiple subscriber identity modules and apparatus therefor

Abstract

A data communication method performed by an end client device supporting multiple subscriber identification modules may include: an operation of connecting to a mesh-type end virtual network based on configuration information through a first network associated with a first subscriber identification module; an operation of activating a second subscriber identification module while connected to the mesh-type end virtual network to connect to a second network associated with the second subscriber identification module; and an operation of transmitting and receiving data packets through the mesh-type end virtual network with another end client device connected to the mesh-type end virtual network while connected to the second network.

Description

Technology Field

[0001] The present invention relates to polymorphic plane-based end-to-end (also expressed as "") computer networking. Specifically, the invention relates to a method and apparatus for continuing data communication through a mesh-type end-to-end virtual network even when an end-to-end client device supporting a plurality of subscriber identification modules (SIMs) is connected to a mesh-type end-to-end virtual network through a first network associated with a first subscriber identification module, and then activates a second subscriber identification module to connect to a second network. Background Technology

[0002] Future networks can be layered into virtual-physical or physical-virtual planes that combine physical and virtual environments, and endpoints (also referred to as "endpoints") connected to these planes. Furthermore, a mesh-type endpoint virtual network space can be formed to transmit data and user experiences by writing and configuring polymorphic planes—the networking forms desired by the user—in real time.

[0003] In a polymorphic end-to-end computer networking environment, edge computing can support data flow acceleration and enhanced seamless reliability by processing data near the end or on the end terminals themselves, rather than on a central cloud server. Edge computing, MEC, and related technologies can provide reduced latency, increased responsiveness, enhanced reliability, and improved computing capabilities compared to traditional cloud network services or wide area network connections.

[0004] Recently, devices supporting dual SIMs or multiple SIMs are being utilized. In end-client devices that support multiple SIMs, the connected communication service or network may change depending on the active SIM.

[0005] Therefore, a technology is required that enables data communication through a mesh-type end-virtual network to continue even when a different SIM among multiple SIMs is activated and the connection network of the end client device changes. The problem to be solved

[0006] The present invention aims to provide a method and apparatus for continuing data communication through a mesh-type end-type virtual network even when the connected network changes, by activating another subscriber identification module while connected to a mesh-type end-type virtual network in an end-type client device that supports a plurality of subscriber identification modules.

[0007] The present invention aims to provide a method and apparatus applicable to the transition from a physical SIM to an eSIM as well as the transition from an eSIM to a physical SIM, the release or maintenance of a first network connection, and cases where the service providers or communication protocols of the first network and the second network are the same or different. means of solving the problem

[0008] A data communication method performed by an end client device supporting a plurality of subscriber identification modules according to an embodiment of the present invention may include: an operation of connecting to a mesh-type end virtual network based on configuration information of the end client device through a first network associated with a first subscriber identification module among the plurality of subscriber identification modules; an operation of activating a second subscriber identification module among the plurality of subscriber identification modules to connect to a second network associated with the second subscriber identification module while connected to the mesh-type end virtual network; and an operation of transmitting and receiving data packets through the mesh-type end virtual network with another end client device connected to the mesh-type end virtual network while connected to the second network.

[0009] In one embodiment, the end client device may disconnect from the first network while connected to the second network. In another embodiment, the end client device may maintain a connection to the first network even while connected to the second network.

[0010] In one embodiment, the first subscriber identification module may be a removable physical SIM and the second subscriber identification module may be an eSIM. In another embodiment, the first subscriber identification module may be an eSIM and the second subscriber identification module may be a removable physical SIM.

[0011] In one embodiment, the first network and the second network may be provided by the same communication service provider or by different communication service providers. Additionally, the first network and the second network may support the same communication protocol or different communication protocols.

[0012] In one embodiment, the configuration information may be obtained from an orchestrator and may include at least one of a mesh-type end virtual network identifier, a virtual IP address of the end client device, a cryptographic key, or an IV (initialization vector) value.

[0013] In one embodiment, the data packet may be encrypted or decrypted based on a symmetric key or a session key. The data packet may be transmitted and received through a direct security tunnel between the end client device and the other end client device, or through a bypass security tunnel passing through a DTR-type end client device.

[0014] An end client device according to one embodiment of the present invention may include a communication circuit for transmitting and receiving signals with an external device, a memory, a first subscriber identification module and a second subscriber identification module, and at least one processor connected to at least one of the communication circuit, the memory, the first subscriber identification module or the second subscriber identification module.

[0015] In one embodiment, the at least one processor may be configured to connect to a mesh-type end-virtual network based on configuration information through a first network associated with the first subscriber identification module, and while connected to the mesh-type end-virtual network, activate the second subscriber identification module to connect to a second network associated with the second subscriber identification module, and while connected to the second network, transmit and receive data packets with another end-client device connected to the mesh-type end-virtual network. Effects of the invention

[0016] According to the system, device, and method of the present invention, data communication through a mesh-type end-to-end virtual network can be continued even if the connection network changes because another subscriber identification module among a plurality of subscriber identification modules is activated.

[0017] According to the system, device, and method of the present invention, bidirectional switching between a physical SIM and an eSIM, maintenance or release of a first network connection, and switching between networks where the service provider or communication protocol is the same or different can be included.

[0018] According to the system, device, and method of the present invention, data can be effectively and securely shared even after the communication environment has changed by using encryption and a secure tunnel of a mesh-type end-to-end virtual network. Brief explanation of the drawing

[0019] FIG. 1 is a diagram illustrating a mesh-type end-to-end virtual network operation environment according to an embodiment of the present invention. FIG. 2 is a block diagram showing an apparatus according to one embodiment of the present invention. FIG. 3 is a simplified block diagram of an apparatus according to one embodiment of the present invention. Figure 4 shows the control structure of a mesh-type end-virtual network in a polymorphic end-network environment according to one embodiment of the present invention. FIG. 5 shows the control structure of a mesh-type end-virtual network in a polymorphic end-network environment according to one embodiment of the present invention. FIG. 6 is a diagram illustrating zero-trust access control according to one embodiment. FIG. 7 is a flowchart of a mesh-type end-virtual net generation procedure according to one embodiment. FIG. 8 is a flowchart of the authentication and mesh-type end-virtual network connection procedure according to one embodiment. FIG. 9 is a flowchart of an end-client connection procedure according to one embodiment. FIG. 10 is a flowchart of a signal transmission and reception procedure on a mesh-type end-to-end virtual network according to one embodiment. FIG. 11 is a diagram illustrating a mesh-type end-to-end virtual network operation environment according to an embodiment of the present invention. FIG. 12 illustrates the data transmission and reception flow of a device including a plurality of shims in a mesh-type end-virtual network according to one embodiment. Specific details for implementing the invention

[0020] Hereinafter, various embodiments of the present invention are described with reference to the accompanying drawings. The present invention is not limited to specific embodiments and should be understood to include various modifications, equivalents, and / or alternatives of the embodiments of the present invention. In connection with the description of the drawings, similar reference numerals may be used for similar components.

[0021] In this document, expressions such as "have," "can have," "include," or "can include" refer to the existence of the relevant feature (e.g., numerical values, functions, actions, or components, etc.) and do not exclude the existence of additional features.

[0022] In this document, expressions such as “A or B,” “at least one of A or / and B,” or “one or more of A or / and B” may include all possible combinations of items listed together. For example, “A or B,” “at least one of A and B,” or “at least one of A or B” may refer to cases including (1) at least one A, (2) at least one B, or (3) both at least one A and at least one B.

[0023] Expressions such as "first," "second," "first," or "second" used in this document may modify various components regardless of order and / or importance, and are used merely to distinguish one component from another without limiting such components. For example, without departing from the scope of rights set forth in this document, the first component may be named the second component, and similarly, the second component may be renamed the first component.

[0024] As used in this document, the expression "configured to" may be replaced, depending on the context, with, for example, "suitable for," "having the capacity to," "designed to," "adapted to," "made to," or "capable of." The term "configured to" does not necessarily mean "specifically designed to."

[0025] In this document, terms transmitted or received between the first electronic device(s) and the second electronic device(s), such as “command,” “instruction,” “control information,” “message,” “information,” “data,” “packet,” “data packet,” “intent,” and / or “signal,” may include or refer to humanly perceptible ideas or specific electrical representations (e.g., digital codes / analog physical quantities) without being limited by their expression. It will be obvious to a person skilled in the art to which the invention disclosed in this document pertains that the exemplary expressions listed above may be interpreted in various ways depending on the context in which they are used. In this document, “a is greater than B” means not only that “a is greater than B” but also includes the meaning that “a is equal to or greater than B”.

[0026] The terms used in this document are used merely to describe specific embodiments and are not intended to limit the scope of other embodiments. Singular expressions may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art described in this document. Terms used in this document that are defined in general dictionaries may be interpreted as having the same or similar meaning as they have in the context of the relevant technology, and are not to be interpreted in an ideal or overly formal sense unless explicitly defined in this document. In some cases, even terms defined in this document may not be interpreted to exclude the embodiments of this document.

[0027] FIG. 1 is a diagram illustrating a mesh-type end-to-end virtual network operation environment according to an embodiment of the present invention.

[0028] Referring to FIG. 1, the mesh-type end-to-end virtual network operation environment of the present invention includes end-to-end client devices (110A, 110B, 120A, 120B, 120C, 120D, 120E) that directly exchange data with each other, at least one controller (131) and at least one orchestrator (132) that centrally manage these devices so that they can access security target data or resources stored in an enterprise device (140).

[0029] At least one controller (131) may represent a functional entity that controls related components (e.g., end client devices, orchestrators, etc.) to control end client devices in a mesh-type end virtual network unit. The controller (131) may be implemented in a polymorphic form as a logical entity or a physical entity. Additionally, at least one controller (131) may make a decision to permit or deny access to security target data, etc., stored in an enterprise device (140) by an end client device (e.g., 110A). At least one controller (131) may include an Intuitive Defined Network (IDN) controller operating according to various embodiments of the present invention, or a Software Defined Perimeter (SDP) controller as a component implementing a zero-trust architecture.

[0030] At least one controller (131) is not limited to a physical form of implementation or a location of implementation. The controller may refer to a controller functional element (entity) defined by the National Institute of Standards and Technology (NIST), Telecommunications Technology Association (TTA), European Telecommunication Standards Institute (ETSI), etc.

[0031] At least one orchestrator (132) may refer to a functional entity that configures related components (e.g., end client devices, orchestrators, etc.) to create a mesh-type end virtual network between end client devices. The orchestrator (132) may perform overall coordination and collaboration functions of the end network environment, such as user authentication and defining the mesh-type end virtual network, as well as requirements and resource allocation between components.

[0032] Each component can exchange signals with one another through a mesh-type end-to-end virtual network. End clients forming the mesh-type end-to-end virtual network may include functional elements that effectively forward, switch, or route traffic, such as switches, routers, and gateways.

[0033] Through a mesh end-to-end virtual network, end clients (110A to 120E), a controller (131), a controller (132), an orchestrator (133), and an enterprise device (140) can be combined to communicate directly or indirectly with end devices that have been authenticated through their own authentication procedures and trust of identity. The mesh end-to-end virtual network can create independent mesh end-to-end virtual networks using wired or wireless communication networks. Additionally, the mesh end-to-end virtual network can be created as a local area or far area communication network and as a polymorphic network of the form desired by the user. For example, the mesh end-to-end virtual network may include cellular networks such as LTE, LTE-A, 5G, and 6G.

[0034] In various embodiments of the present invention, the end client device (110A to 120E) may be a concept corresponding to a user device. The user device may be, for example, a smartphone, tablet PC, laptop, computer, cloud virtualization device, etc. The user may enter an ID and password into the user device through an identity authentication program, and from the perspective of an edge computing environment, the user device may be referred to as an end client device. In various embodiments of the present invention, the end client device may be referred to as a user device located at the end of a network connection, an end client, an end client node, a client, a client device, a node, an edge, or an electronic device.

[0035] Additionally, in various embodiments of the present invention, a device storing data requiring access permission from an end client device is referred to as an enterprise device (140), but such a device may be referred to as a security device, a resource device, or a server. The entities requiring security may include various entities other than enterprises, such as schools and public institutions.

[0036] According to various embodiments of the present invention, an orchestrator (131), a controller (132), and end client devices (110A to 120E) may form a mesh-type end virtual network (110, 120). In the edge computing environment of the present invention, a plurality of mesh-type end virtual networks (110, 120) may be configured. Different virtual security addresses, encryption keys, and / or IV values ​​may be configured for each mesh-type end virtual network. Additionally, different encryption algorithms and / or modes may be applied to each mesh-type end virtual network.

[0037] Independent communication channels may be formed between end client devices connected to the same mesh-type end virtual network. End client devices on the mesh-type end virtual network may perform direct communication between devices. In this case, signals or data exchanged between end client devices may be encrypted according to various embodiments of the present invention. Depending on a specific encryption method and / or encryption key, specific data may be accessible only to devices connected to the same mesh-type end virtual network.

[0038] For example, a first end-to-end virtual network (110) may be connected to a first end-to-end client device (110A) and a second end-to-end client device (120B). The first end-to-end client device (110A) may transmit data to the second end-to-end client device (120B) according to the encryption method assigned to the first mesh-to-end virtual network (110). The second end-to-end client device (120B) may decrypt the acquired data according to the encryption method assigned to the first mesh-to-end virtual network (110) and verify or access the data.

[0039] For example, a first end client device (120A) through a fifth end client device (120E) may be connected to a second mesh-type end virtual network (120). A first end client device (120A) connected to the second mesh-type end virtual network (120) may transmit data encrypted based on a first encryption key and / or IV value assigned to the second mesh-type end virtual network (120) to a third end client device (120C). A third end client device (120C) may decrypt the acquired data based on a second encryption key and / or IV value assigned to the second mesh-type end virtual network (120) and verify or access the data.

[0040] According to one embodiment, access rights to specific corporate data may be set at the mesh-type end-virtual network level. A first end-client device (110A) connected to a first mesh-type end-virtual network (110) can access a first resource among corporate resources allocated to the first mesh-type end-virtual network (110). When a first end-client device (120A) connected to a second mesh-type end-virtual network (110) attempts to access the first resource, the controller (132) can block the resource access of the first end-client device (120A).

[0041] According to one embodiment, devices connected to the first mesh-type end-to-end virtual network (110) can exchange encrypted data with each other. For example, when a first end-to-end client device (110A) obtains data from an enterprise device (140) with restricted access, it can encrypt the data based on the encryption key and IP value of the first mesh-type end-to-end virtual network (110) and share it with a second end-to-end client device (110B).

[0042] The configurations included in the environment illustrated in FIG. 1 are exemplary and may include additional configurations or omit some configurations, and the arrangement between each configuration may also be changed. For example, although the controller (131) and the orchestrator (132) are shown as separate configurations, the controller (131) and the orchestrator (132) may be included in the same configuration and implemented as logically distinct entities.

[0044] FIG. 2 is a block diagram showing the configuration of a device according to one embodiment.

[0045] As illustrated in FIG. 2, a device (200) according to one embodiment of the present invention (e.g., end client device (110A, 110B, 120A, 120B, 120C, 120D, 120E) of FIG. 1, orchestrator (131), controller (132), or server (or enterprise device) (140)) may include a bus (210), a display (220), a communication circuit (230), a database (240), a memory (250), an input / output (I / O) interface (260), and a processor (270). In other embodiments, the device (150) may omit at least one of the above components or additionally include other components.

[0046] For reference, the components (210, 220, 230, 240, 250, 260, 270) of the device (150) illustrated in FIG. 2 are merely exemplary components for explaining a document creation support method according to one embodiment of the present invention. That is, it is evident that the device (150) according to one embodiment of the present invention may additionally include other components other than those illustrated.

[0047] The bus (210) can electrically connect the components (220 to 270) to each other. The bus (210) may include circuits for communication (e.g., control messages and / or data) between the components (220 to 270).

[0048] The display (220) can display text, images, videos, icons, or symbols that constitute various content. The display (220) may include a touchscreen and can receive touch, gesture, proximity, or hovering input using an electronic pen or a part of the user's body.

[0049] For example, the display (220) may include a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic light-emitting diode (organic LED) display, a microelectromechanical systems (MEMS) display, or an electronic paper display. The display (220) may be implemented by being included in the device (150), or implemented separately from the device (150) but operatively connected to the device (150).

[0050] The communication circuit (230) can establish a communication channel between the device (150) and external devices. The communication circuit (230) can communicate with external devices by accessing the network (280) via wireless communication or wired communication. In one embodiment, the communication circuit (230) may include a circuit for forming a wide-area network connection or a peer-to-peer connection, such as Wi-Fi, Bluetooth, and / or a cellular communication circuit.

[0051] The database (240) may be implemented in memory (250) or on a separate storage medium. The database (240) may store all contents, history, etc. of data transmitted and received with an external device. Data stored in the database (240) may be updated regularly according to a predetermined period.

[0052] According to an embodiment of the present invention, various information received from an external device may be stored in the database (240). For example, various end-client configuration information may be stored in the database (240). Additionally, a learning model according to various embodiments of the present invention may be stored in the database (240).

[0053] According to various embodiments, data stored in the database (240) is sensitive information of the user, and may be distributed and stored in a blockchain network to enhance security regarding the use of said information. When the database (240) is distributed and stored in a blockchain network, the history of transmission, modification, deletion, addition, etc. of the information included in the database (240) can be managed more securely in said blockchain network.

[0054] The memory (250) may include volatile and / or non-volatile memory. The memory (250) may store instructions or data related to at least one other component of the device (150). For example, the memory (250) may store instructions that cause the processor (270) to perform various operations described herein at runtime. For example, the instructions may be included in a package file of an application program.

[0055] The I / O interface (260) can perform the role of transmitting commands or data input from a user or other external device to other components of the device (150). The I / O interface (260) can be implemented in hardware or software and can be used as a concept encompassing a user interface (UI) and a terminal for communication with other external devices.

[0056] The processor (270) may include at least one of a central processing unit (CPU), an application processor (AP), or a communication processor (CP). The processor (270) is electrically connected to a memory (250), a display (220), and a communication circuit (230) via a bus (210), and during operation, it may execute operations or data processing regarding the control and / or communication of other components according to instructions, programs, or software stored in the memory (250). Accordingly, the execution of the instructions, application programs, or software can be understood as the operation of the processor (270).

[0057] The network (280) may include at least one of a telecommunications network, a computer network, the Internet, or a telephone network. A wireless communication protocol to access the network (280) may use, for example, at least one of LTE (Long-Term Evolution), LTE-A (LTE Advanced), CDMA (Code Division Multiple Access), WCDMA (Wideband CDMA), UMTS (Universal Mobile Telecommunications System), WiBro (Wireless Broadband), GSM (Global System for Mobile communications), or 5G standard communication protocols. However, this is exemplary, and various wired and wireless communication technologies applicable in the relevant technical field may be used according to embodiments to which the present invention is applied.

[0059] FIG. 3 is a block diagram briefly showing the configuration of devices according to one embodiment of the present invention.

[0060] Referring to FIG. 3, the first device (300) may include at least one of a processor (302), a memory (304), or a communication circuit (306). The processor (302) may control the communication circuit (306) to communicate with the second device (310). The communication circuit (306) may support wired or wireless communication. Additionally, the communication circuit (306) may support bidirectional or unidirectional communication.

[0061] According to one embodiment, the second device (310) may include at least one of a processor (312), a memory (314), or a communication circuit (316). The processor (312) may control the communication circuit (316) to communicate with the electronic device (310). The communication circuit (316) may support wired or wireless communication. Additionally, the communication circuit (316) may support bidirectional or unidirectional communication.

[0062] For example, the first device (300) may be an end client node. The end client node may be a first end client device (e.g., the first end client device (110A) of FIG. 1) having an end client program installed. The first device (300) may transmit and receive signals with a counterpart device through an end client identity verification and trust authentication program. The end client node may perform operations included in various embodiments described in the present invention. In this case, the second device (310), which is the counterpart terminal of the first device (300), may be a controller (e.g., controller (131) of FIG. 1), an orchestrator (e.g., orchestrator (132) of FIG. 1), or an enterprise device where enterprise resources (or data) are stored (e.g., enterprise device (140) of FIG. 1), or another end client node (or second end client device (e.g., second end client device (110B) of FIG. 1)) of the same mesh-type end virtual network as the first device (300).

[0063] Alternatively, the first device (300) may be a controller (e.g., the controller (131) of FIG. 1). In this case, the second device (132) may be an orchestrator (e.g., the orchestrator (132) of FIG. 1), an enterprise device (e.g., the enterprise device (140) of FIG. 1), or an end client node.

[0064] Alternatively, the first device (300) may be an orchestrator (e.g., the orchestrator (132) of FIG. 1). In this case, the second device (132) may be a controller (e.g., the orchestrator (131) of FIG. 1), an enterprise device (e.g., the enterprise device (140) of FIG. 1), or an end client node.

[0065] According to one embodiment, at least one of the first device (300) and the second device (310) may support a plurality of SIMs (Subscriber Identification Modules). The plurality of SIMs may be referred to as a first SIM, a second SIM, and so on. The first SIM may include information associated with a first network provided by a first communication service provider. The second SIM may include information associated with a second network provided by a second communication service provider.

[0066] The first SIM may include, for example, a removable physical SIM. The first device (300) may include a slot that makes the physical SIM removable. The second SIM may include an eSIM (embedded SIM). An eSIM may be installed in the first device (300) at the user's request or at the time of initial purchase.

[0068] FIG. 4 shows a control structure of a mesh-type end-virtual network in an edge computing environment according to an embodiment of the present invention.

[0069] A mesh-type end-to-end virtual network solution may include at least one of end-to-end client devices, a controller (420), and an orchestrator (430). The controller (420) and the orchestrator (430) can easily automatically generate a mesh-type end-to-end virtual network into an intuitive orchestrator authoring model through interaction with the end-to-end client devices.

[0070] The controller (420) can control and manage connected end clients in units of mesh-type end virtual networks. Through this, logically separated mesh-type end virtual networks can be created. When each end client connects to a mesh-type end virtual network, end clients connected to the same mesh-type end virtual network can perform direct communication based on virtual addresses.

[0071] The controller (420) can perform functions such as managing a mesh-type end virtual network, controlling and / or managing end clients, distributing a list of end client nodes, controlling end client external traffic, controlling end client connections, UDP Hole Punching, NAT Traversal, encryption of control messages, and generating and / or registering audit data.

[0072] The orchestrator (430) manages users, such as performing user authentication, or defines mesh-type end-virtual networks. The orchestrator can perform functions such as, for example, registering and managing users (or administrators), changing user (or administrator) passwords, identifying and authenticating users (or administrators), connecting and managing virtual security networks per user, responding to authentication failures, creating and searching audit logs, and securely storing critical data. Additionally, the orchestrator can perform functions such as registering and managing controllers, registering mesh-type end-virtual networks, creating and managing topologies for mesh-type end-virtual networks, registering end clients, controlling and / or managing end client virtual IP blocks, creating and / or providing end client configuration information, collecting and / or monitoring audit data, setting external traffic control for end clients, and managing cryptographic keys and / or IVs for end client access.

[0073] End client devices can connect to, join, or disconnect from a meshed end virtual network. End client devices can form IP-UDP-IP tunneling or perform functions such as NAT traversal, UDP hole punching, control message encryption, data packet encryption, or external traffic control.

[0074] Among the end client devices, specific end client redirection functions can be performed. This means performing the function of connecting the mesh-type end virtual network with existing network services. Each end client connected to the mesh-type end virtual network can perform direct secure communication based on virtual addresses. The end client performing the redirection function can internally perform SNAT functions with the external network. In order for other end clients to connect data from the corresponding external network to the mesh-type end virtual network, the controller can perform the role of distributing redirection information to other end clients.

[0075] The orchestrator (430) can create a mesh-type end virtual network (410, 411, 412) and can create configuration information for end clients (end client 1 to end client 9). The controller (420) can connect the end clients to the mesh-type end virtual network in response to a request from an end client (or end client device). For example, the orchestrator (430) can create a first mesh-type end virtual network (410) and share the mesh-type end virtual network information with the controller (420). When there is a request for a connection to the first mesh-type end virtual network (410) from the first end client device (end client 1), the controller (420) checks whether to approve it, and if there is access authority to the first end client device, it can send a connection response approving the connection to the first end client device.

[0076] Multiple end client devices connected to the first mesh-type end virtual network (410) can directly transmit and receive data to and from each other. Accordingly, all end client devices connected to the first mesh-type end virtual network (410) can share specific data without accessing the enterprise device (e.g., the enterprise device (140) of FIG. 1).

[0078] FIG. 5 shows a control structure of a mesh-type end-virtual network in an edge computing environment according to an embodiment of the present invention.

[0079] Referring to FIG. 5, the orchestrator (430) can perform the functions of creating and / or deleting user information for user management. The orchestrator (430) can perform authentication based on a user ID and password with an end client device. The orchestrator (430) can provide a connection based on HTTP (Hypertext Transfer Protocol) and perform authentication based on TLS (Transport Layer Security) with an end client device. For the management of a mesh-type end virtual network, the orchestrator (430) can create a mesh-type end virtual network and register end client devices that can connect to the mesh-type end virtual network. The orchestrator (430) can generate cryptographic keys and / or IV values ​​required by the end clients. The cryptographic keys may be based on a symmetric key method. The orchestrator (430) can provide information on the created mesh-type end virtual network and end clients to the controller (420). The orchestrator (430) can receive topology information of the end client device and system resource information of the end client from the controller (430) and perform monitoring functions.

[0080] The controller (420) can store mesh-type end virtual network information and end client information received from the orchestrator (430) in an internal data structure. The controller (420) can provide information (NAT Traversal / UDP Hole Punching information) required by end clients connecting to the mesh-type end virtual network through authentication. The controller (420) can encrypt control messages transmitted and received with end clients based on a symmetric key. Additionally, the controller (420) can perform management such as the creation or deletion of encryption keys and / or IV values.

[0081] A database management system (DBMS, Data Base Management System) (450) can be connected to an orchestrator (430). The DBMS (450) may include a database used by the orchestrator (430).

[0082] The end client device can perform an authentication procedure with the orchestrator (440) based on TLS. If the authentication procedure is successful, the end client device can perform an operation to connect to the mesh-type end virtual network. If the connection procedure to the mesh-type end virtual network is successful, the end client device can perform secure communication based on virtual addresses with other end client devices connected to the same mesh-type end virtual network.

[0083] End client devices can be classified into a first type and a second type. The first type is an end client installed on a user terminal or a server providing a service, while the second type can operate at a location where all end clients can communicate. If communication between end clients of the first type is impossible, each end client can establish a secure tunnel with an end client of the second type. End clients can perform secure communication through the end client of the second type based on virtual addresses.

[0084] The hierarchical structure of FIGS. 4 and 5 is exemplary and may include additional configurations compared to those depicted in the drawings. For example, the mesh-type end-virtual network operation environment may further include a key management system for managing cryptographic key / IV values, etc. Such configurations may be implemented as logical entities or physical entities.

[0086] FIG. 6 is a diagram illustrating zero-trust access control according to one embodiment.

[0087] Zero Trust is a set of concepts designed to minimize uncertainty in granting permissions accurately and minimally, by treating the network as already compromised whenever a request for access to information systems and services is made. Zero Trust refers to a set of principles for addressing system components, services, and users that are continuously exposed to and potentially compromised by malicious adversaries. Under a system with Zero Trust security, all data and computing services must be separated and protected as resources, and authentication must be performed whenever a request for access to each resource is made.

[0088] According to one embodiment, the zero-trust architecture is divided into a control area and a data area, and includes a policy decision point (PDP) and a policy enforcement point (PEP) for controlling connection requests.

[0089] A PDP can be divided into a Policy Engine (PE) and a Policy Manager (PA). The PE determines trustworthiness and makes the final decision on access authorization. The PA can execute policies by issuing commands to the PEP. The PA informs the PEP of the PE's decision, allowing it to create or close communication paths between the accessing principal and the resource. In the data domain, the PEP is responsible for ultimately establishing or terminating connections based on the determined policy when an accessing principal attempts to access corporate resources. The PA, PE, PA, and PEP can be logical components. These components can be implemented in various ways depending on the corporate network environment, resource types, and access control technologies.

[0090] PDP can determine whether to grant access to resources through a trust assessment based on security information generated by PEP and various security solutions (SIEM, C-TAS, IAM, LMS, etc.). Once access is granted, PDP can establish a bidirectional secure communication path between the accessing entity and corporate resources. The trust assessment can be determined by utilizing artificial intelligence technology based on trust judgment data.

[0091] The core security function of a zero-trust architecture is access control policy. The trust evaluation certification for access to all resources can be determined by communication between PDPs and PEPs. In addition, for further information regarding zero trust, you can refer to documents such as NIST-SP 800-207.

[0092] When implementing a zero-trust architecture based on Software Defined Perimeter (SDP) technology, the SDP controller can perform the role of a PDP.

[0094] FIG. 7 is a flowchart of a mesh-type end-virtual network creation procedure according to one embodiment.

[0095] Referring to FIG. 7, an orchestrator (132) (e.g., the orchestrator (132) of FIG. 1 or the orchestrator (430) of FIG. 4 and 5) can create a mesh-type end-virtual network and transmit mesh-type end-virtual network information to a controller (131) (e.g., the controller (131) of FIG. 1 or the controller (420) of FIG. 4 and 5). Additionally, although the operations described below are described as being performed by the orchestrator (132) and the controller (131), at least some of them may be understood as operations performed by a processor. The procedure for creating a mesh-type end-virtual network and registering end clients to a user is described below.

[0096] In operation S701, the orchestrator (132) can register the controller (131). The administrator can register the controller (131) on the management page of the orchestrator (132).

[0097] In operation S703, the administrator can run the controller (131) to connect to the orchestrator (132).

[0098] In operation S705, the controller (131) can be connected to the orchestrator (132). Through the operation of operations S701 to S705, the controller (131) can obtain a master key.

[0099] In operation S707, the orchestrator (132) can create a mesh-type end-to-end virtual network. The orchestrator (132) can select mesh-type end-to-end virtual network information and a cryptographic algorithm. The cryptographic algorithm may be, for example, any one of ARIA, LEA, or AES. The operation of creating a mesh-type end-to-end virtual network may include an operation of obtaining a cryptographic key and an operation of obtaining IV information. Specifically, the operation of creating a mesh-type end-to-end virtual network may include an operation of generating a cryptographic key, an operation of generating an IV, and an operation of obtaining cryptographic key information and IV information.

[0100] When creating a mesh-type end-to-end virtual network, the orchestrator (132) can define a virtual address block (e.g., 10.1.0.0 / 16) to be assigned to end-to-end clients. End-to-end clients can be assigned a virtual address (e.g., 10.1.1.1 / 32) within the virtual address block according to the administrator's policy. Subsequently, the administrator can define the mesh-type end-to-end virtual network and the user by registering the user and assigning an end-to-end client node to the user.

[0101] In operation S709, the orchestrator (132) can transmit mesh-type end-virtual network information to the controller (131). The mesh-type end-virtual network information may include at least one of mesh-type end-virtual network information, a cryptographic algorithm, a cryptographic key, or an IV value.

[0102] In operation S711, the controller (131) may add a mesh-type end-virtual network in response to an operation to acquire mesh-type end-virtual network information. The controller (131) may register at least one of mesh-type end-virtual network information, a cryptographic algorithm, a cryptographic key, or an IV value in a data structure.

[0103] In operation S713, the orchestrator (132) creates an end client node and, in operation S715, can transmit end client information to the controller (131). The end client information may include end client node information. In response to the acquisition of end client information, in operation S717, the controller (131) can add an end client node.

[0104] In operation S719, the administrator can register a user through the orchestrator (132) and assign an end client node to the user. The orchestrator (132) can store user IDs and end client node information by matching them.

[0105] Through the above procedure, the administrator can define a mesh-type end-to-end virtual network on the management page of the orchestrator (132). The algorithm and mode to be applied to the symmetric key method can be specified by the administrator. Configuration information for the algorithm and mode can be provided to the controller (131). The administrator can register a user and assign an end-to-end client node for the user to use. When registering a user, the administrator can register the user's ID and password.

[0106] The administrator can register an end client node in a mesh-type end virtual network defined on the orchestrator management page. When registering in a mesh-type end virtual network, the end client information obtained by the orchestrator (132) may include at least one of the following: an identifier (ID) of the end client node, a virtual IP address, a node type (first type, second type), a MAC address, a unique identifier (UUID) of the end client node, an attribute allowing connection to the end client node, an attribute allowing external traffic to the end client node, and whether the end client node has a Redirect function.

[0107] When an end client node is assigned to a user, the user ID and the end client node ID can be matched. Additionally, the end client node identifier (ID) can be matched with the assigned mesh-type end virtual network node identifier (ID).

[0108] Subsequently, encryption of control messages transmitted and received between the controller (131) and the end client, or between the end clients, can be applied by generating a new session key using the provided encryption key. Additionally, if a secure tunnel is subsequently created between the end clients, the same encryption operation for control messages can be applied to the data transmitted and received between the end clients.

[0109] Control messages transmitted and received between an end client and a controller, or between end clients, may include an IP header, a UDP header, an indicator, a sequence number, and a datagram. The datagram may include a meshed end virtual network identifier (Vnet ID), a TNI address (or the virtual IP address of the transporting end client), a protocol message, and padding. Encryption algorithms such as ARIA, LEA, or AES may be applied to the protocol message.

[0110] Data transmitted and received between an end client and a controller, or between end clients, may include an external IP header, a UDP header, an identifier, a sequence number, an internal IP header, and a datagram. The external IP header may include a source IP and a destination IP. The external IP header may include a source IP and a destination IP. A datagram may include a data packet and padding. An encryption algorithm such as ARIA, LEA, or AES may be applied to the data packet.

[0112] FIG. 8 is a flowchart of the authentication and mesh-type end-to-end virtual network connection procedure according to one embodiment.

[0113] Referring to FIG. 8, after the orchestrator (132) creates a mesh-type end-to-end virtual network, registers users, and assigns end-to-end clients, the user at the end-to-end client node performs ID / Password-based authentication and can access the mesh-type end-to-end virtual network based on at least one of the cryptographic key, IV value, or end-to-end client configuration information provided during the authentication process. The operations described below are described as being performed by the orchestrator (132), the controller (131), and the end-to-end client devices (110A, 110B), but at least some of them can be understood as operations performed by a processor.

[0114] In operation S801, the orchestrator (132) creates a mesh-type end-virtual network, and in operation S803, transmits the mesh-type end-virtual network information to the controller (131), and in operation S805, the controller (131) can add the mesh-type end-virtual network.

[0115] In operation S807, the first end client device (110A) may transmit an end client authentication request to the orchestrator (132). The user may log in by entering an ID and password through the first end client device (110A). The end client authentication request may include a user ID and a password. The first end client device (110A) (or end client node) may transmit the user ID and password to the orchestrator (132). The user ID and password may be transmitted via TLS. The orchestrator (132), having obtained the user ID and password, may perform user authentication. The orchestrator (132) may authenticate the user by comparing the user ID and password in the user database and query the database for end client information corresponding to the user.

[0116] In operation S809, the orchestrator (132) may generate at least one of an end client key or an end client IV value. In the following description, the end client key refers to a key assigned to an end client, and the end client IV refers to an IV assigned to an end client. The orchestrator (132) may store at least one of the generated key or IV value in a database. In this case, the orchestrator (132) may encrypt and store at least one of the key or IV value.

[0117] In operation S811, the orchestrator (132) can generate end client configuration information. The end client configuration information may include at least one of an end client key or an end client IV value.

[0118] In operation S813, the orchestrator (132) can transmit end client configuration information to the controller (813). The orchestrator (132) can transmit at least one of the end client key or end client IV value to the controller (813). The controller (131) can update the end client configuration information accordingly. The controller (131) can update at least one of the end client key or end client IV value. The controller (813) can derive a new session key based on the end client's key value and the Master Key value provided during the authentication process. The controller (813) can obtain the new session key and use it for encryption.

[0119] The administrator registers the controller on the management page of the orchestrator (132), and the controller (131) checks the settings in the orchestrator (132), copies and saves them, and can connect to the orchestrator (132) by running the controller (131). The master key can be obtained during the controller's connection process.

[0120] In operation S815, the orchestrator (132) may transmit a response to an authentication request to the first end client device (110A). The authentication request may include at least one of information indicating the success or failure of authentication or end client configuration information. The first end client device (110A) may derive a new session key using the master key value and the end client key value. The first end client device (110A) may obtain the new session key and use it for encryption.

[0121] After user authentication is successful, the first end client device (110A) can initiate a connection to the mesh-type end virtual network. The first end client device (110A) can access the mesh-type end virtual network through a connection request and a connection response. In operation S817, the first end client device (110A) can send a Join Request message to the controller (131) to access the mesh-type end virtual network using configuration information. The first end client device (110A) can encrypt the message based on at least one of an algorithm, a mode, a session key, or an IV. For example, the first end client device (110A) can encrypt the message using a session key and an IV value.

[0122] In operation S819, the controller (131) obtains a connection request message and can decrypt it using at least one of an algorithm, a mode, a session key, or an IV value. After checking the configuration information of the corresponding end client, if it is a normal end client, the controller (131) can encrypt the message and transmit a Join Response message in operation S819. The controller (131) can encrypt the Join Response message using a session key and an IV value. The first end client device (110A) can connect to a mesh-type end virtual network after performing additional message transmission and reception. Here, for an explanation regarding additional messages, refer to FIG. 9.

[0123] Referring to FIG. 8, other end clients (e.g., a second end client device (110B)) can also connect to the mesh-type end virtual network using the same procedure. End clients connected to the mesh-type end virtual network can perform virtual address-based encrypted communication. When performing virtual address-based encrypted communication, the end clients can encrypt the data using a symmetric key method, using a session key and IV value specific to each end client. The end client receiving the data can decrypt it using the session key and IV value.

[0124] Each end client connected to the same mesh-type end virtual network can communicate directly with each other based on virtual addresses. Each data can be transmitted and received by encrypting or decrypting it.

[0126] FIG. 9 is a flowchart of an end-client connection procedure according to one embodiment.

[0127] Referring to FIG. 9, a detailed procedure for an end client (e.g., a first end client device (110A)) to connect to a mesh-type end virtual network is described.

[0128] It is assumed that the controller (131) receives at least one of a cryptographic algorithm, mode, cryptographic key or IV value, and configuration information from the orchestrator (132), and has derived a session key to be used for end client encryption. It is assumed that the first end client device (110A) receives at least one of a cryptographic algorithm, mode, cryptographic key or IV value, and configuration information through an authentication process, and has derived a session key with the controller (131). In this state, the procedure for sending and receiving control messages between each component to access the mesh-type end virtual network is described. The following operations may be performed after the first end client device (110A) obtains an authentication response in operation S815 of FIG. 8. Additionally, the controller (131) maintains a mesh-type end virtual network and an end client list.

[0129] In operation S901, the first end client device (110A) can set up a virtual interface. The first end client device (110A) can create a virtual interface to set up a virtual address and set up an MTU.

[0130] In operation S903, the first end client device (110A) transmits a connection request message to the controller (131), and in operation S905, in response to the connection request message, it may obtain a connection response message. Operations S903 and S905 may refer to operations S817 and S819, respectively. The connection response message may include at least one of a virtual address (or virtual IP address) or a virtual address range to be used by the end client. The virtual address may be information obtained when registering the end client node to the virtual security network at the orchestrator (132). A virtual IP address may be assigned to each end client device. The virtual IP address may be referred to as a TNI address.

[0131] In operation S907, the first end client device (110A) can set a virtual IP address on the virtual interface. The first end client device (110A) can set a virtual IP and a subnet on the virtual interface.

[0132] In operation S909, the first end client device (110A) can transmit a Network Type Request message to the controller (131). The first end client device (110A) can transmit the request message to identify the type of connected network, and the transmission of the request message can be performed repeatedly three times.

[0133] In operation S911, the controller (131) can send a Network Type Response message to the first end client device (110A). The controller (131) can set an IP address other than the server's IP as the source address of the packet and send the Network Type Response message to the first end client device (110A). The network type can be checked through the Network Type Response message at the first end client device (110A). For example, if the Network Type Response message is received, the network type can be determined as “Open,” and if it is not received, the network type can be determined as “Restrict.”

[0134] In operation S913, the first end client device (110A) can determine the connected network type and then send a Propagate request message to the controller (131). This is to obtain information about other end clients.

[0135] In operation S915, the controller (131) may obtain a list of end client information containing all end client information connected to the mesh-type end virtual network. The controller (131) may generate the list of end client information. An identifier representing the mesh-type end virtual network may be assigned to a specific mesh-type end virtual network.

[0136] In operation S917, the controller (131) may send a Propagate response message to the first end client device (110A). The Propagate response message may include a list of end client information. The first end client device (110A) that receives the Propagate response message may store the received end client list in a data structure.

[0137] Additionally, in operation S919, the controller (131) may distribute the corresponding end client information to other end clients. The controller (131) may transmit connection information to other end clients. In this case, the other end clients may be end clients connected to the same mesh-type end virtual network. In this case, the controller (131) may use the master key to derive a session key between each end client and use the key and IV value for the other end client for encryption.

[0138] The first end client device (110A) that receives the Propagate response message can send a peer network request message to the second end client device (110B) in operation S921. In this case, the second end client device (110B) may be connected to the same mesh-type end virtual network.

[0139] In operation S923, the second end client device (110B) can transmit a peer network response message to the first end client device (110A) in response to the acquisition of a peer network request message.

[0140] In operation S925, the first end client device (110A) can add tunnel information to the peer end client.

[0141] If direct communication with the counterpart client is possible, the first counterpart client device (110A) can send a peer network request message over a public IP. The counterpart client, the second counterpart client device (110B), can send a peer network response message to the first counterpart client device (110A) as soon as it receives the message. Upon receiving the peer network response message, the first counterpart client device (110A) can establish a secure tunnel directly to the counterpart client, the second counterpart client device (110B).

[0142] If the first end client device (110A) is unable to communicate directly with the counterpart end client, it may send a peer network request message to the public IP of the second end client device (110B), which is the counterpart end client. If no response is received, the transmission of the request message may be repeated three times. If no response message is received from the counterpart end client, the security tunnel to the counterpart end client may be configured as a bypass security tunnel leading to the DTR.

[0143] After establishing a direct security tunnel or an bypass security tunnel with the counterpart end client, each end client can send a peer TNI request message to the counterpart end client. Upon receiving the peer TNI request message, the end client can send a peer TNI response message to the counterpart end client.

[0144] The end client can use the Round Trip Time (RTT) value with the counterpart end client as network quality information through the transmission and reception of peer TNI request and peer TNI response messages. The end client of the DTR type can establish a direct security tunnel with all end clients connected to the mesh-type end virtual network and periodically transmit the RTT value collected from the counterpart end client to the controller (131).

[0145] The NAT Traversal procedure is a process that checks for changes in the IP and port of an end client and provides them to other end clients connected to a mesh-type end virtual network, and may include at least some of operations S911 to S915. The UDP Hole Punching procedure is a process that establishes a direct secure tunnel between end clients and may include at least some of operations S917 to 911.

[0147] FIG. 10 is a flowchart of a signal transmission and reception procedure on a mesh-type end-to-end virtual network according to one embodiment.

[0148] Referring to FIG. 10, the first end client device can transmit data packets acquired from the security device to a second end client device outside the security device through a mesh-type end virtual network. A device outside the security device may refer to a device that is physically separated from the security device or a device that accesses the security device by penetrating the security device's firewall. Alternatively, it may refer to an end client device that can access the security device according to the security device's SD-WAN protocol policy.

[0149] In operation S1010, a first end client (e.g., the first end client device (110A) of FIG. 1) can obtain configuration information of the first end client. The first end client can obtain the first end client configuration information from an orchestrator (e.g., the orchestrator (132) of FIG. 1). The first end client configuration information may include at least one of a mesh-type end virtual network identifier assigned to the first end client, a virtual IP address of the first end client, a cryptographic key assigned to the first end client, and an IV value assigned to the first end client.

[0150] In operation S1020, the first end client may perform a mesh-type end virtual network connection operation. The first end client may perform a mesh-type end virtual network connection operation based on at least some of the acquired first end client configuration information. The mesh-type end virtual network connection operation may include operations described in various embodiments of the present invention. For example, the first end client may send a connection request message to a controller (e.g., controller (131) of FIG. 1) and obtain a connection response message from the controller. The connection request message is a message that the end client sends to the controller when connecting to the mesh-type end virtual network.

[0151] A connection request message may include at least one of a mesh-type end virtual network identifier, a virtual IP address (the controller's TNI address), the IP address of a first end client (Public IP Address), a mesh-type end virtual network subnet address, the subnet address of the first end client, the virtual IP address of the first end client (the first end client's virtual IP address), and the controller's subnet address.

[0152] In operation S1030, the first end client can obtain a data packet from the end device.

[0153] According to one embodiment, the end device may include a security device such as the enterprise device (140) of FIG. 1 or a device connected to the same mesh-type end virtual network at the same layer as the first end client (e.g., a third end client device). Alternatively, the operation of receiving data packets from the end device may follow a software-defined wide area network (SD-WAN) protocol. Alternatively, the operation of receiving data packets from the end device may be transmitted through a mesh-type end virtual network according to an embodiment of the present invention. That is, the operation of receiving data packets from the end device may follow a software-defined mesh-type end virtual network protocol as described in the present invention.

[0154] In operation S1040, the first end client can transmit a data packet to the second end client (e.g., the second end client (130) of FIG. 1). The data packet can be encrypted based on configuration information obtained by the first end client device. For example, the first end client can derive a new session key based on the key value of the first end client and the Master Key value provided during the authentication process. Subsequently, the first end client can encrypt the data packet using the new session key.

[0155] A data packet transmitted to a second end client can be decrypted by the second end client. The second end client can decrypt the data packet using a session key.

[0156] A second end client capable of transmitting data from a first end client is an end client connected to the same mesh-type end virtual network as the first end client. End clients that do not share the same mesh-type end virtual network as the first end client cannot access the data packet. Through mesh-type end virtual network allocation and connection operations with the orchestrator and controller, the first end client and the second end client can share the same mesh-type end virtual network identifier, the same master key, encryption algorithm, the list of end clients of the corresponding mesh-type end virtual network, and end client configuration information.

[0157] Through this, when a specific user owns multiple end client devices, direct data transmission and reception becomes possible between devices connected to the same meshed end virtual network without each end client device having to access corporate resources individually to verify corporate security data on each end client device. Consequently, traffic issues occurring in edge computing network environments can be reduced, and data transmission and reception efficiency as well as resource usage efficiency can be improved.

[0159] According to one embodiment, clients can be classified into two types. For example, they can be distinguished into a host type and a DTR type. The host type is a client installed on a user terminal or a server providing a service, while the DTR type can operate in a location where all clients can communicate. In cases where communication between host type clients is impossible (clients connected to NAT), each client establishes a secure tunnel with a DTR type client. Clients can perform secure communication through the DTR type client based on virtual addresses.

[0160] Generally, it can be assumed that a client connects to a network either via NAT or to a public network. Communication with a client connected to NAT is impossible. Conversely, a client connected to NAT can communicate with clients that are not connected.

[0161] Even with UDP Hole Punching applied, direct security tunnels can be established between clients connected to NAT. A client located on the public network that routes tunnels between clients that cannot establish direct security tunnels is called a DTR. To provide virtual address-based direct communication between clients that cannot establish direct security tunnels, if a client is configured as a DTR type when registering it in a virtual security network, clients within the virtual security network can establish direct security tunnels with DTR-type clients, while clients unable to establish direct security tunnels can be configured to bypass tunnels to the other clients via the DTR. A DTR-type client can route tunneling packets to the corresponding client.

[0162] When DTR type clients are applied to a virtual security network, all clients can communicate directly encrypted based on virtual addresses.

[0164] FIG. 11 is a diagram illustrating a mesh-type end-to-end virtual network operation environment according to an embodiment of the present invention.

[0165] Referring to FIG. 11, in a situation where multiple end clients (1110A, 1110B) form a mesh-type end virtual network and transmit and receive data to and from each other, if an eSIM (embedded SIM (subscriber identity module)) is activated in at least one end client device, the operation of the mesh-type end virtual network can be maintained.

[0166] In the following, it is assumed that an eSIM is installed in the first end client device (1110A). Additionally, it may be assumed that the first end client device (1110A) is equipped with a detachable external hardware-type USIM (Universal SIM).

[0167] Hereinafter, the service provided by the first telecommunications service provider through USIM is referred to as the first telecommunications service network (first network), and the service provided by the second telecommunications service provider through eSIM is referred to as the second telecommunications service network (second network).

[0168] The first network and the second network may support the same communication protocol, or they may support different communication protocols. For example, the first network may be Wi-Fi (Wireless Fidelity) and the second network may be a communication network such as LTE, LTE-Advanced, 5G, or 6G. Alternatively, even if the first network and the second network support the same communication protocol, the service providers may be different.

[0169] Meanwhile, the MAC address of the first end client device (1110A) connected to the first network (hereinafter, the first MAC address) and the MAC address of the second end client device (1110B) connected to the second network (hereinafter, the second MAC address) may be different from each other.

[0170] If a first MAC address is registered with a controller (1131) (e.g., controller (131) of FIG. 1) and / or an orchestrator (1132) (e.g., orchestrator (1132) of FIG. 1) for a first end client device (1110A), the first end client device (1110A) may access data (1140) only through the first network with the permission of the controller (1131). Accordingly, if the eSIM is activated and the second end client device (1110A) attempts to access data (1140) restricted by the software-defined security network through the second network, the controller (1131) may restrict access by the first end client device (1110A). Here, being activated means that the SIM is in an enabled state.

[0171] However, in the case where the first end client device (1110A) and the second end client device (1110B) form a mesh-type end virtual network (1110) according to FIGS. 1 to 10, the first end client device (1110A) can share the data (1140) through the second end client device (1110B), which is allowed to access the data (1140) through the controller (1131).

[0172] Alternatively, for the first end client device (1110A) to access data (1140) through the second network, an additional connection procedure may be required to the software-defined security network of the controller (1131).

[0173] Although FIGS. 11 and 12 assume a case where the eSIM is activated, the above embodiment can be similarly applied even when the user activates the physical SIM and deactivates the eSIM when access to a software-defined security network is permitted using the eSIM.

[0175] FIG. 12 illustrates the data transmission and reception flow of a device including a plurality of shims in a mesh-type end-virtual network according to one embodiment.

[0176] In FIG. 12, it is assumed that the first end client device (1110A) is equipped with a USIM. The first end client device (1110A) can connect to a first network provided by a first communication service provider through the USIM. Additionally, it is assumed that the first end client device (1110A) can access data (1140) (or resources) that are restricted from access by the controller (1131) of the software-defined security network through the first network. Similarly, it is assumed that the second end client device (1110B) can also access data (1140) that is restricted from access by the controller (1131) of the software-defined security network. The second end client device (1110B) can access data (1140) through a network connected to the controller (1131). Additionally, it is assumed that the first end client device (1110A) and the second end client device (1110B) form the same mesh-type virtual network as described in FIGS. 1 to 10.

[0177] The network connected by the second end client device (1110B) is not necessarily limited to the first network and the second network mentioned in FIGS. 11 and 12. For example, if the first network and the second network each conform to a specific communication protocol, the network connected by the second end client device (1110B) may conform to a communication protocol different from the specific communication protocol.

[0178] In operation S1301, the second end client device (1110B) can access or obtain data (1140) that is restricted from access by a software-defined security network. In operation S1303, the second end client device (1110B) can share data with the first end client device (1110A) through the first mesh-type end virtual network. Alternatively, as in operation S1305, the first end client device (1110B) may directly obtain data by connecting to the software-defined security network.

[0179] In operation S1307, the first end client device (1110A) can activate the eSIM. While connected to the mesh-type end virtual network, the first end client device (1110A) can activate the eSIM in response to user input. After activating the eSIM, the first end client device (1110A) can connect to the second network according to the information stored in the eSIM.

[0180] When a first end client device (1110A) attempts to connect to a software-defined security network through a second network, the attempt by the first end client device (1110A) may be restricted by the controller (1131). The first end client device (1110A) may request a connection to the software-defined security network from the controller (1131) or an orchestrator (e.g., the orchestrator (1132) of FIG. 11) using a second MAC address. In this case, the controller (1131) or the orchestrator (1132) may ignore the connection request based on the second MAC address. Here, the first end client device (1110A) may be disconnected from the connection or link to the first network.

[0181] Instead, the first end client device (1110A) can obtain data (1140) that is restricted from access through the first mesh-type end virtual network while connected to or connected to the second network. That is, while the first end client device (1110A) is connected to the second network, it can obtain a data packet containing the data from another end client device connected to the first mesh-type end virtual network through the first mesh-type end virtual network.

[0182] The second end client device (1110B) can obtain data (1140) whose access is restricted or blocked by a software-defined security network (or data (1140) stored in a management device whose access is restricted or blocked by a software-defined security network). The second end client device (1110B) can transmit or share the obtained data to the first end client device (1110A) through the first mesh-type end virtual network. That is, the first end client device (1110A) can obtain a data packet containing the data from the second end client device (1110B) through an existing security tunnel.

[0183] The above data packet may be encrypted by a first end client device (1110A) and decrypted by a second end client device (1110B) that shares the same algorithm. The above data packet may be encrypted based on a symmetric key by the first end client device (1110A) and decrypted based on a symmetric key by the first end client device.

[0184] Recently, devices supporting dual-SIM or multiple SIMs are primarily being utilized. By utilizing the mesh-type end-to-end virtual network according to the present invention, even when changes occur in communication services due to the use of multiple SIMs, users can access limited resources through the mesh-type end-to-end virtual network without directly connecting to the software-defined security network. This allows for the stable sharing of a continuous user experience even when the communication environment changes.

[0186] Although all components constituting the embodiments of the present invention have been described above as being combined or operating together, the present invention is not necessarily limited to such embodiments. That is, within the scope of the purpose of the present invention, all components may be selectively combined and operated in one or more ways.

[0187] Meanwhile, the various embodiments described herein may be implemented by hardware, middleware, microcode, software, and / or combinations thereof. For example, the various embodiments may be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions presented herein, or combinations thereof.

[0188] Additionally, for example, various embodiments may be stored or encoded on a computer-readable medium containing instructions. Instructions stored or encoded on a computer-readable medium may enable a programmable processor or other processor to perform a method, for example, when the instructions are executed. A computer-readable medium includes a computer storage medium, and the computer storage medium may be any available medium accessible by a computer. For example, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage media, magnetic disk storage media or other magnetic storage devices.

[0189] Such hardware, software, firmware, etc., may be implemented within the same device or in individual devices to support the various operations and functions described in this specification. Additionally, components, units, modules, components, etc., described as “parts” in this invention may be implemented together or individually as separate but interoperable logic devices. Descriptions of different features for modules, units, etc., are intended to highlight different functional embodiments and do not necessarily imply that they must be realized by individual hardware or software components. Rather, functions associated with one or more modules or units may be performed by individual hardware or software components or integrated within common or individual hardware or software components.

[0190] Although operations are depicted in a specific order in the drawings, it should not be understood that these operations must be performed in the specific order depicted or in a sequential order to achieve the desired result, or that all depicted operations must be performed. In any environment, multitasking and parallel processing may be advantageous. Furthermore, the distinction between the various components in the above-described embodiments should not be understood as requiring such distinction in all embodiments, and it should be understood that the described components may generally be integrated together into a single software product or packaged into multiple software products.

[0191] The electronic device, server, or external device according to the various embodiments of the present document described above may include, for example, at least one of a smartphone, tablet PC, mobile phone, video phone, desktop PC, laptop PC, PDA (personal digital assistant), PMP (portable multimedia player), MP3 player, mobile medical device, camera, or wearable device.

[0192] According to various embodiments, the wearable device may include at least one of an accessory type (e.g., a watch, ring, bracelet, anklet, necklace, glasses, contact lens, or head-mounted device (HMD)), a fabric or clothing integrated type (e.g., electronic clothing), a body-attached type (e.g., a skin pad or tattoo), or a bio-implantable type (e.g., an implantable circuit).

[0193] In some embodiments, the electronic device or external device may be a home appliance. The home appliance may include, for example, at least one of a television, a DVD player (Digital Video Disk player), audio, a refrigerator, an air conditioner, a vacuum cleaner, an oven, a microwave oven, a washing machine, an air purifier, a set-top box, a home automation control panel, a security control panel, a TV box, a game console, an electronic dictionary, an electronic key, a camcorder, or a digital photo frame.

[0194] In another embodiment, the electronic device, external device, and wearable device may include at least one of various medical devices (e.g., various portable medical measuring devices (blood glucose meter, heart rate monitor, blood pressure monitor, or body temperature monitor, etc.), MRA (magnetic resonance angiography), MRI (magnetic resonance imaging), CT (computed tomography), imaging device, or ultrasound device, etc.), navigation device, satellite navigation system (GNSS (Global Navigation Satellite System)), EDR (event data recorder), FDR (flight data recorder), automotive infotainment device, home robot, or Internet of Things device (e.g., light bulb, various sensor, electric or gas meter, sprinkler device, fire alarm, thermostat, street light, exercise equipment, hot water tank, heater, boiler, etc.).

[0196] As described above, the best embodiments have been disclosed in the drawings and specification. Specific terms have been used herein, but they are used only for the purpose of describing the invention and are not intended to limit the meaning or the scope of the invention as described in the claims. Therefore, those skilled in the art will understand that various modifications and equivalent alternative embodiments are possible therefrom. Accordingly, the true technical scope of protection of the invention should be determined by the technical spirit of the appended claims.

Claims

Claim 1 A data communication method performed by an end client device supporting a plurality of subscriber identification modules, comprising: an operation of connecting to a mesh-type end virtual network based on configuration information of the end client device through a first network associated with a first subscriber identification module among the plurality of subscriber identification modules; an operation of activating a second subscriber identification module among the plurality of subscriber identification modules to connect to a second network associated with the second subscriber identification module while connected to the mesh-type end virtual network; and an operation of transmitting and receiving data packets through the mesh-type end virtual network with another end client device connected to the mesh-type end virtual network while connected to the second network. Claim 2 The method of claim 1, wherein the terminal client device disconnects the connection to the first network while connected to the second network. Claim 3 The method of claim 1, wherein the terminal client device maintains a connection to the first network even while connected to the second network. Claim 4 A method according to claim 1, wherein the first subscriber identification module is a detachable physical SIM (Subscriber Identification Module) and the second subscriber identification module is an eSIM (embedded SIM). Claim 5 An end client device that performs data communication through a mesh-type end virtual network, comprising: a communication circuit for transmitting and receiving signals with an external device; a memory; a first subscriber identification module and a second subscriber identification module; and at least one processor connected to at least one of the communication circuit, the memory, and the first subscriber identification module or the second subscriber identification module, wherein the at least one processor is configured to connect to the mesh-type end virtual network based on configuration information of the end client device through a first network associated with the first subscriber identification module, and while connected to the mesh-type end virtual network, activate the second subscriber identification module to connect to a second network associated with the second subscriber identification module, and while connected to the second network, transmit and receive data packets through the mesh-type end virtual network with another end client device connected to the mesh-type end virtual network.

Images