Method and electronic device for edge computing service

Abstract

The present disclosure relates to a 5G or pre-5G communication system to be provided for supporting a data transmission rate higher than that of a 4G communication system such as LTE. A method according to an embodiment of the present invention is a method for authenticating an electronic device that receives an edge computing service from an authentication server of a mobile communication system, wherein the method may include the following steps: performing a first authentication (403) of the electronic device through authentication and key agreement (AKA) with the electronic device, and, when the first authentication succeeds, providing first authentication information to the electronic device; and performing a second authentication (411) of an edge computing service for the electronic device, and, when the second authentication succeeds, providing the electronic device with second authentication information including an access token for authentication of the edge computing service.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to methods and electronic devices thereof for supporting edge computing services (e.g., multi-access edge computing (MEC) services). Background Art

[0002] In order to meet the demand for wireless data traffic that has grown since the deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "beyond 4G networks" or "post-LTE systems."

[0003] The 5G communication system is considered to be implemented in the ultra-high frequency (mmWave) band (e.g., the 60 GHz band) in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed in the 5G communication system.

[0004] In addition, in the 5G communication system, development for system network improvement is underway based on advanced small cells, cloud radio access network (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multi-point (CoMP), receiving-end interference cancellation, etc.

[0005] In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as advanced coded modulation (ACM) have also been developed, as well as sparse code multiple access (SCMA) and non-orthogonal multiple access (NOMA), filter bank multi-carrier (FBMC) as advanced access technologies.

[0006] According to such a technical trend, a technology for using a channel bonding scheme in a WiFi wireless communication system, which is one of various wireless communication systems, for high-speed data transmission has emerged. In a WiFi wireless communication system, a scheme using a channel bonding technology binds an additional frequency band to a basic frequency band to increase the data transmission rate. The standard of the technology stipulates that, for example, the IEEE 802.11ac standard can bind 8 20MHz channels to support a maximum 160MHz frequency band, and the channel bonding technology will be applied to the IEEE 802.11ay standard. When using the channel bonding technology, the increase in power consumption of electronic devices is inevitable.

[0007] Edge computing technology for transmitting data through edge servers has been discussed recently. Edge computing technology may include, for example, multi-access edge computing (MEC) or fog computing. Edge computing technology may be a technology for providing data to electronic devices by installing a separate server (hereinafter referred to as an edge server or MEC server) at a location geographically close to the electronic device (e.g., within a base or near a base station). For example, an application that requires low latency among at least one application installed in the electronic device can send and receive data through an edge server installed at a geographically close location without traversing a server located in an external data network (DN) (e.g., the Internet).

[0008] Recently, services using edge computing technology (hereinafter referred to as "MEC-based services" or "MEC services") have been discussed, and electronic devices supporting MEC-based services have been studied and developed. For example, an application of a mobile communication electronic device can send and receive edge computing-based data to and from an edge server (or an application of an edge server) at the application layer. Summary of the invention

[0009] Technical issues

[0010] In MEC-based services, security services should be provided to perform, for example, services between electronic devices (or users), networks, operators, or application providers. For example, for MEC services, the edge server (or MEC application) needs to provide services (or access) to authenticated and authorized (licensed) electronic devices (or client applications). For example, an application of an electronic device can communicate with an application of an edge server, and the edge server can authenticate the application of the electronic device and grant authorization based on the authentication result. For example, in a MEC-based service, authorized applications between an electronic device and an edge server can communicate with each other. For example, an electronic device and an edge server can perform a discovery (e.g., MEC discovery) process (or MEC service discovery process) when authentication between them is completed.

[0011] At the same time, when multiple applications are installed in an electronic device, each application can communicate with the edge server separately at the application layer to perform edge computing-based data transmission. For example, in the prior art, an application in an electronic device can perform authentication, authorization, and discovery processes separately to use MEC services.

[0012] Various embodiments disclose methods and apparatus capable of providing services to electronic devices by executing MEC applications on the basis of a more optimized MEC host.

[0013] Various embodiments disclose methods and apparatus capable of providing services to electronic devices by executing MEC applications on the basis of a more optimized MEC host.

[0014] Various embodiments disclose methods and apparatus for performing discovery operations by an electronic device (eg, an MEC service module) rather than a separate application.

[0015] Various embodiments disclose methods and apparatus that are capable of more quickly and efficiently performing discovery and selection of a MEC host that can be received with the best quality by allowing an electronic device (e.g., an MEC service module) rather than a separate application to perform MEC discovery.

[0016] Various embodiments disclose methods and apparatus capable of providing a stable edge computing service by managing the state of an application and the state of an electronic device together through an MEC service module installed in the electronic device.

[0017] Solution to the problem

[0018] The method according to an embodiment of the present disclosure is a method for authenticating an electronic device that receives an edge computing service from an authentication server of a mobile communication system, and includes performing a first authentication (403) of the electronic device in an authentication and key agreement (AKA) scheme with the electronic device, and providing first authentication information to the electronic device when the first authentication is successful; and performing a second authentication (411) of an edge computing service for the electronic device, and providing the electronic device with second authentication information including an access token for authentication of the edge computing service.

[0019] A method according to another embodiment of the present disclosure is a method for authentication of an edge computing service in a mobile communication system, wherein an electronic device of the mobile communication system provides an edge computing service, and includes performing a first authentication (403) of the electronic device in an authentication and key agreement (AKA) scheme with an authentication server of the mobile communication system, and receiving first authentication information by the electronic device; and performing a second authentication (411) for the edge computing service with the authentication server, and receiving second authentication information including an access token for authentication of the edge computing service by the electronic device.

[0020] A method according to another embodiment of the present disclosure is a method for providing edge computing service information to an electronic device receiving edge computing services through a multi-access edge computing management proxy (MMP) server of a mobile communication system, and includes receiving a query message of at least one edge computing server including a fully qualified domain name (FQDN) for the MMP from the electronic device; and sending a response message to the electronic device for responding to the query, wherein the response message includes a list of applications for providing edge computing services through the MMP.

[0021] A method according to another embodiment of the present disclosure is a method for an electronic device in a mobile communication system for providing edge computing services to obtain edge computing service information through a multi-access edge computing management agent (MMP) server, and includes sending a query message of at least one edge computing server including a fully qualified domain name (FQDN) for the MMP to the MMP; and receiving a response message from the MMP for responding to the query, wherein the response message includes a list of applications for providing edge computing services through the MMP.

[0022] An electronic device according to an embodiment of the present disclosure includes a network interface; at least one application for edge computing services (multi-access edge computing services (MEC)); a multi-access service agent (MSA), configured to perform authentication of the electronic device, authentication of the MEC, policies of the MEC and control through the network interface according to the configuration of the data path of the MEC; and a multi-access service enabler (MSE), configured to establish (set) a session with a MEC management proxy server (MMP) of a mobile communication system through the network interface, configure a path in data transmission through the MMP, send query information, receive a response signal and perform discovery of a MEC application server.

[0023] Advantageous Effects of the Invention

[0024] Electronic devices and operating methods thereof according to various embodiments can provide services for electronic devices by executing MEC applications on the basis of a more optimized MEC host. According to various embodiments, service discovery operations can be performed by an electronic device (e.g., a service enabler) rather than by a separate application. According to various embodiments, since MEC discovery is performed by an electronic device (e.g., a service enabler) rather than by a separate application, discovery can be performed more quickly and efficiently, and a MEC host capable of receiving with the best quality can be selected. According to various embodiments, a stable edge computing service can be provided by managing the state of the application and the state of the electronic device together through a MEC service module installed in the electronic device.

[0025] Furthermore, various effects detected directly or indirectly by the present disclosure can be provided. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a block diagram illustrating an electronic device 101 within a network environment 100 according to various embodiments.

[0027] Figure 2 2 is a block diagram 200 illustrating an electronic device 101 for supporting both traditional network communications and 5G network communications according to various embodiments.

[0028] Figure 3 An electronic device 101 and an external server 300 for supporting MEC-based services in a network environment according to various embodiments of the present disclosure are shown.

[0029] Figure 4 An example of an authentication process according to various embodiments of the present disclosure is shown.

[0030] Figure 5 An example of an authentication process according to various embodiments of the present disclosure is shown.

[0031] Figure 6 An example of an authentication process according to various embodiments of the present disclosure is shown.

[0032] Figure 7 An example of an authentication process according to various embodiments of the present disclosure is shown.

[0033] Figure 8 An example of a policy update operation by the electronic device 101 according to various embodiments of the present disclosure is shown.

[0034] Fig. 9 An example of a PDU session establishment operation by the electronic device 101 according to various embodiments of the present disclosure is shown.

[0035] Fig.10 An example of a discovery process according to various embodiments of the present disclosure is shown.

[0036] Fig.11 An example of a discovery process according to various embodiments of the present disclosure is shown.

[0037] Fig.12 An example of an operation of acquiring an app list during a discovery process according to various embodiments of the present disclosure is shown.

[0038] Fig.13 An example of providing an app list according to various embodiments of the present disclosure is shown.

[0039] Fig.14 is a diagram illustrating an example of a context creation process in a discovery process according to various embodiments.

[0040] Fig.15 An example of a MEC host selection process in a discovery process according to various embodiments of the present disclosure is shown.

[0041] Fig.16 An example is shown in which the electronic device 101 separately manages a local DNS cache for MEC according to various embodiments.

[0042] Fig.17 An example is shown in which the electronic device 101 manages a local DNS cache for MEC within the MSE 330 according to various embodiments of the present disclosure.

[0043] Fig.18 is a diagram illustrating an example of a DNS resolution operation in a discovery process according to various embodiments of the present disclosure. DETAILED DESCRIPTION

[0044] Figure 1 is a block diagram illustrating an electronic device 101 within a network environment 100 according to various embodiments.

[0045] Reference Figure 1 , the electronic device 101 may communicate with the electronic device 102 through the first network 198 (e.g., a short-range wireless communication network) in the network environment 100 or communicate with the electronic device 104 or the server 108 through the second network 199 (e.g., a long-range wireless communication network). According to an embodiment, the electronic device 101 may communicate with the electronic device 104 through the server 108. According to an embodiment, the electronic device 101 may include a processor 120, a memory 130, an input device 150, a sound output device 155, a display device 160, an audio module 170, a sensor module 176, an interface 177, a haptic module 179, a camera module 180, a power management module 188, a battery 189, a communication module 190, a subscriber identification module 196, or an antenna module 197. In some embodiments, at least one of the elements (e.g., the display device 160 or the camera module 180) may be omitted or one or more elements may be added to the electronic device 101. In some embodiments, some of the elements may be implemented as one integrated circuit. For example, the sensor module 176 (eg, a fingerprint sensor, an iris sensor, or an illumination sensor) may be implemented while being embedded in the display device 160 (eg, a display).

[0046] The processor 120 may control at least one other element (e.g., hardware or software component) connected to the processor 120 by executing, for example, software (e.g., program 140) and perform various data processing or calculations. According to an embodiment, as at least part of the data processing or calculation, the processor 120 may load a command or data received from another element (e.g., sensor module 176 or communication module 190) to the volatile memory 132, process the command or data stored in the volatile memory 132, and store the resultant data in the non-volatile memory 134. According to an embodiment, the processor 120 may include a main processor 121 (e.g., a central processing unit (CPU) or an application processor (AP)) and an auxiliary processor 123 (e.g., a graphics processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)) that may operate independently of the main processor or together with the main processor. Additionally or alternatively, the auxiliary processor 123 may use lower power than the main processor 121 or may be configured to be dedicated to a predetermined function. The auxiliary processor 123 may be implemented separately from the main processor 121 or as a part thereof.

[0047] The auxiliary processor 123 may control at least some of the functions or states related to at least one of the elements of the electronic device 101 (e.g., the display device 160, the sensor module 176, or the communication module 190) on behalf of the main processor 121 when the main processor 121 is in an inactive (e.g., sleep) state, or together with the main processor 121 when the main processor 121 is in an active (e.g., application execution) state. According to an embodiment, the auxiliary processor 123 (e.g., an image signal processor or a communication processor) may be implemented as a part of another element (e.g., the camera module 180 or the communication module 190) functionally associated therewith.

[0048] The memory 130 may store various data used by at least one element of the electronic device 101 (e.g., the processor 120 or the sensor module 176). The data may include software (e.g., the program 140) and input data or output data about commands related thereto. The memory 130 may include a volatile memory 132 or a nonvolatile memory 134.

[0049] The program 140 may be stored as software in the memory 130 , and may include, for example, an operating system (OS) 142 , middleware 144 , or application programs 146 .

[0050] Input device 150 may receive commands or data from outside of electronic device 101 (e.g., a user) to be used by elements of electronic device 101 (e.g., processor 120). Input device 150 may include, for example, a microphone, a mouse, a keyboard, or a digital pen (e.g., a stylus).

[0051] The sound output device 155 can output a sound signal to the outside of the electronic device 101. The sound output device 155 may include, for example, a speaker or a receiver. The speaker may be used for general purposes such as reproducing multimedia or recording reproduction, and the receiver may be used to receive an incoming call. According to an embodiment, the receiver may be implemented separately from the speaker or as a part thereof.

[0052] The display device 160 can visually provide information to the outside of the electronic device 101 (e.g., a user). The display device 160 may include, for example, a display, a holographic device, a projector, and a control circuit for controlling the corresponding device. According to an embodiment, the display device 160 may include a touch circuit (circuit system) configured to detect a touch or a sensor circuit (e.g., a pressure sensor) configured to measure the strength of the force generated by the touch.

[0053] The audio module 170 can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to an embodiment, the audio module 170 can obtain sound through the input device 150 or output sound through the sound output device 155 or an external electronic device (e.g., electronic device 102) (e.g., speaker or earphone) directly or wirelessly connected to the electronic device 101.

[0054] The sensor module 176 may detect an operating state (e.g., power or temperature) or an external environment state (e.g., a user state) and generate an electrical signal or data value corresponding to the detected state. According to an embodiment, the sensor module 176 may include, for example, a gesture sensor, a gyroscope sensor, a barometer sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor (e.g., an RGB (red, green, blue) sensor), an infrared sensor (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illumination sensor.

[0055] The interface 177 may support one or more predetermined protocols, which may be used to directly or wirelessly connect an external electronic device (e.g., the electronic device 102) to the electronic device 101. According to an embodiment, the interface 177 may include, for example, a high-definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface.

[0056] The connection terminal 178 may include a connector, and the electronic device 101 may be physically connected to an external electronic device (e.g., the electronic device 102) through the connector. According to an embodiment, the connection terminal 178 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0057] The haptic module 179 may convert the electric signal into mechanical stimulation (eg, vibration or motion) or electric stimulation that the user may sense through a sense of touch or a sense of movement. According to an embodiment, the haptic module 179 may include, for example, a motor, a piezoelectric element, or an electric analog device.

[0058] The camera module 180 may capture still images and moving images. According to an embodiment, the camera module 180 may include one or more lenses, image sensors, image signal processors, or flashes.

[0059] The power management module 188 may manage power supplied to the electronic device 101. According to an embodiment, the power management module 188 may be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

[0060] The battery 189 may supply power to at least one element of the electronic device 101. According to an embodiment, the battery 189 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0061] The communication module 190 may support a direct (e.g., wired) communication channel or a wireless communication channel created between the electronic device 101 and an external electronic device (e.g., electronic device 102, electronic device 104, or server 108) and communication through the created communication channel. The communication module 190 may include one or more communication processors that operate independently of the processor 120 (e.g., an application processor) and support direct (e.g., wired) communication or wireless communication. According to an embodiment, the communication module 190 may include a wireless communication module 192 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (e.g., a local area network (LAN) communication module or a power line communication module). Among the communication modules, the corresponding communication module may communicate with an external electronic device through a first network 198 (e.g., a short-range communication network such as Bluetooth, Wi-Fi Direct, or Infrared Data Association (IrDA)) or a second network 199 (e.g., a long-range communication network such as a cellular network, the Internet, or a computer network (e.g., LAN or WAN)). Such various types of communication modules may be integrated into one element (eg, a single chip), or may be implemented as a plurality of separate elements (eg, a plurality of chips).

[0062] The wireless communication module 192 may identify and authenticate the electronic device 101 within a communication network such as the first network 198 or the second network 199 through subscriber information (eg, International Mobile Subscriber Identity (IMSI)) stored in the subscriber identification module 196 .

[0063] The antenna module 197 may send a signal or power to the outside (e.g., an external electronic device) or receive a signal or power from the outside. According to an embodiment, the antenna module 197 may include an antenna including a conductor configured on a substrate (e.g., a PCB) or a radiator configured with a conductive pattern. According to an embodiment, the antenna module 197 may include a plurality of antennas. In this case, for example, the communication module 190 may select at least one antenna suitable for a communication scheme used by a communication network such as the first network 198 or the second network 199 from among the plurality of antennas. Signals or power may be sent or received between the communication module 190 and the external electronic device by at least one selected antenna. According to some embodiments, another component (e.g., an RFIC) and a radiator may be additionally implemented as part of the antenna module 197.

[0064] At least some of the elements may be interconnected via a scheme for communication between peripheral devices (e.g., a bus, a general purpose input / output (GPIO), a serial peripheral interface (SPI), or a mobile industry processor interface (MIPI)), and signals (e.g., commands or data) may be exchanged therebetween.

[0065] According to an embodiment, a command or data may be transmitted or received between the electronic device 101 and the external electronic device 104 through the server 108 connected to the second network 199. Each of the electronic devices 102 and 104 may be a device of the same type as or different from the electronic device 101.

[0066] According to an embodiment, all or some of the operations performed by the electronic device 101 can be performed by one or more of the external electronic devices 102, 104 and 108. For example, when the electronic device 101 is required to perform a function or service automatically or in response to a request from a user or another device, the electronic device 101 can make a request to perform at least some of the functions or services to one or more external electronic devices 102 and 104 instead of performing the function or service by itself or in addition to performing the function or service. The one or more external electronic devices 102 and 104 that receive the request can perform at least some of the requested function or service or other functions or services related to the request, and transmit the result of the execution to the electronic device 101. The device 101 can provide a result or process the result and provide the processed result as at least part of the response to the request. To achieve this, for example, cloud computing, distributed computing or client server computing technology can be used.

[0067] The electronic device 101 according to various embodiments disclosed herein may be one of various types of electronic devices. The electronic device 101 may include, for example, a portable communication device (e.g., a smart phone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. The electronic device 101 according to an embodiment of the present disclosure is not limited to those described above.

[0068] It should be understood that the various embodiments of the present disclosure and the terms used therein are not intended to limit the technical features set forth herein to specific embodiments and include various changes, equivalents or substitutes for corresponding embodiments. With respect to the description of the drawings, the same reference numerals may be used to designate the same or related elements. The singular form of a noun corresponding to an item may include one or more things unless the relevant context clearly indicates otherwise.

[0069] As used herein, each of phrases such as "A or B", "at least one of A and B", "at least one of A or B", "A, B or C", "at least one of A, B and C", and "at least one of A, B or C" may include all possible combinations of items listed together in one of the corresponding phrases. As used herein, terms such as "first", "second", "the first" and "the second" may be used to merely distinguish the corresponding element from another, and do not otherwise limit the elements (e.g., importance or order). It should be understood that if an element (e.g., a first element) is referred to as being "coupled with", "coupled to", "connected with", or "connected to" another element (e.g., a second element) with or without the term "operably" or "communicatively", it means that the element may be coupled to the other element directly (e.g., wired), wirelessly, or via a third element.

[0070] As used herein, the term "module" may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with other terms such as "logic," "logic block," "component," or "circuit." A "module" may be the smallest unit of a single integrated component adapted to perform one or more functions, or a portion thereof. For example, according to an embodiment, a "module" may be implemented in the form of an application specific integrated circuit (ASIC).

[0071] Various embodiments as set forth herein may be implemented as software (e.g., program 140) that includes one or more instructions stored in a storage medium (e.g., internal memory 136 or external memory 138) readable by a machine (e.g., electronic device 101). For example, a processor (e.g., processor 120) of a machine (e.g., electronic device 101) may call at least one of the one or more instructions stored in the storage medium and execute it. This allows the machine to be operated to perform at least one function according to at least one instruction called. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, the term "non-transitory" only means that the storage medium is a tangible device and does not include signals (e.g., electromagnetic waves), but the term does not distinguish between data being semi-permanently stored in the storage medium and data being temporarily stored in the storage medium.

[0072] According to an embodiment, the method according to various embodiments of the present disclosure may be included and provided in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disk read-only memory (CD-ROM)), or distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play Store TM), or distributed directly between two user devices (e.g., smartphones). If distributed online, at least a portion of the computer program product may be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as a memory of a manufacturer's server, a server of an application store, or a relay server.

[0073] According to various embodiments, each element (e.g., module or program) of the above-mentioned elements may include a single entity or multiple entities. According to various embodiments, one or more of the above-mentioned elements may be omitted, or one or more other elements may be added. Alternatively or additionally, multiple elements (e.g., module or program) may be integrated into a single element. In such a case, according to various embodiments, the integrated element may still perform one or more functions of each of the multiple elements in the same or similar manner as one or more functions of each of the multiple elements performed before integration by a corresponding one of the multiple elements. According to various embodiments, the operation performed by a module, program or another element may be performed sequentially, in parallel, repeatedly or heuristically, or one or more operations may be performed or omitted in different orders, or one or more other operations may be added.

[0074] Before describing various embodiments of the present disclosure, an electronic device 101 to which embodiments of the present disclosure can be applied is described.

[0075] Figure 2 2 is a block diagram 200 illustrating an electronic device 101 for supporting both traditional network communications and 5G network communications according to various embodiments.

[0076] Reference Figure 2 , the electronic device 101 may include a first communication processor 212, a second communication processor 214, a first RFIC 222, a second RFIC 224, a third RFIC 226, a fourth RFIC 228, a first radio frequency front end (RFFE) 232, a second RFFE 234, a first antenna module 242, a second antenna module 244, and an antenna 248. The electronic device 101 may also include a processor 120 and a memory 130.

[0077] The network 199 may include a first network 292 and a second network 294. According to another embodiment, the electronic device 101 may also include Figure 1 , and the network 199 may also include at least one other network. According to an embodiment, the first communication processor 212, the second communication processor 214, the first RFIC 222, the second RFIC 224, the fourth RFIC 228, the first RFFE 232, and the second RFFE 234 may configure at least a portion of the wireless communication module 192. According to another embodiment, the fourth RFIC 228 may be omitted or may be included as a part of the third RFIC 226.

[0078] The first communication processor 212 may support creation of a communication channel in a frequency band to be used for wireless communication with the first network 292 and legacy network communication through the created communication channel. According to various embodiments, the first network 292 may be a legacy network including a second generation (2G), 3G, 4G, or long term evolution (LTE) network.

[0079] The second communication processor 214 may support creation of a communication channel corresponding to a predetermined frequency band (e.g., about 6 GHz to about 60 GHz) among frequency bands to be used for wireless communication with the second network 294 and 5G network communication through the created communication channel. According to various embodiments, the second network 294 may be a 5G network defined in 3GPP.

[0080] In addition, according to an embodiment, the first communication processor 212 or the second communication processor 214 may support the creation of a communication channel corresponding to another predetermined frequency band (e.g., equal to or lower than 6 GHz) among the frequency bands to be used for wireless communication with the second network 294 and 5G network communication through the created communication channel. According to an embodiment, the first communication processor 212 and the second communication processor 214 may be implemented in a single chip or a single package. According to various embodiments, the first communication processor 212 or the second communication processor 214 may be implemented in a single chip or a single package together with the processor 120, the auxiliary processor 123, or the communication module 190.

[0081] In transmission, the first RFIC 222 may convert a baseband signal generated by the first communication processor 212 into a radio frequency (RF) signal from about 700 MHz to about 3 GHz used by the first network 292 (e.g., a legacy network). In reception, an RF signal may be acquired from the first network 292 (e.g., a legacy network) through an antenna (e.g., the first antenna module 242) and may be pre-processed by an RFFE (e.g., the first RFFE 232). The first RFIC 222 may convert the pre-processed RF signal into a baseband signal to be processed by the first communication processor 212.

[0082] In transmission, the second RFIC 224 may convert a baseband signal generated by the first communication processor 212 or the second communication processor 214 into an RF signal (hereinafter referred to as a 5GSub6 RF signal) in the Sub6 frequency band used by the second network 294 (e.g., a 5G network) (e.g., equal to or lower than about 6 GHz). In reception, a 5G Sub6 RF signal may be obtained from the second network 294 (e.g., a 5G network) through an antenna (e.g., a second antenna module 244) and may be pre-processed by an RFFE (e.g., a second RFFE 234). The second RFIC 224 may convert the pre-processed 5G Sub6 RF signal into a baseband signal to be processed by a corresponding communication processor among the first communication processor 212 or the second communication processor 214.

[0083] The third RFIC 226 may convert the baseband signal generated by the second communication processor 214 into an RF signal (hereinafter referred to as a 5G Above6 RF signal) in a 5G Above6 frequency band (e.g., from about 6 GHz to about 60 GHz) used by the second network 294 (e.g., a 5G network). Upon reception, the 5G Above6 RF signal may be acquired from the second network 294 (e.g., a 5G network) through an antenna (e.g., the antenna 248) and may be pre-processed by the third RFFE 236. The third RFIC 226 may convert the pre-processed 5G Above6 RF signal into a baseband signal to be processed by the second communication processor 214. According to an embodiment, the third RFFE 236 may be configured as a part of the third RFIC 226.

[0084] According to an embodiment, the electronic device 101 may include a fourth RFIC 228 that is separate from or as part of the third RFIC 226. In this case, the fourth RFIC 228 may convert the baseband signal generated by the second communication processor 214 into an RF signal (hereinafter referred to as an IF signal) in an intermediate frequency band (e.g., about 9 GHz to about 11 GHz), and then transmit the IF signal to the third RFIC 226. The third RFIC 226 may convert the IF signal into a 5G Above 6 RF signal. In reception, the 5G Above 6 RF signal may be received from the second network 294 (e.g., a 5G network) through an antenna (e.g., antenna 248) and converted into an IF signal by the third RFIC 226. The fourth RFIC 228 may convert the IF signal into a baseband signal to be processed by the second communication processor 214.

[0085] According to an embodiment, the first RFIC 222 and the second RFIC 224 may be implemented as at least a portion of a single chip or a single package. According to an embodiment, the first RFFE 232 and the second RFFE 234 may be implemented as at least a portion of a single chip or a single package. According to an embodiment, at least one of the first antenna module 242 and the second antenna module 244 may be omitted or combined with another antenna module to process RF signals in a plurality of corresponding frequency bands.

[0086] According to an embodiment, the third RFIC 226 and the antenna 248 may be arranged on the same substrate to configure the third antenna module 246. For example, the wireless communication module 192 or the processor 120 may be arranged on a first substrate (e.g., a main PCB). In this case, the third RFIC 226 may be arranged in a portion of the area (e.g., the bottom side) of the second substrate (e.g., a sub-PCB) separated from the first substrate, and the antenna 248 may be arranged in another portion of the area (e.g., the top side) to configure the third antenna module 246. By arranging the third RFIC 226 and the antenna 248 on the same substrate, the length of the transmission line between them can be reduced. This can reduce the loss (e.g., attenuation) of the signal in the high frequency band (e.g., about 6 GHz to about 60 GHz) used by the 5G network communication due to the transmission line. Therefore, the electronic device 101 can improve the quality or speed of communication with the second network 294 (e.g., 5G network).

[0087] According to an embodiment, the antenna 248 may be configured as an antenna array including a plurality of antenna elements that may be used for beamforming. In this case, the third RFIC 226 may include, for example, a plurality of phase shifters 238 corresponding to a plurality of antenna elements that are part of the third RFFE 236. In transmission, each of the plurality of phase shifters 238 may convert the phase of a 5G Above6 RF signal to be transmitted to the outside of an electronic device (e.g., a base station of a 5G network) through a corresponding antenna element. In reception, each of the plurality of phase shifters 238 may convert the phase of a 5GAbove6 RF signal received from the outside through a corresponding antenna element to the same phase or substantially the same phase. This enables transmission or reception between the electronic device 101 and the outside through beamforming.

[0088] The second network 294 (e.g., a 5G network) can operate independently of the first network 292 (e.g., a traditional network) (e.g., standalone (SA)) or by connecting to the first network 292 (e.g., non-standalone (NSA)). For example, in a 5G network, there may be only an access network (e.g., a 5G radio access network (RAN) or a next generation RAN (NG RAN)) without a core network (e.g., a next generation core network (NGC)). In this case, the electronic device 101 can access the access network of the 5G network and then access an external network (e.g., the Internet) under the control of the core network (e.g., the Evolved Packet Core (EPC)) of the traditional network. Protocol information for communicating with a traditional network (e.g., LTE protocol information) or protocol information for communicating with a 5G network (e.g., new radio (NR) protocol information) can be stored in the memory 130 and can be accessed by another element (e.g., the processor 120, the first communication processor 212, or the second communication processor 214).

[0089] Hereinafter, the 5G network technology described in the drawings and descriptions may refer to the standard provisions defined by the International Telecommunications Organization (ITU) or 3GPP (e.g., Technical Specification (TS) 23.501), and the MEC technology may refer to the standard provisions defined by the European Telecommunications Standards Institute (ETSI) (e.g., MEC 001 to MEC 016). The following description is made on the basis of MEC technology, but the same or similar principles can be applied to the fog computing technology defined in the openfog consortium.

[0090] Figure 3 An electronic device 101 and an external server 300 for supporting MEC-based services in a network environment according to various embodiments of the present disclosure are shown.

[0091] like Figure 3 As shown in Figure 3 The electronic device 101 may illustrate an example of a software architecture for a MEC authentication / authorization (AA) process and a MEC discovery process.

[0092] According to an embodiment, the electronic device 101 may include an application 310 (hereinafter referred to as a client application (App)) for an edge computing service (multi-access edge computing service) (hereinafter referred to as an MEC service), a service agent (agent) 320 (e.g., MSA) (hereinafter referred to as MSA 320) and a service enabler 330 (e.g., MSE) (hereinafter referred to as MSE 330). According to an embodiment, the electronic device 101 may include a network interface 340 (e.g., a protocol data unit (PDU) session for creating data transmission. Figure 1 or Figure 2The client application 310, the MSA 320, and the MSE 330 may be configured to be installed in the electronic device 101 as software or have a physical configuration. According to an embodiment, the MSA 320 and the MSE 330 may be configured as a processor (e.g., Figure 1 According to an embodiment, MSA 320 and MSE 330 may be separate hardware components that operate independently of processor 120. According to another embodiment, MSA 320 and MSE 340 may be software (e.g., Figure 1 For example, the MSA 320 and the MSE 340 in software form may be stored in a memory in the form of commands (or instructions) (e.g., Figure 1 or Figure 2 's memory 130), and the operations of MSA 320 and MSE 330 may be performed by processor 120.

[0093] According to an embodiment, the client application 310 may include a third-party application installed by a user in the electronic device 101. According to an embodiment, the client application 310 may be an application using an MEC service such as MEC or fog computing. According to an embodiment, the client application 310 may include an application using a differentiated service such as a free (e.g., free of charge (FOC)) service.

[0094] According to an embodiment, the client application 310 for MEC may be an application for the electronic device 101 to access the MEC application executed by the MEC host. According to an embodiment, the MEC application may be an application installed in the MEC host adjacent to the user and executed by it to communicate with the client application 310. According to an embodiment, the client application 310 may be authenticated by the MSA 320 (e.g., a service agent) used as a separate authentication client. According to an embodiment, the client application 310 may access the network through the network interface 340 on the basis of a unique PDU session (e.g., a MEC-dedicated PDU session) or access the MEC application through the DNS proxy function of the MSE 330 (e.g., a service enabler) on the basis of an existing PDU session (e.g., a default PDU session).

[0095] According to an embodiment, the client application 310 for the FOC service may be an application of the electronic device 101 to which the data FOC policy is applied. According to an embodiment, when the client application 310 is authenticated by the MSA 320 for performing FOC authentication, a routing rule for a corresponding unique identifier (UID) may be registered through a client application routing policy (CARP) or a UE routing policy (URSP), and traffic generated by the corresponding UID may be sent and received through a FOC dedicated PDU session. According to an embodiment, the URSP may indicate a routing (or configuration) policy of the electronic device 101 (e.g., a user terminal) defined in the 3GPP standard, and may be received from the AMF through a modem (or communication processor (CP)) of the electronic device 101 while being inserted into a non-access stratum (NAS) message. According to an embodiment, the CARP is a routing (or configuration) policy of the electronic device 101 defined in various embodiments, and, for example, may be received by an application layer (e.g., MSA 320 or MSE 330) of the electronic device 101 in an environment where the URSP of 3GPP is not available.

[0096] According to an embodiment, the MSA 320 (e.g., a service agent) may use an authentication / authorization (AA) server 380 (e.g., an authentication server) of the external server 300 to process an authentication process (e.g., an authentication / authorization (AA) process) related to the MEC service. For example, the MSA 320 may be used to transmit the received URSP rule and / or MEC access token to the MSE 330 as a result of the AA. According to an embodiment, the MSA 320 may be used to detect an application event (e.g., start or end) or transmit a unique event to the application. According to various embodiments, the MSA 320 of the electronic device 101 may include an AA client 325. According to an embodiment, the AA client 325 may be provided by a manufacturer (or manufacturer) or an operator (e.g., a service provider) that produces the electronic device 101. According to an embodiment, the MSA 320 may perform authentication / authorization on the basis of the subscriber identification information of the electronic device 101 through the AA client 325. The subscriber identification information may include, for example, a subscriber identity module (SIM), a universal SIM (USIM), an international mobile equipment identity (IMEI), or a universal public subscription identifier (GPSI). For example, the MSA 320 may be an application (or software) for providing authentication and authorization functions to use services (e.g., MSE services) of the MSE 330 by communicating with the AA server 380 based on subscriber identification information. According to an embodiment, for example, the MSE services may be collectively referred to as services such as Ultra Reliable and Low Latency Communication (URLLC) or MEC, FOC, MMS through the MSE 330.

[0097] According to an embodiment, when the MSA 320 is authenticated and authorized for MSE services through communication with the AA server 380, the MSA 320 may use the MSE application programming interface (API) for the authorized service type to activate / deactivate (enable / disable) the MSE 330, register rules (e.g., ApnSettings) and UIDs that can be used for client applications for each service type, and make a request to configure routing. According to an embodiment, the MSE API may include an API provided from the electronic device 101 to a higher application layer for enabling / disabling each MSE service type and routing rule settings for each UID. According to an embodiment, the MSE API may include an API for configuring at least one policy (such as a policy for the MEC discovery process or a context monitoring policy). According to an embodiment, the client application 310 may access the corresponding service (e.g., MEC or FOC) through an authentication and authorization process with the MSA 320.

[0098] According to an embodiment, when the MSA 320 is implemented by an operator (e.g., a service provider), for example, when the operator directly develops an MSA (e.g., an operator MSA) that uses an MSE service, the MSA 320 may directly perform an authentication and authorization process for the use of the MSE service through the AA server 380. According to an embodiment, the MSA 320 may receive application-specific routing rules (e.g., data network name (DNN) (in LTE=APN) information when a dedicated PDU session is used) from the AA server 380 during the authentication and authorization process. According to an embodiment, in order to use the MSE API, the MSA 320 should be able to perform an authentication and authorization process between the MSA 320 and the electronic device 101. For example, when the MSA 320 is pre-installed in the electronic device 101, the MSA may be authenticated by the platform key through the signature of the MSA application APK. According to an embodiment, when the electronic device 101 includes (or supports) an authentication module, the authorization of the MSE API may be obtained through a separate authentication process using the authentication module within the electronic device 101 after the MSA 320 is installed. According to an embodiment, when the MSE service authentication process is completed, the MSA 320 may call the MSE API to generate / end a PDU session and configure a routing rule based on the received policy.

[0099] According to an embodiment, when configuring a data path for an application program for MEC, the electronic device 101 may configure the data path (e.g., path path or Path ) to stop by at least one of the various entities of the MSE 330 (e.g., MEC enabling layer (MEL) 331, URSP handling layer (UHL) 333, and domain name system (DNS) handling layer (DHL) 335). According to an embodiment, when configuring a data path for an application for MEC, the electronic device 101 can use a default PDU session (e.g., path ) or using separate dedicated PDU sessions (e.g., path or Path According to an embodiment, when a separate dedicated PDU session is used, the path may be determined based on whether the MEC discovery process is performed by the MEL 331 of the MSE 330. or Path data path.

[0100] According to an embodiment, the MSA 320 may configure (eg, configure the path of the service as the path) by sending a request directly to the UHL 333 of the MSE 330 without stopping at the MEL 331 of the MSE 330. ) dedicated PDU session. For example, when the electronic device 101 executes a sponsored application, if a reservation is made in advance with a specific server or network, the MSA 320 can send a request to the UHL 333 and provide the corresponding service through the dedicated PDU session. According to an embodiment, the MSA 320 can also generate or receive separate information for identifying the service from the external service, and then provide it to the UHL 333.

[0101] According to various embodiments, the electronic device 101 may include an MSE 330 (eg, service enabler) in a lower layer of the MSA 320 .

[0102] According to an embodiment, the MSE 330 may provide the MSA 320 with an MSE API so that the client application 310 may use the MEC service (or MSE service) through the MSA 320, and thus may configure a routing table for each application for the PDU session used. According to an embodiment, the MSE 330 may configure a routing table for a PDU session path to be used for each application ID or each URI, and store it in a memory (e.g., Figure 1 or Figure 2memory 130). According to an embodiment, the MSE330 may configure at least one of an application ID and a URI as a target to configure a PDU session path. The URI may include a domain name or an IP address form. For example, the PDU session path for each application ID may be configured as, for example, “AppID1: PDU session 1, AppID 2: PDU session 1, AppID 3: PDU session 2”. For example, the PDU session path for each URI may be configured as “URI 1: PDU session 1, URI 2: PDU session 2”. For example, the PDU session path for each application ID and each URI may be configured as, for example, “AppID 1&URI 1: PDU session 3, AppID 2&URI 1: PDU session 1”.

[0103] According to an embodiment, MEC services may be collectively referred to as services related to processes required to use MEC applications (or mobile edge (ME) applications), services provided by MEC applications, and information provided to MEC applications. According to an embodiment, MSE 330 may support additional functions such as MEC service discovery, location verification, route selection, performance verification, or mobility support for MEC services.

[0104] According to various embodiments, in a state where the MSE 330 is connected to at least one MEC host (or MEC application), the MSE 330 may configure a dedicated PDU session or a default PDU session to provide a unique service. According to an embodiment, the information required to configure the dedicated PDU session or the default PDU session may be information received by the modem (or communication processor (CP)) of the electronic device 101 from the AMF / PCF server 390 through the non-access layer (NAS).

[0105] According to an embodiment, the MSE 330 may include a MEL 331 , a UHL 333 , and a DHL 335 .

[0106] According to an embodiment, MEL 331 may perform tasks required to use MEC services among MSE services. For example, MEL 331 may process operations such as MEC service registration, MEC service discovery, route selection (e.g., DNN processing), performance prediction, location services, and / or mobility processing.

[0107] According to an embodiment, in the MEC service registration, the joining of the electronic device 101 can be authenticated by the MMP server 370 (or LCM proxy server) or the MEC solution provider server based on the USIM or account (e.g., login) information, and a token (e.g., cookie) suitable for the MEC service authorization level can be received and stored in the memory (e.g., Figure 1 or Figure 2 The corresponding token may then be used to make a request for MEC services during the validity period of the token.

[0108] According to an embodiment, in MEC service discovery, when the electronic device 101 enters an area where MEC services may be provided (e.g., accessing a unique cell ID or entering a LADN area), the MEL 331 may detect entries, receive at least one of the app lists (e.g., MEC App (name) lists) that can be used in the corresponding area or domain name (e.g., a domain name for each MEC application), and perform various functions according to user settings. For example, the MEL 331 may provide available MEC application notifications, DNS proxy, and / or MEC application activation according to user settings. According to an embodiment, the MEL 331 may provide notifications for available MEC applications. For example, currently available MEC applications may be displayed on a notification window or may be displayed by an application icon (e.g., an app icon). According to an embodiment, a notification of the installation of a client application corresponding to the corresponding MEC application may be displayed on the electronic device 101.

[0109] According to an embodiment, MEL 331 may provide a DNS proxy. For example, when a DNS query for a corresponding domain name is generated when a client application accesses an MEC application, if at least one of the corresponding application name and the DNS query matches the MEC app list, MEL 331 may send a corresponding DNS query to a DNS server for MEC, receive an access IP address of the corresponding MEC application, and return the access IP address to the client application 310. According to an embodiment, the corresponding IP address may be stored in a DNS cache for MEC within the electronic device 101, for example, during a valid period. MEC DNS resolution for domain names in the MEC app list may be performed by MEL 331 by itself separately from the DNS query of the client application, and may be stored in a DNS cache for MEC.

[0110] According to an embodiment, the MEL 331 may provide MEC application activation. For example, when an MEC client application installed in the electronic device 101 is being used or expected to be used, a request for MEC application activation (e.g., instance generation (instantiation)) that interacts with it may be made. According to an embodiment, when the corresponding MEC application is not installed in the MEC host in the access area of ​​the electronic device 101, a request for installation (including a data packet URI) may be made.

[0111] According to an embodiment, in route selection (e.g., DNN processing), when it is desired to use a dedicated PDU session for a MEC service or MEC application instead of a default PDU session, a routing rule for the UID of the client application can be configured. According to an embodiment, the MSE 330 can receive dedicated DNN information for a MEC service or MEC application from a predefined configuration file or the AA server 380, and make a request to generate a MEC dedicated PDU session by using a UHL API (not shown).

[0112] According to an embodiment, the performance prediction quantity may include, for example, pre-performance testing of multiple candidate MEC hosts by MEL 331. For example, MEL 331 may select the optimal MEC host through pre-performance (e.g., data packet Internet Explorer (ping) detection or bandwidth estimation) testing.

[0113] According to an embodiment, the location service may include, for example, providing a service based on an area where the electronic device 101 is located. According to an embodiment, the MEL 331 may provide information about service availability (or location accuracy) at a corresponding location of the electronic device 101. For example, the information about service availability may include, for example, information such as location confirmation, location not found, or location spoofing.

[0114] According to an embodiment, the mobility processing may provide, for example, processing of service continuity in an area where a handover is generated. For example, the MEL 331 may process a handover from an MEC host to another MEC host or from an MEC host to a remote host.

[0115] According to an embodiment, MEL 331 can control the discovery of MEC applications of the MEC host and identify the service type by communicating with the MMP server. For example, MEL 331 can identify the service through a predefined MSE API call. In another example, MEL 331 can identify the service according to a policy received from a service provider server (e.g., AA server 380) or MMP server 370.

[0116] According to an embodiment, in the case where the service uses, for example, a default PDU session based on the identification result of the service, the MEL 331 may configure a path (for example, a path ) and accordingly provide MEC services through MEL 331 and DHL 335. According to an embodiment, in the data path of the application for MEC In the case of, MEL 331 can be configured to provide the service through a default PDU session. According to another embodiment, in the case where the service uses, for example, a dedicated PDU session based on the identification result of the service, MEL 331 can configure a path of the service (for example, a path ), and provide corresponding services through MEL 331, UHL 333 and DHL 335. According to an embodiment, in the data path of the application for MEC In this case, MEL 331 may be configured to provide services through a dedicated PDU session sending a request to UHL 333. According to an embodiment, in order to identify the above-mentioned various services, MSA 320 may also provide separate information to MEL 331 or MEL 331 may receive (or obtain) relevant information from MMP server 370.

[0117] According to an embodiment, the UHL 333 may make a request for a dedicated PDU session for each service type according to an API call, and perform binding to become a dedicated PDU session configured for a corresponding application.

[0118] According to an embodiment, DHL 335 may support DNS pre-resolution or DNS proxy functions in third-party applications. For example, when a DNS query for a client application of MEC to access a unique service is generated in a state where a data connection is made through an existing default PDU session, the DNS proxy may hook the DNS query through the domain name of MEC and transmit the query to the DNS server or look up and return the corresponding MEC domain IP address in the DNS cache. Therefore, third-party applications can provide MEC services without any modification to the separate software and without any separate traffic filtering (or steering) work of the operator.

[0119] According to an embodiment, the AA server 380 may provide authentication and authorization for using MSE services. According to an embodiment, the MSA 320 of the electronic device 101 may receive authorization for each service type through the AA server 380 according to the authentication and subscriber information. According to an embodiment, the MSA 320 may authenticate the MSE service available client application. According to an embodiment, for example, the authentication process between the AA server 380 and the electronic device 101 may use a default PDU session connected to the current Internet through a communication such as LTE or Wi-Fi without a separate PDU session.

[0120] According to an embodiment, the MMP server 370 may be a proxy server that communicates with the electronic device 101 for authentication of the electronic device 101 or control of the MEC. According to an embodiment, the MMP server 370 may exchange request / response messages on the basis of, for example, a hypertext transfer protocol (HTTP). According to an embodiment, when the electronic device 101 may perform direct communication with the AA server 380 or the MEC solution providing server, the LCM agent may not be required. For example, when the server API provided by the LCM agent is used, the authentication request message of the MSA 320 may be forwarded to the AA server 380 for authentication, and the MEC control message may be transmitted to the MEC solution providing server. In various embodiments, the entitlement server or the interlocking API between the MMP server 370 and the MSA 320 may be omitted, and the information required for the AA process (e.g., authentication and authorization process) may be received in advance.

[0121] According to an embodiment, when MEC is supported in the 5G New Radio (NR) standard, the Access and Mobility Function (AMF) / Policy Control Function (PCF) server 390 may register MMP information and URPS rules in the PCF and receive corresponding information from the AMF through NAS signaling.

[0122] As described above, according to various embodiments, the MSA 320 may perform authentication by communicating with the AA server 380, make a request for desired information (e.g., authentication and authorization), and receive and obtain the requested information from the AA server 380. According to various embodiments, the MSE 330 may make a request for desired information by communicating with the MMP server 370, and receive and obtain the requested information from the MMP server 370. For example, the MSE 330 may obtain a MEC app list or perform a MEC service discovery process and configure a connection with at least one unique MEC host (or MEC application) by communicating with the MMP server 370.

[0123] According to various embodiments, as in reference Figure 3 As described in the section, when a data path for an application for MEC is configured on the basis of an electronic device 101 including an MSA 320 and an MSE 330, the following various service scenarios can be provided.

[0124] 1. The first data path (eg, path ) scenarios (e.g., MSE on a single PDU session)

[0125] According to an embodiment, a first data path (eg, path ) scenario may indicate a scenario for making a connection to an MEC application by using a default PDU session (or public data network (PDN) connection) for an existing Internet data for a client application. According to an embodiment, the MEL 331 may perform an MEC discovery process, make a request for execution and connection of a MEC application to a MEC host close to the electronic device 101, and receive a URI of the corresponding MEC application. When the client application 310 makes a request for access to the corresponding MEC application, access may be performed through the MEC application IP address (obtained by DNS resolution of the corresponding URI). According to an embodiment, since a separate PDU session for MEC services is not used in a scenario of the first data path (e.g., an MSE on a single PDU session), the UHL 333 that controls the URSP rules may not intervene in the operation.

[0126] 2. Second data path (e.g., path ) scenarios (e.g. MSE over multiple PDU sessions with MEL)

[0127] According to an embodiment, a second data path (eg, path ) scenario may indicate a scenario in which a connection to an MEC application is made by generating a separate MEC dedicated PDU session and a default PDU session (or PDN connection) of an existing Internet for a client application. According to an embodiment, the generation of the MEC dedicated PDU session may comply with a service provider (e.g., a mobile network operator (MNO) or an MMP server 370) policy, and the MSA 320 or the authenticated client application 310 may generate it through the UHL 333 using an MSE API. According to an embodiment, with respect to the MEC dedicated PDU session, one or more PDU sessions and the default PDU session may be always open, and may be dynamically generated or released by a request from the MEL 331 at a necessary unique time point. According to an embodiment, the UHL 333 of the MSE 330 may support routing of traffic for a corresponding client application (or UID) or access UR to the MEC dedicated PDU session according to predefined rules (e.g., CARP or URSP rules), or routing rules received from an external server (e.g., an MMP server 370, an AA server 380, or an AMF / PCF server 390).

[0128] 3. The third data path (eg, path ) scenarios (e.g. MSE on multiple PDU sessions without MEL)

[0129] According to an embodiment, the scenario of the third data path may indicate a scenario in which only a dedicated PDU session for a unique service without any function of the MEL 331 is generated and used. According to an embodiment, a separate dedicated PDU session may be generated using the MSE API in the MSA 320 or the authenticated client application 310, an application (e.g., UID) rule using the corresponding PDU session may be registered, and traffic of the corresponding application may be routed to the corresponding PDU session. According to an embodiment, a scenario such as the third data path (e.g., MSE on multiple PDU sessions without MEL) may be used in various types of services that require a dedicated PDU session as well as MEC (e.g., FOC, MMS, or URLLC).

[0130] According to various embodiments of the present disclosure, the electronic device 101 may include a network interface 420 and a processor 120, and the processor 120 may obtain information about an application that can be provided by at least one external server from within a base station or through a base station that can be connected using a network interface, select an external server that includes an application corresponding to a predetermined condition based on the information about the application, and transmit data to the selected external server.

[0131] According to various embodiments, the processor 120 may send a request message requesting information about an application to at least one external server, receive a response message including information about the application from at least one external server, and obtain the information of the application from the response message.

[0132] According to various embodiments, the processor 120 may specify conditions for information about an application in a request message and transmit it to at least one external server.

[0133] According to various embodiments, the request message may include at least one of clientappName, locationInfo, deviceType, serviceType, contextType, and URI Request.

[0134] According to various embodiments, the response message may include at least one of referenceURI, clientAppName, clientAppPackageURL, uriTTL, uriLOC, carpRule, DNN, S-NSSAI, accessType, sessionType, mptcp, and fqdnList.

[0135] According to various embodiments of the present disclosure, the electronic device 101 may include a network interface 420 and a processor 120, and the processor 120 may obtain an app list of applications that can be served from a predetermined external server based on a discovery strategy, obtain information about applications to be accessed that are associated with a client application of the electronic device based on the app list from the predetermined external server, determine a host for data transmission based on the obtained information, and transmit data to the host.

[0136] According to various embodiments, the processor 120 may include a service agent for performing operations related to authentication and authorization through communication with an external server and a service enabler for acquiring an app list and performing operations related to discovery through communication with an external server.

[0137] According to various embodiments, the processor 120 may activate the service enabler through an API between the service agent and the service enabler, and perform a discovery process with an external server through the service enabler.

[0138] According to various embodiments, the processor 120 may configure a discovery policy included in a service enabler through a service agent, and the discovery policy may include a client application name (clientAppName) and a discovery policy (discoveryPolicy), and the discovery policy (discoveryPolicy) may include at least one of information about whether to use a dynamic DNN (dynamicDnn), location information (locationInfo), a device type (deviceType), a service type (serviceType), and a context type (contextType).

[0139] According to various embodiments, the processor 120 may activate the service enabler based on the discovery policy received from the service agent, and make a request for a list of apps satisfying a predetermined condition to the proxy server through the service enabler according to the discovery policy.

[0140] According to various embodiments, when there is no application associated with the client application in the app list, the processor 120 can make a request for the URI of the application to the proxy server through the service enabler, and when there is an application associated with the client application in the app list, the application name of the application can be inserted and transmitted to the proxy server.

[0141] According to various embodiments, when there is no application in the proxy server, the processor 120 may acquire an application data packet URI for downloading or installing the application from the proxy server.

[0142] According to various embodiments, the processor 120 may transmit a DNS query through a URI for an application through a service enabler, and store an IP address acquired in response to the DNS as a response to the DNS query in a local DNS cache.

[0143] According to various embodiments, when receiving a candidate IP list of multiple hosts from an external server, the processor 120 may be configured to select a host based on additional information, and the additional information may include information about the host location, current user location, user speed, or host performance.

[0144] According to various embodiments of the present disclosure, the electronic device 101 may include a network interface 420 and a processor 120, and the processor 120 may obtain an app list of applications that can be served from a predetermined external server based on a discovery strategy, obtain information related to an application to be accessed and associated with the client application from a predetermined external server based on an event related to the creation of a context by the client application, select a host for data transmission based on the obtained information, and transmit data to the host.

[0145] According to various embodiments, the event related to the creation of the event may include at least one of the execution of the client application, the request for the creation of the context by the client application, or the generation of a DNS query by the client application.

[0146] According to various embodiments, the discovery policy may include a client application name (clientAppName) and a discovery policy (discoveryPolicy), and the discovery policy (discoveryPolicy) may include at least one of information about whether to use a dynamic DNN (dynamicDnn), location information (locationInfo), a device type (deviceType), a service type (serviceType), and a context type (contextType).

[0147] According to various embodiments, the processor 120 may make a request to the proxy server for a list of apps that meet a predetermined condition according to a discovery policy.

[0148] According to various embodiments, when there is no application associated with the client application in the app list, the processor 120 may make a request for the URI of the application to the proxy server, and when there is an application associated with the client application in the app list, insert the application name of the application and transmit it to the proxy server. When there is no application in the proxy server, the processor 120 may obtain the application data packet URI for downloading or installing the application from the proxy server.

[0149] According to various embodiments, the processor 120 may transmit a DNS query through a URI for an application program and store an IP address obtained in response to the DNS as a response to the DNS query in a local DNS cache.

[0150] Hereinafter, a method of operating the electronic device 101 according to various embodiments is described. For example, hereafter, various embodiments of receiving authentication and authorization (e.g., authentication / authorization (AA)) and policies (e.g., app routing policies, discovery policies, or monitoring policies) according to various embodiments are described on the basis of the electronic device 101 including the MSA 320 and the MSE 330 and performing route configuration based on the received policies and the MEC discovery process.

[0151] The operations performed by the electronic device 101 described below may be performed by at least one processor of the electronic device 101 (e.g., at least one processor including a processing circuit, such as Figure 1 According to an embodiment, the operations performed by the electronic device 101 may be stored in a memory (e.g., Figure 1 memory 130) and when executed, cause the processor 120 to execute through the instructions.

[0152] According to various embodiments, the electronic device 101 may perform wireless communication through an access node (not shown) disposed between the MEC management agent (MMP) server 370 and the electronic device 101 .

[0153] For example, for an edge computing service (e.g., an MEC service), a network entity that interacts with an MEC service module (not shown) including a service agent 320 (e.g., a multi-access service agent (MSA)) and a service enabler 330 (e.g., a multi-access service enabler (MSE)) within the electronic device 101 may be indicated.

[0154] According to various embodiments, Figure 3In the example of , in the control path between the service agent (e.g., MSA) 320 and the service enabler 330 (e.g., MSE) and the MMP server 370, authentication, authorization, and discovery processes may be performed. According to an embodiment, after the discovery process, MEC data services may be provided through a data path (e.g., MEC user plane) between the application (e.g., the first App and the second App) of the electronic device 101 and the MEC application (e.g., the first MEC App and the second ME App—not shown) connected to the MMP server 370. Although Figure 3 Not shown, through a Domain Name System (DNS) query / response data path, the electronic device 101 may perform data communication with a DNS server.

[0155] According to an embodiment, the MMP server 370 may provide a user application program interface (see: ETSI MEC 016 standard) for an edge computing system (e.g., MEC system) to a user equipment (UE) (e.g., electronic device 101). For example, the electronic device 101 may make a request for information about applications that can be provided by the MEC system (e.g., a list of available applications) and transmit an execution request (e.g., context creation) to the MMP server 370, as well as stop requests for specific applications to the MEC system (e.g., context termination). In another example, the MMP server 370 may manage the life cycle of applications installed in the MEC system. For example, the MMP server 370 may receive a request from the electronic device 101, send the received request to the MEC system, and manage the life cycle of applications installed in the MEC system.

[0156] According to an embodiment, the MEC service module may include a service agent 320 (e.g., MSA) and a service enabler 330 (e.g., MSE). According to various embodiments, the MEC service module may receive and process authentication and authorization (e.g., authentication / authorization (AA)) and policies (e.g., application routing policies, discovery policies (or monitoring policies)) (e.g., a list of information to be monitored). According to an embodiment, the MEC service module may receive authentication / authorization (AA) and policies (e.g., a list of information to be monitored) through the service agent 320 (e.g., MSA) and perform route configuration based on the policies received through the service enabler 330 (e.g., MSE) and the MEC discovery process.

[0157] According to various embodiments, the MEC service module may operate to allow at least one of the entities within the MEC service module (e.g., the service agent (MSA) 320 or the service enabler (MSE) 330) to monitor the MEC discovery condition and transmit the result of monitoring by the corresponding entity to the service enabler (MSE) 330. According to an embodiment, the MEC service module may obtain AA and discovery-related policies through the service agent (MSA) 320. According to an embodiment, when the service agent 320 performs monitoring, if the MEC discovery condition is monitored by the service agent 320 and the MEC discovery condition is satisfied, the service agent may transmit an MEC discovery request to the service enabler 330 and perform an MEC discovery process through the service enabler 330. According to another embodiment, when the service enabler 330 performs monitoring, the service agent 320 may transmit a policy to the service enabler 330, and the service enabler 330 may monitor the MEC discovery condition according to the transmitted policy, and if the condition is satisfied, perform an MEC discovery process.

[0158] According to an embodiment, the service agent 320 may monitor context information of the electronic device 101. For example, the context information may be information about an application supporting MEC-based data transmission among applications installed in the electronic device 101, information related to the mobility of the electronic device 101, application life cycle information, information related to the state of the electronic device 101, information acquired by a sensor, and at least one of network performance. The information related to the mobility of the electronic device 101 may include at least one of information indicating the movement of the electronic device 101, information related to a change in a base station connected to the electronic device 101, and information related to whether the electronic device 101 enters a predetermined area. The predetermined area may be at least one of a local area data network (LADN), a tracking area, a cell of a base station, an area where a handover between base stations is generated, or an area determined by a location-based service (e.g., a location measurement technology based on cellular, satellite, and wireless fidelity (Wi-Fi)). The application life cycle information may indicate, for example, a state (e.g., a life cycle) of an application having a series of cycles. For example, the information about the state of the electronic device 101 may be a display (e.g., Figure 1 display device 160), the on / off state of the battery (e.g., Figure 1 battery 189), memory (e.g., Figure 1 130), received signal strength, timeout information, and CPU (e.g., Figure 1 For example, the information acquired by the sensor may be obtained by Figure 1For example, the network performance may be at least one of a frequency bandwidth and a latency of a network to which the electronic device 101 is connected. The service agent 320 according to various embodiments is described in detail with reference to the following drawings.

[0159] According to an embodiment, the service enabler 330 may manage (or process) MEC-based data transmission of the application based on the monitored context information.

[0160] For example, when an event related to the mobility of the electronic device 101 is detected without any separate requests for information from multiple applications to the MMP server 370, the service enabler 330 according to various embodiments can reduce the load on the electronic device 101 by making a request to the MMP server 370 for or receiving information related to an application (e.g., a MEC application) that can be provided by the MEC system.

[0161] In another example, the service enabler 330 may determine whether at least one of the MEC application or the application included in the electronic device 101 satisfies a predetermined condition that MEC-based data transmission can be performed, and notifies at least one application of the performance of MEC-based data transmission, so that the corresponding application performs data transmission. When at least one application that satisfies the predetermined condition is not installed in the electronic device 101, the service enabler 330 may cause the application layer 310 and / or the architecture (e.g., the middleware 144 and / or the operating system 142) to install the application. For example, according to a request from the application layer 310, a new application may be installed in the electronic device 101. In various embodiments, the electronic device 101 may receive (or obtain) information about the new application (e.g., URI, IP address, or application name) from the MEC system.

[0162] In another example, when a predetermined condition related to lifecycle synchronization (hereinafter referred to as the second condition) is detected, the service enabler 330 may make a request for lifecycle synchronization to the MMP server 370 (e.g., LCM proxy server) or the edge server (or MEC server) to reduce the resource consumption of the edge server. For example, the service enabler 330 may notify the MMP server 370 whether the application is used. According to an embodiment, the MEC application may perform operations (e.g., data transmission) only when the application is being used, and the MEC application may stop the operation (e.g., data transmission) when the application is not in use (e.g., at least one of the screen off, client application background state change, and user movement speed being higher than or equal to a predetermined speed). According to an embodiment, the service enabler 330 may notify the MMP server 370 whether the application as described above is used, thereby efficiently managing the resources of the MEC host (or edge server). According to an embodiment, for unused applications, the resource allocation of the MEC application is released, so that the resource consumption of the MEC host can be reduced.

[0163] In another example, unlike a method of separately performing an authentication process for MEC-based data transmission through multiple applications, the service enabler 330 can reduce network load by performing an authentication process for the electronic device 101 together with the MMP server 370 (or edge server).

[0164] Figure 4 An example of an authentication process according to various embodiments of the present disclosure is shown.

[0165] like Figure 4 As shown, the electronic device 101 may include an MSA (or service agent) 320 (eg, including an AA client 325) and an MSE (or service enabler) 330 (eg, including an MEL 331 and an UHL 333).

[0166] Reference Figure 4 In operation 401, the MSA 320 of the electronic device 101 may transmit a message (e.g., a first request message) for an authentication (e.g., first authentication) request to the AA server 380 based on at least one authentication scheme (e.g., first authentication). According to an embodiment, the MSA 320 may make a request for authentication with the AA server 380 by using an application layer AKA scheme based on a general public subscription identifier (GPSI), an ID / password-based login scheme, or a GBA scheme.

[0167] In operation 403, the MSA 320 may perform authentication with the AA server 380. According to an embodiment, the MSA 320 may perform GPSI-based user authentication with the AA server 380.

[0168] When receiving the authentication request from the electronic device 101, the AA server 380 may perform authentication with the electronic device 101, and when the authentication is completed (e.g., the authentication process is completed), in operation 405, authentication information (e.g., first authentication information) is provided (or sent) according to the authentication result of the electronic device 101 (e.g., MSA 320). According to an embodiment, the authentication information may include, for example, MMP related information (hereinafter referred to as MMP Info) and an authorization code (hereinafter referred to as Auth code). According to an embodiment, the MMP server 370 may also include additional (or selective) required information as well as the above information (e.g., ID_token for MEC data service in the authentication information, and at least one of CARP and URSP rules), and provide authentication information.

[0169] According to an embodiment, for example, MMP Info may include information related to accessing the MMP server 370 (e.g., MMP access address). For example, MMP Info may include address information (e.g., uniform resource identifier (URI) or IP address) of a new MMP server 370 to be accessed and information related to the valid corresponding address information and / or the location of the corresponding address information. According to an embodiment, for example, the Auth code may include a code (e.g., based on QAuth2.0) that requires a request for an access token (e.g., MAT or MEC access token) to be made from the MMP server 370. According to an embodiment, for example, the CARP or URSP rule may include relevant information (e.g., DNN) for PDU session establishment, information related to an application (or application group) that can be used for each DNN, a list of DNNs that can be configured thereafter, or a maximum number of DNNs that can be configured.

[0170] When the authentication process with the AA server 380 is completed, the MSA 320 may perform a policy update (e.g., PDU session establishment) with the MSE 330 in operation 407. According to an embodiment, the MSA 320 may perform the PDU session establishment according to the CARP rule or the URSP rule (e.g., DNN). For example, the MSA 320 may identify a policy indicating whether to perform the PDU session establishment according to the CARP or URSP rule, and transmit a PDU session establishment request to the MSE 330 through the MSE API according to the CARP rule or the URSP rule. The MSE 330 may perform the PDU session establishment in response to the PDU session establishment request from the MSA 320. According to an embodiment, the MSA 320 may change the default PDU session or otherwise create a new dedicated PDU session.

[0171] According to an embodiment, for example, when the MSA 320 receives the CARP or URSP rule from the AA server 380, the operation of performing the policy update by the MSA 320 and the MSE 330 in operation 407 may be performed. According to an embodiment, when the CARP or URSP rule is not provided from the AA server 380, the MSA 320 may not perform the policy update with the MSE 330. According to another embodiment, even if the CARP or URSP rule is provided from the AA server 380, the MSA 320 may not perform the policy update on a self-determined basis or through information exchange with the MSE 330.

[0172] After the authentication is completed (or after performing policy update or omitting policy update with the MSE 330), the MSA 320 may transmit a message (e.g., a second message) for an authorization (e.g., a second authorization) request to the MMP server 370 in operation 409. According to an embodiment, the MSA 320 may make a request for authentication to the MMP server 370 based on the authentication information (e.g., including an Auth code or another ID_token) acquired from the AA server 380.

[0173] In operation 411, the MSA 320 may perform authentication (eg, authorization process) with the AA server 380 through the MMP server 370. According to an embodiment, the MSA 320 may perform service authorization with the AA server 380 based on an Auth code.

[0174] In operation 413, in response to the authentication request (e.g., the second request message) from the MSA 320, the MMP server 370 may provide (or transmit) authentication information (e.g., the second authentication information) to the electronic device 101 (e.g., the MSA 320) according to the authentication result. According to an embodiment, the authentication information may include, for example, an access token (e.g., a MAT or MEC access token) and MMPInfo. According to an embodiment, the MMP server 370 may transmit a response including an access token to the MSA 320 while the authentication of the MSA 320 is being performed or after the authentication of the MSA 320 is performed.

[0175] In operation 415, the MSA 320 may activate the MSE 330. According to an embodiment, when the MSA 320 receives authentication information (e.g., access token (MAT)) according to the authentication result from the MMP server 370 while performing authentication with the AA server 380 or after performing authentication, the MSA 320 may send the received authentication information (e.g., access token (MAT)) to the MSE 330 to activate the MSE 330. According to an embodiment, the MSA 320 may send at least one additional information such as an access address (e.g., URI or IP address) of a new MMP server 370 to be accessed, a DNS server address, or a DNN to be used to perform the MEC discovery process, together with the authentication information (e.g., authentication token (MAT)) to the MSE 330. According to an embodiment, the MSA 320 may activate (enable) the MSE 330 on the basis of the received access token and / or other additional information. According to an embodiment, for example, when MSA 320 performs authentication (e.g., authorization) with the MMP server 370, MSA 320 can receive an access token (e.g., MAT) as an authentication result from the MMP server 370, call enableMecEnablingLayer(true, MMPInfo, MAT) of the MSE API, and send MMP access information (MMP Info) and the access token (MAT) to the MSE 330.

[0176] In operation 417, the MSE 330 may receive authentication information (e.g., MAT) and / or other additional information (e.g., DNN to be used, DNS server address, or MMP Info) and perform an MEC discovery process based at least on the authentication information and / or the additional information. According to an embodiment, the MSE 330 may perform an MEC discovery process after accessing the corresponding MMP server 370 using MMP Info and MAT.

[0177] Although not in Figure 4, but according to another embodiment, the MSE 330 may perform authentication (e.g., service authorization of operation 411) with the MMP server 370. According to an embodiment, when the MSE 330 performs authentication (e.g., authorization) with the MMP server 370, the MSA 320 that completes the authentication may first receive the MMP Info, Auth Code, and / or other additional information (e.g., identification token (ID_token)) from the MMP server 370, call enableMecEnablingLayer(true, MMP Info, Auth Code, [ID-Token]) of the MSE API to activate the MSE 330, and send it to the MSE 330. The MSE 330 may perform authorization directly with the MMP server 370 based on the information received from the MSA 320 and receive (or obtain) the MAT based on the result thereof. For example, with Figure 4 Compared with the operation of the electronic device 101, the entity that performs the service authentication process for authorization in the internal configuration of the electronic device 101 can be divided into the MSA 320 and the MSE 330.

[0178] Figure 5 An example of an authentication process according to various embodiments of the present disclosure is shown.

[0179] like Figure 5 As shown, Figure 5 An example of a signal flow for an authentication process (e.g., scenario A related to authentication / authorization (AA) and policy update) according to various embodiments is shown. For example, Figure 5 An example of an MEC service authentication flow for scenario A in the authentication process according to various embodiments is shown, and may include operations according to embodiments of user authentication (or subscriber authentication) (e.g., operation 510) and operations according to embodiments of MEC service authorization (e.g., 520). According to an embodiment, scenario A for MEC AA and policy update may indicate the following: Figure 5 An example of a scenario is shown in which MEC service authorization (eg, operation 520 ) is performed after user authentication (eg, operation 510 ).

[0180] Reference Figure 5 In operation 501, the MSA 320 of the electronic device 101 may transmit a message for an authentication request to the authority server 500.

[0181] In operation 503, the authority server 500 may determine an authentication method. According to an embodiment, the authority server 500 may determine an authentication method corresponding to an authentication request of the electronic device 101 in at least one predetermined authentication method. According to an embodiment, for example, at least one authentication method may include an application layer AKA or a login (e.g., ID / password) type of authentication using GPSI. According to an embodiment, the MSA 320 may make a request for an authorization code while transmitting subscriber identification information (or terminal identification information) (e.g., GPSI or IMSI) to the authority server 500. According to an embodiment, the MSA 320 and the authority server 500 may perform user authentication by application layer AKA or login method as in operation 510.

[0182] According to an embodiment, in operation 505, the MSA 320 may perform authentication (e.g., MEC subscriber authentication) with the AA server 380 through the authority server 500 on the basis of the application layer AKA method and obtain an authentication response including authentication information according to the authentication result from the AA server 380. According to another embodiment, in operation 507, the MSA 320 may perform an authentication process with the authority server 500 on the basis of an ID / password-based login method, and obtain an authentication response including authentication information according to the authentication result from the authority server 500 based on a successful login in the authority server 500 in operation 509.

[0183] In operation 511, the MSA 320 may receive an authentication response corresponding to the authentication request. For example, in operation 511, the MSA 320 may obtain authentication information (e.g., MMP Info, Auth code, ID_token, CARP rule, or URSP rule) according to the authentication result from the authority server 500 or from the AA server 380 through the authority server 500. For example, the MSA 320 may receive information related to the MMP (e.g., MMP access address) to perform the MEC discovery process, an authentication code (e.g., Auth code) for authorization, and an ID_token as an authentication result. According to an embodiment, the MSA 320 may receive information related to the CARP or URSP rule for the MEC data service based on the support by the AA server 380.

[0184] According to an embodiment, the MSA 320 may perform MEC service authorization as in operation 520 after user authentication as in operation 510 .

[0185] According to an embodiment, after completing the authentication, the MSA 320 may transmit a message for an authorization request to the MMP server 370 in operation 513. For example, the MSA 320 may transmit the acquired authentication information (e.g., including an Auth code or another ID_token) to the MMP server 370 and make a request for authorization for the MMP server 370. For example, after completing the authentication, the MSA 320 may access the MMP server 370 based on the MMP access address and perform an authorization procedure.

[0186] The MMP server 370 may make a request for an access token to the authority server 500 in operation 515, and obtain the access token from the authority server 500 in operation 517. According to an embodiment, the MMP server 370 may communicate with the authority server 500 or communicate with the AA server 380 through the authority server 500 and identify whether the electronic device 101 is a MEC service subscriber. According to an embodiment, when the MEC service subscriber is identified through the AA server 380, the MMP server 370 may issue (e.g., authorize) an access token (e.g., MAT) in the MSA 320.

[0187] In operation 519, the MMP server 370 may transmit the MMP information and the authorization code to the rights server 500 (or the AA server 380), and may make a request for an access token for user profile information access and acquire the access token for user profile information access.

[0188] In operation 521, the MMP server 370 may transmit an authorization response corresponding to the authorization request to the MSA 320. According to an embodiment, the MMP server 370 may identify the user profile using the corresponding access token, and when it is identified that the MEC service is available based on the user profile, the authorization response including MMP Info, MAT, or CARP rules may be transmitted to the MSA 320.

[0189] According to an embodiment, in operation 521, as a result of the authorization process, the MSA 320 may acquire an access token (e.g., MAT). According to an embodiment, when the MSA 320 performs the authorization process with the MMP server 370, the MSA 320 may receive the access token as a result of the authorization process and send the MMP information and the access token to the MSE 330 through the MSE API. According to another embodiment, when the MSE 330 performs the authorization process with the MMP server 370, the MSA 320 that completes the authentication may first send the MMP information and the authorization code (Auth code) received from the authority server 500 to the MSE 330 through the MSE API, and selectively send the ID_token to the MSE 330 through the MSE API. The MSE 330 may perform the authorization process directly with the MMP server 370 on the basis of the information sent from the MSA 320, and receive the access token as a result thereof.

[0190] In operation 523 , the MSA 320 may perform an MEC discovery procedure through the MSE 330 using the MMP Info and the access token.

[0191] Figure 6 An example of an authentication process according to various embodiments of the present disclosure is shown.

[0192] like Figure 6 As shown, the electronic device 101 may include an MSA (or service agent) 320 (eg, including an AA client 325) and an MSE (or service enabler) 330 (eg, including an MEL 331 and an UHL 333).

[0193] Reference Figure 6 In operation 601, the MSA 320 of the electronic device 101 may transmit a message (e.g., an authorization request message) for an authorization request for using a service to the MMP server 370 based on at least one predetermined authentication method. According to an embodiment, when a request for authorization to use a service is made to the MMP server 370, the MSA 320 may provide (or transmit) at least one or all of mobile network operator (MNO) (e.g., authority server 500) information and a device ID (e.g., IMSI, IMEI, GPSI, or a separately assigned unique identifier) ​​to the MMP server 370. According to an embodiment, the device ID may include an identifier, and the MMP server 370 may uniquely identify the electronic device 101 through the identifier.

[0194] In operation 603, the MSA 320 may perform an authentication and authorization (Authentication & Authorization (AA)) process with the MMP server 370 or with the AA server 380 through the MMP server 370. For example, when the MSA 320 transmits an authorization request to the MMP server 370, the MSA 320 may perform a trilateral message exchange between the MSA 320, the MMP server 370, and the AA server 380. According to an embodiment, the MSA 320 may perform user authentication and service authorization (or authorization) with the MMP server 370. For example, the MSA 320 may perform a process of identifying whether the electronic device 101 corresponds to a registered user and a process of identifying whether the electronic device can receive a corresponding service. According to an embodiment, since the AA method varies depending on the MNO information, the MMP server 370 may perform AA by a method suitable therefor according to the MNO information.

[0195] When the MMP server 370 receives an authentication request from the electronic device 101, the MMP server 370 may perform authentication with the electronic device 101, and when the authentication is completed (e.g., the authentication process is completed), authentication information according to the authentication result is provided (or sent) to the electronic device 101 (e.g., MSA 320) in operation 605. According to an embodiment, the authentication information may include, for example, MMP Info and an access token (e.g., MAT). According to an embodiment, the MMP server 370 may also additionally (or selectively) include required information as well as the above information (e.g., at least one of the CARP and URSP rules for MEC data services in the authentication information), and provide the authentication information. According to an embodiment, in operation 605, the MSA 320 may receive all of the authentication information according to the authentication result (e.g., MMP Info, MAT, and CARP or URSP rules) from the MMP server 370. According to another embodiment, in operation 605, the MSA 320 may receive a portion of authentication information (eg, MMP Info and MAT for discovery) from the MMP server 370 and receive a CARP rule (or URSP rule) as a user authentication result from the AA server 380.

[0196] According to an embodiment, MMP Info may include, for example, information related to accessing the MMP server 370 (e.g., MMP access address). For example, MMP Info may include address information (e.g., uniform resource identifier (URI) or IP address) of a new MMP server 370 to be accessed and information related to the valid corresponding address information and / or the location of the corresponding address information. According to an embodiment, an access token (e.g., MAT) may include, for example, an access token for identifying an MEC discovery authorization. According to an embodiment, a CARP or URSP rule may include, for example, information related to DNN configuration, information related to an application (or application group) that can be used for each DNN, a list of DNNs that can be configured thereafter, or a maximum number of DNNs that can be configured.

[0197] When the authentication process is completed, the MSA 320 may perform a policy update (e.g., PDU session establishment) with the MSE 330 in operation 607. According to an embodiment, the MSA 320 may perform PDU session establishment according to a CARP rule or a URSP rule (e.g., DNN). For example, when there is a URSP rule in the information received from the MMP server 370, the MSA 320 may update the URSP rule through the MSE API.

[0198] According to an embodiment, for example, when the MSA 320 receives the CARP or URSP rule from the AA server 380, the operation of performing the policy update by the MSA 320 and the MSE 330 in operation 607 may be performed. According to an embodiment, when the CARP or URSP rule is not provided from the AA server 380, the MSA 320 may not perform the policy update with the MSE 330. According to another embodiment, even if the CARP or URSP rule is provided from the AA server 380, the MSA 320 may not perform the policy update through its own determination or information exchange with the MSE 330.

[0199] In operation 609, the MSA 320 may activate the MSE 330. According to an embodiment, when the MSA 320 receives authentication information (e.g., access token (MAT)) according to the authentication result from the MMP server 370 while performing authentication with the AA server 380 or after performing authentication, the MSA 320 may send the received authentication information (e.g., access token (MAT)) to the MSE 330 to activate the MSE 330. According to an embodiment, the MSA 320 may send at least one additional information such as an access address (e.g., URI or IP address) of a new MMP server 370 to be accessed, a DNS server address, or a DNN to be used to perform the MEC discovery process, together with the authentication information (e.g., authentication token (MAT)) to the MSE 330. According to an embodiment, the MSA 320 may activate (enable MEC) the MSE 330 based on the received access token and / or other additional information. According to an embodiment, for example, when MSA 320 performs authentication with the MMP server 370, MSA 320 may receive an access token (e.g., MAT) as an authentication result from the MMP server 370, call enableMecEnablingLayer(true, MMP Info, MAT) of the MSE API, and send MMP access information (MMP Info) and the access token (MAT) to the MSE 330.

[0200] In operation 611, the MSE 330 may receive authentication information (e.g., MAT) and / or other additional information (e.g., DNN to be used, DNS server address, or MMP Info) and perform an MEC discovery process based at least on the authentication information and / or the additional information. According to an embodiment, the MSE 330 may perform an MEC discovery process after accessing the corresponding MMP server 370 using MMP Info and MAT.

[0201] Figure 7 An example of an authentication process according to various embodiments of the present disclosure is shown.

[0202] like Figure 7 As shown, the electronic device 101 may include an MSA (or service agent) 320 (e.g., including an AA client 325) and an MSE (or service enabler) 330 (e.g., including a MEL 331 and a UHL 333). According to an embodiment, the URSP may be added by the PCF of the AMF / PCF server 390, and information required for MMP access (e.g., MMP information, Auth code, or ID_token) may be managed.

[0203] Reference Figure 7In operation 701, the MSE 330 of the electronic device 101 may perform a NAS signaling process with an AMF / PCF server 390 (e.g., AMF). According to an embodiment, the AMF / PCF server 390 may provide the electronic device 101 with MMP Info and Auth code and additionally provide ID_token and / or CARP or URSP rules. According to an embodiment, the MSE 330 may receive a NAS signaling message received by the modem (or communication processor) of the electronic device 101 from the AMF 390 through the UHL 333 of the MSE 330. For example, the modem of the electronic device 101 may obtain at least one of MMPInfo, Auth code, ID_token, and CARP and URSP rules from the NAS signaling message received from the AMF, and send the obtained information to the MSA 320 through the UHL 333.

[0204] In operation 703, the MSE 330 may acquire at least one of MMP Info, Auth code, and / or ID_token from the NAS signaling message, and send the acquired information to the MSA 320. According to an embodiment, the MMP Info may include, for example, information related to accessing the MMP server 370 (e.g., an MMP access address). For example, the MMP Info may include address information (e.g., a uniform resource identifier (URI) or an IP address) of a new MMP server 370 to be accessed and information related to valid corresponding address information and / or a location of the corresponding address information. According to an embodiment, the CARP or URSP rule may include, for example, information related to DNN configuration, information related to an application (or application group) that can be used for each DNN, a list of DNNs that can be configured thereafter, or a maximum number of DNNs that can be configured.

[0205] According to an embodiment, the MSA 320 may acquire at least one of MMP Info, Auth code, ID_token, and CARP and URSP rules provided from the AMF / PCF server 390 through the MSE.

[0206] In operation 705, the MSA 320 may perform a policy update (e.g., a PDU session establishment) with the MSE 330. According to an embodiment, the MSA 320 may perform a PDU session establishment according to a CARP rule or a URSP rule (e.g., a DNN). For example, when there is a URSP rule in the information received from the MMP server 370, the MSA 320 may update the URSP rule through the MSE API. According to an embodiment, when the information acquired through the NAS signaling message includes the CARP or URSP rule, the MSA 320 may perform a policy update with the MSE 330. According to an embodiment, when the information acquired through the NAS signaling message does not include the CARP or URSP rule, the MSA 320 may not perform a policy update with the MSE 330. According to another embodiment, even if the CARP or URSP rule is provided, the MSA 320 may not perform a policy update based on its own determination or through information exchange with the MSE 330. According to an embodiment, the PDU session establishment may be performed when a policy update between the MSA 320 and the MSE 330 is performed.

[0207] After receiving the NAS signaling message (or after performing a policy update or omitting a policy update with the MSE 330), the MSA 320 may send a message for an authorization request (e.g., a service authorization request) to the MMP server 370 in operation 707. According to an embodiment, the MSA 320 may make a request for authorization to use a service to the MMP server 370 based on the authentication information (e.g., including an Auth code or another ID_token) obtained from the NAS signaling message.

[0208] In operation 709, the MSA 320 may perform authentication (e.g., authorization process) with the AA server 380 through the MMP server 370. According to an embodiment, the MSA 320 may provide (or transmit) at least one or all of the Auth code and the ID_token to the MMP server 370 together with the AA server 380 and make a request for service authorization.

[0209] In operation 711, the MMP server 370 may provide (or transmit) authentication information to the electronic device 101 (e.g., MSA 320) in response to an authorization request (e.g., authorization request message) from the MSA 320. According to an embodiment, the authentication information may include, for example, an access token (e.g., MAT) and MMP Info. According to an embodiment, the MMP server 370 may transmit a response including the access token and MMP Info to the MSA 320 during or after authentication of the MSA 320.

[0210] In operation 713, the MSA 320 may activate the MSE 330. According to an embodiment, when the MSA 320 receives authentication information (e.g., access token (MAT) and MMP Info) from the MMP server 370, the MSA 320 may send the received authentication information (e.g., access token (MAT) and MMP Info) to the MSE 330 to activate the MSE 330. According to an embodiment, the MSA 320 may send at least one additional piece of information together with the authentication token (MAT), such as an access address (e.g., URI or IP address) of a new MMP server 370 to be accessed, a DNN or DNS server address to be used to perform the MEC discovery process, to the MSE 330. According to an embodiment, the MSA 320 may activate (enable MEC) the MSE 330 based on the received access token (MAT) and / or other additional information. According to an embodiment, when MSA 320 performs an authorization process with MMP server 370, MSA 320 may receive an access token (e.g., MAT) from MMP server 370, call, for example, enableMecEnablingLayer(true, MMPInfo, MAT) of the MSE API, and send MMP access information (MMP Info) and access token (MAT) to MSE 330 for transmission.

[0211] In operation 715, the MSE 330 may receive authentication information (e.g., MAT) and / or other additional information (e.g., MMP Info, DNS server address, or DNN to be used) and perform an MEC discovery process based at least on the authentication information and / or the additional information. According to an embodiment, the MSE 330 may perform an MEC discovery process after accessing the corresponding MMP server 370 using MMP Info and MAT.

[0212] Figure 8 An example of a policy update operation by the electronic device 101 according to various embodiments of the present disclosure is shown.

[0213] like Figure 8 As shown, Figure 8 An example of PDU session creation (e.g., PDU session establishment) during policy update and an example of operations for dedicated DNN activation in PDU session establishment (or PDN connection creation) are shown. According to an embodiment, PDU session establishment may include new PDU session creation, existing PDU session release, and existing PDU session update (e.g., changes in characteristics (e.g., QoS information such as bandwidth or latency) for each PDU session during establishment), and Figure 8An example of PDU session creation is shown. According to an embodiment, the electronic device 101 may include an MSA (or service agent) 320 , an MSE (or service enabler) 330 , and a modem (or communication processor (CP)) 800 .

[0214] Reference Figure 8 When acquiring (or receiving) information about DNN establishment, MSA 320 may provide (or send) a first message (eg, setUrspDNN) indicating configuration of the DNN to MSE 330 in operation 801 .

[0215] In operation 803, the MSE 330 may update the DNN information (eg, update DNN Info) based on the first message (eg, setUrspDNN) provided from the MSA 320.

[0216] In operation 805 , the MSA 320 may provide the MSE 330 with a second message (eg, requestPduSession) indicating creation of a PDU session (or PDN connection).

[0217] When receiving the second message (eg, requestPduSession), the MSE 330 may provide a third message (eg, establish data call) indicating data call establishment to the modem 800 in operation 807 .

[0218] When receiving the third message (e.g., establishing a data call) from the MSE 330, the modem 800 may configure the data call on the basis of the pre-configuration information for processing the service (e.g., MEC service) or on the basis of the indicated information in operation 809, and provide a fourth message (e.g., a response message) corresponding to the third message to the MSE 320. According to an embodiment, a PDU session may be created based on a request made by the modem 800 to create a PDU session to a core network (e.g., SMF—not shown) through the third message (e.g., establishing a data call).

[0219] When receiving the fourth message (eg, a response to the data call establishment request) from the modem 800 , the MSE 330 may provide a fifth message (eg, onAvaible) informing the creation of the PDU session to the MSA 320 in operation 811 .

[0220] When the URSP rule is received using one of the above methods or by other methods, the MSA 320 may provide the MSE 330 with a sixth message (e.g., setUrspRules) indicating establishment of the URSP rule in operation 813. According to an embodiment, in operation 815, the MSA 320 may provide the MSE 330 with a seventh message (e.g., setMaServiceEnableMode(true)) indicating execution (true) of the MEC service activation mode (e.g., MSE activation).

[0221] In operation 817, the MSE 330 may generate (or add) a routing table in the sixth message (e.g., setUrspRules) and the seventh message (e.g., setMaServiceEnableMode(true)) received from the MSA 320. According to an embodiment, the URSP rule may include PDU session information for each application or each URI, and the electronic device 101 (e.g., MSE 330) may create a PDU session through the setUrspDNN API when the PDU session under the URSP rule is not created. According to an embodiment, when creating a PDU session, the electronic device 101 (e.g., MSE 330) may configure the routing table through the setUrspRules API to configure a data path for the corresponding application ID (AppID) or URI through the PDU session under the URSP rule.

[0222] Fig. 9 An example of a PDU session establishment operation by the electronic device 101 according to various embodiments of the present disclosure is shown.

[0223] like Fig. 9 As shown, Fig. 9 An example of a PDU session release during a policy update (e.g., PDU session establishment) and an example of an operation for releasing a PDU session (or PDN connection) are shown. According to an embodiment, a PDU session establishment may include a new PDU session creation, an existing PDU session release, and an existing PDU session update (e.g., a change in configuration of characteristics (e.g., QoS information such as bandwidth or latency) for each PDU session), and Fig. 9 An example of a PDU session release is shown. According to an embodiment, the electronic device 101 may include an MSA (or service agent) 320 , an MSE (or service enabler) 330 , and a modem (or communication processor (CP)) 800 .

[0224] Reference Fig. 9When the MSA 320 should release the configuration of the information about the DNN establishment, the MSA 320 may provide (or transmit) a first message (eg, setUrspDNN) indicating the release of the corresponding DNN to the MSE 330 in operation 901.

[0225] In operation 903 , the MSE 330 may provide the modem 800 with a second message (eg, Release Data Call) indicating the release of the data call, based on the first message (eg, setUrspDNN) provided from the MSA 320 .

[0226] When receiving the third message (e.g., releasing the data call) from the MSE 330 in operation 905, the modem 800 may release the configuration set to process the corresponding service (e.g., MEC service) and provide a fourth message (e.g., response message) corresponding to the third message to the MSE 330. According to an embodiment, the PDU session may be released based on a PDU session request made by the modem 800 to release to the core network (e.g., SMF).

[0227] In operation 907 , the MSA 320 may provide the MSE 330 with a fifth message (eg, setMaServiceEnableMode(false)) indicating execution (false) of the MEC service deactivation mode (eg, MSE deactivation).

[0228] In operation 909, the MSE 330 may delete the fifth message (eg, setMaServiceEnableMode(false)) stored in the memory (eg, Figure 1 or Figure 2 A routing table in the memory 130 (or generated by the memory).

[0229] Fig.10 An example of a discovery process according to various embodiments of the present disclosure is shown.

[0230] like Fig.10 As shown, Fig.10 An example of an App state-based MEC discovery process is shown. According to an embodiment, the electronic device 101 may include a client application (or client App) 310, an MSA (or service agent) 320, an MSE (or service enabler) 330 (for example, including MEL 331 and DHL 335), and a DNS cache 1010.

[0231] Reference Fig.10In operation 1001, the MSA 320 of the electronic device 101 may configure an MEC discovery policy in the MSE 330. According to an embodiment, the MEC discovery policy may include and provide a client application name (e.g., clientAppNames) and a discovery policy (e.g., discoveryPolicy). According to an embodiment, the discoveryPolicy may include information indicating whether a dynamic DNN (e.g., dynamicDnn) is used, and may include and provide at least one of information such as a location (e.g., locationInfo), a device type (e.g., deviceType), a service type (e.g., serviceType), and a context type (e.g., contextType). According to an embodiment, the MSA 320 may insert the location (e.g., locationInfo), the device type (e.g., deviceType), and the service type (e.g., serviceType) into the discoveryPolicy and restrictively receive only an app list that satisfies the corresponding conditions. According to an embodiment, the MSA 320 may insert a context type (e.g., contextType) into the discoveryPolicy to include information indicating whether an application context is required. According to an embodiment, when the MSA 320 inserts a URI request tag into the discoveryPolicy and the URI of the MEC application is available, the MSA 320 may make a request to insert the URI into the app list. According to an embodiment, the client application name (clientAppNames) may be information for making a request for an app list to identify whether the MEC is available, the location (locationInfo) may be information for making a request for a location-based app list according to the current location of the electronic device 101, and the dynamic DNN (dynamicDnn) may be information for making a request to update the use of the dynamic DNN.

[0232] In operation 1003, the MSE 330 may perform an acquisition process (e.g., MEC application search) for acquiring an app list (e.g., AppList) based on information (e.g., MEC discovery policy) received from the MSA 320. According to an embodiment, the acquisition process (e.g., MEC application search) for acquiring an app list may be started according to the configuration of the MEC discovery policy between the MSA 320 and the MSE 330. According to an embodiment, when the MEC discovery policy is received from the MSA 320 through the MSE API, the MSE 330 may activate the MEC application search and execute (or start) it when the unique conditions of the electronic device 101 are met (e.g., the change of the cell ID of the access base station when the electronic device 101 moves). According to an embodiment, the MSE 330 may make a request for an app list (e.g., MECAppList) related to an MEC application (e.g., MEP App) that can be served according to the MEC discovery policy and receive it. According to an embodiment, MSE 330 may write the MEC discovery policy in the MEC AppList request message parameters as shown in and send a request to the MMP server 370, and the MMP server 370 may provide the MSE 330 with a list of apps suitable for service here and respond to the request from the MSE 330.

[0233] In operation 1005, the client application 310 may provide (or transmit) an App launch detection or an API (context creation) call to the MSA 320. According to an embodiment, the case of the App launch detection may indicate a case where the client application 310 is executed. According to an embodiment, the API (context creation) call may indicate a case where a request is made for a URI for a MEC application name to be accessed (e.g., MEC App name).

[0234] When receiving an App program launch detection or an API (context creation) call, the MSA 320 may provide a notification message (e.g., notifyClientAppState) notifying the state of the client application 310 to the MSE 330 in operation 1007. According to an embodiment, the notification message (e.g., notifyClientAppState) may include and provide, for example, the state of the client application (e.g., start) and the client application name (e.g., clientAppName) (and / or UID) (e.g., notifyClientAppState (start, clientAppName)).

[0235] In operation 1009, the MSE 330 may receive a notification message (e.g., notifyClientAppState) from the MSA 320 and perform a process (e.g., application context creation) for discovering (or searching for or identifying) an MEC application (or an MEC host (e.g., an edge server or an MEC server) including a corresponding MEC application) based on the received notification message. According to an embodiment, when an event related to the execution of the client application 310 is received from the MSA 320, the MSE 330 may activate the application context creation. According to an embodiment, the MSE 330 may perform an operation for discovering the application context creation of the MEC host including the desired MEC application through the MMP server 370 based on the information of the received notification message (e.g., notifyClientAppState). According to an embodiment, when the MSA 320 detects the execution of the client application 310, the application context creation may be activated (or executed) by calling the MSE API. According to an embodiment, when the client application 310 calls the context creation API, the application context creation may be activated (or executed). According to an embodiment, the MSE 330 may make a request for a URI of a MEC application name (e.g., MEC App name) to be accessed to the MMP server 370 and receive it. According to an embodiment, the MSE 330 may make a request for information about a dedicated DNN to the MMP server 370 when necessary and receive it. According to an embodiment, when there is no corresponding MEC application, the MMP server 370 may send a MEC application data packet URI to the MSE 330. The application context creation process according to various embodiments is described in detail with reference to the following drawings.

[0236] In operation 1011, the MSE 330 may perform a host selection process (e.g., MEC host selection) for selecting a MEC host having a DNS server 1020. According to an embodiment, when the number of MEC hosts acquired through the MMP server 370 is two or more, the MSE 330 may perform a host selection process (e.g., MEC host selection) for selecting one MEC host having the DNS server 1020. According to an embodiment, when the number of MEC hosts is two or more, the host selection process for selecting one MEC host may be determined using pre-configured information and / or information asked from the DNS server 1020, and / or a specific MEC host may be selected (or configured) based on the information asked from the DNS server 1020 and / or by asking a user. According to an embodiment, when the number of MEC hosts is two or more, the information pre-configured by the MSE 330 to configure the specific MEC host may include priority information. According to an embodiment, the host selection process may include a DNS pre-resolution operation and a MEC host prioritization operation. According to an embodiment, DNS pre-resolution may include, for example, the performance of a DNS resolution of a MEC fully qualified domain name (FQDN) by the MSE 330 itself, regardless of the DNS query of the client application 310. According to an embodiment, the DNS resolution may be performed using a URI or domain name received by the Get App List step in operation 1003 or the Find Cloudlet step in operation 1009. According to an embodiment, for example, when multiple IP addresses are received as a DNS query response, the MEC host priority may include the configuration of an IP priority. The host selection process (e.g., MEC host selection) according to various embodiments is described in detail with reference to the following figures.

[0237] In operation 1013, the client application 310 may perform a DNS resolution operation based on the information obtained by the operation. According to an embodiment, for example, when a DNS query of the client application 310 is generated, a DNS resolution may be performed. According to an embodiment, the DNS resolution may include, for example, a client-driven regular DNS resolution or a DNS proxy (hooking the DNS query). The DNS resolution according to various embodiments is described in detail with reference to the following figures.

[0238] Fig.11 An example of a discovery process according to various embodiments of the present disclosure is shown.

[0239] like Fig.11 As shown, Fig.11An example of a MEC discovery process based on a DNS query is shown. According to an embodiment, the electronic device 101 may include a client application (or client App) 310, an MSA (or service agent) 320, an MSE (or service enabler) 330 (for example, including MEL 331 and DHL 335), and a DNS cache 1010.

[0240] Reference Fig.11 In operation 1101, the MSA 320 of the electronic device 101 may configure an MEC discovery policy in the MSE 330. According to an embodiment, the MEC discovery policy may include and provide a client application name (e.g., clientAppNames) and a discovery policy (e.g., discoveryPolicy). According to an embodiment, the discoveryPolicy may include information indicating whether a dynamic DNN (e.g., dynamicDnn) is used, and may include and provide at least one of information such as a location (e.g., locationInfo), a device type (e.g., deviceType), a service type (e.g., serviceType), and a context type (e.g., contextType). According to an embodiment, the MSA 320 may insert the location (e.g., locationInfo), the device type (e.g., deviceType), and the service type (e.g., serviceType) into the discoveryPolicy and restrictively receive only an app list that satisfies the corresponding conditions. According to an embodiment, the MSA 320 may insert a context type (e.g., contextType) into the discoveryPolicy to include information indicating whether an application context is required. According to an embodiment, when the MSA 320 inserts a URI request tag into the discoveryPolicy and the URI of the MEC application is available, the MSA 320 may make a request to insert the URI into the app list.

[0241] In operation 1103, the MSE 330 may perform an acquisition process (e.g., MEC application search, obtain application list) for acquiring an app list (e.g., AppList) based on information (e.g., MEC discovery policy) received from the MSA 320. According to an embodiment, the acquisition process (e.g., MEC application search, obtain App list) for acquiring an app list may be started according to the configuration of the MEC discovery policy between the MSA 320 and the MSE 330. According to an embodiment, when the MEC discovery policy is received from the MSA 320 through the MSE API, the MSE 330 may activate the MEC application search and execute (or start) it when the unique conditions of the electronic device 101 are met (e.g., the change of the cell ID of the access base station when the electronic device 101 moves). According to an embodiment, the MSE 330 may make a request for an app list (e.g., MEC AppList) related to an MEC application (e.g., MEP App) that can be served according to the MEC discovery policy and receive it. According to an embodiment, the MSE 330 may write the MEC discovery policy in the MEC AppList request message parameter and send a request to the MMP server 370 , and the MMP server 370 may provide the MSE 330 with a list of apps suitable for service here and respond to the request from the MSE 330 .

[0242] In operation 1105 , the client application 310 may transmit a message for a DNS query (eg, a DNS query message) to the MSE 330 .

[0243] In operation 1107, in response to a DNS query from the client application 310, the MSE 330 may perform a find cloudlet operation with the MMP server 370. According to an embodiment, when a DNS query (with FQDN) message is generated by the client application 310, the MSE 330 may perform a find cloudlet operation for the corresponding MEC application (e.g., MEC App) when the FQDN for MEC is detected through FQDN filtering. According to an embodiment, the MSE 330 may make a request to the MMP server 370 for a URI for a MEC application name (e.g., MEC App name) to be accessed. According to an embodiment, the MSE 330 may make a request to the MMP server 370 for information about a dedicated DNN when necessary and receive it. According to an embodiment, when there is no corresponding MEC application, the MMP server 370 may send a MEC application data packet URI to the MSE 330.

[0244] In operation 1109, the MSE 330 may perform a host selection process (e.g., MEC host selection) for selecting a MEC host using the DNS server 1020 in response to a DNS query from the client application 310. According to an embodiment, when the number of MEC hosts acquired through the MMP server 370 is two or more, the MSE 330 may perform a host selection process (e.g., MEC host selection) for selecting one MEC host using the DNS server 1020. According to an embodiment, when the number of MEC hosts is two or more, the host selection process for selecting one MEC host may be determined using preconfigured information and / or information received through a request to the DNS server 1020 (e.g., IP address and location information of each IP), or a user may be allowed to select (or configure) a unique MEC host through information received in response to a request to the DNS server 1020 or a user interface (UI) (e.g., a selection button). According to an embodiment, when the number of MEC hosts is two or more, the information preconfigured by the MSE 330 to configure the unique MEC host may include priority information. According to an embodiment, the priority information may include, for example, information about a host priority determined according to each URI, or when the number of IP addresses as a result of DNS resolution for one URI is multiple, information about the priority for each corresponding one. According to an embodiment, the host selection process may include a DNS resolution operation and an MEC host prioritization operation. According to an embodiment, the DNS resolution may include, for example, the MSE 330's own execution of a DNS resolution of the FQDN of the MEC, regardless of the DNS query of the client application 310. According to an embodiment, for example, when multiple IP addresses are received as a DNS query response, the MEC host prioritization may include the configuration of the IP priority. According to an embodiment, a priority may be predetermined for each URI or each IP, and when multiple IP addresses are received, the IP priority may be determined based on the result of a performance test for each of the multiple IPs. The host selection process (e.g., MEC host selection) according to various embodiments is described in detail with reference to the following figures.

[0245] When the process is completed, the MSE 330 may provide the information obtained through the process as a DNS response to the client application 310 in operation 1111. According to an embodiment, after MEC host selection (e.g., DNS resolution), the MSE 330 may transmit a DNS response corresponding to the DNS query to the client application 310 that provided the DNS query. The DNS response according to various embodiments is described with reference to the following drawings.

[0246] Fig.12 An example of an operation of acquiring an app list during a discovery process according to various embodiments of the present disclosure is shown.

[0247] like Fig.12 As shown, Fig.12 An example of operations related to generation or acquisition of an app list in an MEC discovery process (eg, MEC application lookup) according to an embodiment is shown.

[0248] Reference Fig.12 In operation 1201, the MSA 320 of the electronic device 101 may send an MEC discovery policy to the MSE 330. According to an embodiment, the MEC service module 410 may obtain the MEC discovery policy through the MSA 320 and perform a discovery process based on the MEC discovery policy received using the MSE 330. According to an embodiment, the MEC discovery policy may include and provide at least one of information such as a client application name (e.g., clientAppNames), a location (e.g., locationInfo), a device type (e.g., deviceType), a service type (e.g., serviceType), a context type (e.g., contextType), a URI request tag (e.g., URI Request), and a dynamic DNN (e.g., dynamicDnn).

[0249] In operation 1203, the MSE 330 may perform an acquisition process (e.g., MEC application lookup) for acquiring an app list (e.g., AppList) based on information (e.g., MEC discovery policy) received from the MSA 320. According to an embodiment, the operation of acquiring the app list may be started according to the configuration of the MEC discovery policy between the MSA 320 and the MSE 330. According to an embodiment, the process of acquiring the app list may be activated when the MSA 320 calls the MEC discovery policy API, makes a request for the MEC app list and / or URI suitable for the MEC discovery policy to the MMP server 370, and receives it. According to an embodiment, the process of acquiring the app list may include operations 1210 and 1220.

[0250] In operation 1210, the MSE 330 may send a request message (e.g., HTTP Get AppList request parameter) requesting an app list to the MMP server 370. According to an embodiment, the MSE 330 may insert (or write) the MEC discovery policy into the request message (e.g., HTTP Get AppList request parameter) and provide the request message to the MMP server 370. For example, the MSE 330 may include an app list request parameter and provide the app list request parameter to the MMP server 370.

[0251] According to an embodiment, field information that can be supported in request parameters can be defined in MMP Info within the authorization response in the authentication (AA) step. According to an embodiment, parameters (or information) related to the app list request (e.g., AppList request parameters) can be included in a parameter field of a request message (e.g., HTTP Get). According to an embodiment, the app list request parameter may include an application name (e.g., clientAppNames) received from the MSA 320 (e.g., setMecDiscoveryPolicy(clientAppNames and discoveryPolicy) in operation 1201), an access cell ID, a tracking area (TA) ID, area information (e.g., city, district, cave, and building), location information (Location Info) related to the location of the electronic device 101 including at least one of the preferred location information specified by the user, a device type for identifying the type of the electronic device 101 (e.g., a smartphone, a tablet, a wearable device, the Internet of Things, a car, or a drone), a service type for identifying the type of the service (e.g., a game, V2X, AR / VR, LBO, an enterprise, or a web page), a context type for identifying whether context information is required (e.g., whether context information of a user or an application is required to execute the MEC application), or at least one of a mark (e.g., a URI request flag) for making a request to insert a corresponding URI into the response when the URI of the MEC application is available. According to an embodiment, the context type is information for identifying the service application type of the electronic device 101 and may include, for example, at least one of an application installed in the electronic device (e.g., a unique launcher or a predetermined application), a name of the executed application, and a domain.

[0252] According to an embodiment, the electronic device 101 may transmit information about an application (e.g., a unique launcher or a predetermined application) installed in the electronic device 101 to the MMP server 370 in the process of making a request for an app list. According to an embodiment, when there is a change (e.g., update) in the information about the application installed in the electronic device 101, the electronic device 101 may transmit information about the application installed in the electronic device 101 in the process of making a request for an app list to the MMP server 370.

[0253] In operation 1220, the MMP server 370 may provide a response message (e.g., HTTP 200OK AppList response data) including an app list (e.g., MEC AppList) to the MSE 330 in response to the request message received from the MSE 330. According to an embodiment, the MMP server 370 may search for MEC applications based on the received client application name, and may provide the MSE 330 with an app list including the searched MEC applications in the response message.

[0254] According to an embodiment, data (or information) related to the app list response (eg, AppList response data) may be included in a message body of a response message (eg, HTTP 200OK).

[0255] According to an embodiment, when providing an app list, the MMP server 370 may provide a list of MEC Apps that can be served based on at least one of the request parameters or all of the available MEC Apps. According to an embodiment, a MEC App name accessed for each client application (Client App) may be included, and the MEC App name may be used (or required) for subsequent application context creation operations.

[0256] According to an embodiment, when the operator's location API is available, the MMP server 370 may insert a notification into the app list and provide an app list. According to an embodiment, when the URI request flag in the request message is true and the corresponding MEC App is being executed in an available MEC host near the electronic device 101 (e.g., a user device), the MMP server 370 may insert the URI of the corresponding MEC App into the app list and provide an app list. According to an embodiment, even when there is no URI request flag in the request message, if the corresponding MEC App is being executed in the MEC host, the MMP server 370 may insert the URI of the corresponding MEC App into the app list and provide an app list. According to an embodiment, when an app list request is received from the electronic device 101, if the MEC App can be directly executed according to the context type, the MMP server 370 may execute the MEC App and then insert the corresponding URI into the request message and provide the request message. According to an embodiment, the MMP server 370 may also insert the valid time / valid location information of the URI into the app list and provide an app list. According to an embodiment, the information about the valid time of the URI may be determined by the electronic device 101 or variably determined by the MMP server 370 according to the MECApp execution state. According to an embodiment, when there are application-specific DNN rules, the MMP server 370 may provide corresponding rules.

[0257] According to an embodiment, the URI included in the app list may be distinguished by a hyperlink or highlight, and the electronic device 101 may distinguish and display the URI from the MEC App that does not include the URI on the basis of the hyperlink and / or highlight. According to another embodiment, the electronic device 101 may equally display the MEC App including the URI and the MEC App not including the URI in the app list without distinction between them. According to an embodiment, the electronic device 101 may include and provide location and / or time information that can be served for each application in the app list.

[0258] According to an embodiment, when DNN establishment can be in units of applications in the process of transmitting a response of an app list, the MMP server 370 may include DNN information used for each application (or each app) in the app list. According to an embodiment, the corresponding DNN server may be a DNN included in the DNN list received during the authentication (AA) process.

[0259] According to an embodiment, the electronic device 101 may make a request for an app list to the MMP server 370 and obtain (or receive) the app list and information (e.g., URI) about a MEC host (e.g., an edge server or a MEC server) for a corresponding application in the app list during a process of receiving a response. According to an embodiment, when information (e.g., URI) about a MEC host is not received, the electronic device 101 may also perform, for example, an application context creation process for the corresponding app and obtain information (e.g., URI) about a MEC host for the corresponding application from an external server. According to an embodiment, when the electronic device 101 receives information (e.g., URI) about a MEC host, the electronic device may directly access, for example, the corresponding MEC host (e.g., via a URI) without performing any application context creation process for the corresponding application.

[0260] According to an embodiment, the electronic device 101 may make a request for an app list to the MMP server 370, and receive the app list and information about a predetermined networking path (e.g., DNN) for the corresponding application in the app list in the process of making a request for the app list to the MMP server 370 and receiving a response. According to an embodiment, when the electronic device 101 receives information about a predetermined networking path (e.g., DNN), the electronic device may perform a process of configuring a network and a predetermined networking path. According to an embodiment, the electronic device 101 may configure a DNN path only for an application that receives DNN information to communicate with a predetermined (or dedicated) DNN. According to an embodiment, the electronic device 101 may configure a predetermined DNN path for an application that receives DNN information in the process of making a request to create an MEC host context (e.g., application context creation).

[0261] Fig.13 An example of providing an app list according to various embodiments of the present disclosure is shown.

[0262] like Fig.13 As shown, Fig.13 Location-based service areas are shown.

[0263] Reference Fig.13According to an embodiment, it can be assumed that the MMP server 370 obtains first information about available applications (available Apps) (e.g., A(+URI), B, and C) from the first server (Server 1) 1310 (or the first MEC host of the neighboring user). According to an embodiment, it can be assumed that the MMP server 370 obtains second information about available applications (e.g., A, C(+URI), and D) of the neighboring user) from the second server (Server 2) 1320 (or the second MEC host of the neighboring user).

[0264] According to an embodiment, the MMP server 370 may collect information about application programs (e.g., first information and second information) obtained from the first server 1310 and the second server 1320 and generate (or obtain) information A (+URI), B, C (+URI), and D. According to an embodiment, the MMP server 370 may generate an app list including A (+URI), B, C (+URI), and D generated by the first server 1310 and the second server 1320, and provide the generated app list to the user 1330 (e.g., the electronic device 101).

[0265] Fig.14 An example of a context creation process in a discovery process according to various embodiments is shown.

[0266] like Fig.14 As shown, Fig.14An example of operations related to application context creation (e.g., application context creation) in an MEC discovery process according to an embodiment is shown. According to an embodiment, for example, when a client application 310 is executed, the process of creating an application context can be performed from the transmission of application start information together with information related to the corresponding client application (e.g., data packet name or UID) by MSA 320 to MSE 330 through an MSE API. According to various embodiments, application context creation can be performed when an application in an app list is started (a first case), an application makes a request to create a context (contextcreate) through an MSE API (e.g., calling a context creation API) (a second case), or when a DNS query is transmitted in an application, and the DNS query matches the name and / or URI (e.g., FQDN) of an application included in a pre-received app list (a third case). According to an embodiment, for example, when the location information transmitted through the MEC discovery policy (e.g., setDiscoveryPolicy(discoveryPolicy)) or the available location (e.g., uriLOC) for each application included in the app list transmitted through the application search response matches the location of the current user (or electronic device 101) (e.g., the fourth case), application context creation can be performed. According to various embodiments, application context creation can be performed when at least one of the first case, the second case, the third case, and the fourth case is satisfied. Fig.14 An example of performing an operation of application context creation according to the first case may be shown.

[0267] Reference Fig.14 In operation 1401, when the specific client application 310 is started, the corresponding client application 310 may provide information notifying the start of the application (e.g., App start) to the MSA 320. According to an embodiment, operation 1401 may not be performed. For example, when the client application 310 is started, the MSA 320 (e.g., architecture level) may detect the start of the client application 310 by itself without any operation notifying the start of the client application 310.

[0268] When the MSA 320 receives information notifying the launch of the client application 310 (e.g., App launch), the MSA 320 may provide a notification message (e.g., notifyClientAppState) notifying the state of the client application 310 to the MSE 330 in operation 1403. According to an embodiment, the notification message (e.g., notifyClientAppState) may include and provide, for example, the state of the client application (e.g., launch) and the client application name (e.g., clientAppName (and / or UID) (e.g., notifyClientAppState (launch, clientAppName)).

[0269] In operation 1405, MSE 330 may receive a notification message (e.g., notifyClientAppState) from MSA 320 and perform an application context creation process based on information in the received notification message. According to an embodiment, the application context creation process (operation 1405) may include operations 1410, 1420, and 1430.

[0270] In operation 1410, the MSE 330 may transmit a request message (e.g., HTTP post AppContext data) to make a request for application context creation to the MMP server 370. According to an embodiment, when MEC application context creation is required (e.g., when there is no URI in the app list), the MSE 330 may transmit a request message to make a request for the URI to the MMP server 370. According to an embodiment, when there is a MEC application in the MMP server 370, the MSE 330 may insert the MEC application name (MEC App name) into the request message and transmit the request message to the MMP server 370. According to another embodiment, when there is no MEC application in the MMP server 370, the MSE 330 may only insert the URI (e.g., application data packet download URI) from which the corresponding MEC application can be downloaded into the request message and transmit the request message to the MMP server 370.

[0271] In operation 1420, the MMP server 370 may provide a response message (e.g., HTTP OK 200 response AppContext data) including the URI of the MEC application to the MSE 330 in response to the request message received from the MSE 330. According to an embodiment, the response message may include the URI (FQDN) of the application (e.g., MEC application) corresponding to the response message. According to an embodiment, the response message may include the URI of the MEC application and information about the valid time and / or valid location of the corresponding URI. According to an embodiment, when the valid time passes or the valid location changes, the MSE 330 may re-execute the application context or perform a switching trigger. According to an embodiment, the response message may include DNN information.

[0272] In operation 1430, the MSE 330 may perform a policy update. According to an embodiment, the MSE 330 may additionally (or selectively) include a policy update operation in the application context creation process (operation 1405). According to an embodiment, when a dedicated PDU session is required (or when a new dedicated DNN rule is configured), the MSE 330 may receive a URSP rule (e.g., DNN) and create a PDU session for each application or each URI according to the URSP rule. For example, the URSP rule (or CARP rule) may be received as a result of an authentication process (e.g., received by the MSA 320 and sent to the MSE 330), a result of an application lookup (e.g., App lookup) by the MSE 330, or a result of context creation (context creation), and when a new DNN rule is configured in the URSP rule, the PDU session establishment may be performed. According to an embodiment, when the MSE 330 is as described in reference Figure 8 or Fig. 9 The PDU session establishment (eg, Figure 8 PDU session creation and Fig. 9 When a request is made for PDU session release in the 5G network, the PDU session establishment can be created / released by the modem 800 requesting the SMF of the 5G network (or core network).

[0273] According to an embodiment, for example, when the MEC application that the client application 310 should access has been executed and the URI is received in the app list acquisition process (e.g., MEC application search), the application context creation process (operation 1405) can be omitted.

[0274] Fig.15 An example of a MEC host selection process in a discovery process according to various embodiments of the present disclosure is shown.

[0275] like Fig.15 As shown, Fig.15 An MEC host selection operation (MEC host selection) 1501 is shown, in which the MSE 330 selects a MEC host with a DNS server 1020. According to an embodiment, the MEC host selection operation (operation 1501) may include a DNS (pre) resolution operation (e.g., operation 1510), a MEC host prioritization operation (e.g., operation 1520), and a DNS cache operation (e.g., operation 1530).

[0276] Reference Fig.15 In operation 1510, the MSE 330 may perform DNS resolution (or pre-resolution). According to an embodiment, the DNS resolution may include, for example, the performance of a DNS resolution of the FQDN of the MEC by the MSE 330 itself, regardless of the DNS query of the client application 310. According to an embodiment, the DNS resolution (operation 1510) may include operations 1511 and 1513.

[0277] According to an embodiment, in operation 1511, the MSE 330 may perform a DNS resolution operation through the DHL 335. According to an embodiment, the MSE 330 may transmit a DNS query for a URI (FQDN) for the MEC application to the DNS server 1020.

[0278] According to an embodiment, in operation 1513, the DNS server 1020 may receive a DNS query from the MSE 330 and send a DNS response to the MSE 330 in response to the DNS query. According to an embodiment, the DNS response may include at least one of address information (eg, URI or IP address) related to the MEC host.

[0279] In operation 1520, the MSE 330 may perform an MEC host prioritization operation. According to an embodiment, for example, when receiving multiple IP addresses as a DNS query response, the MEC host prioritization may include configuration of IP priorities (prioritization). For example, the MSE 330 may configure priorities for the MEC hosts.

[0280] According to an embodiment, the MSE 330 may obtain (or receive) a candidate IP list for multiple MEC hosts from the MMP server 370, and select a candidate IP list from the MEC host candidate IP and a remote server (e.g., Figure 3The access IP is selected from the IP addresses of the remote server 306 or the priority is specified based on other information in the candidate IP list (e.g., the current location of the user at the MEC host location, the user speed, or at least one of the MEC host performance (e.g., round-trip time (RTT) and throughput)). According to an embodiment, when the access IP is selected in the candidate IP list, one of the MEC host IP or the remote server IP can be selected. For example, when all MEC host locations are a predetermined distance or longer from the user location, the RTT value is greater than or equal to a predetermined value, or the user movement speed is greater than or equal to a predetermined value, the remote server IP can be selected without selecting the MEC host IP. According to an embodiment, the MSE 330 (e.g., the MEL 331) can select the optimal MEC host by pre-performance measurement (or test) (e.g., ping detection or bandwidth estimation) for multiple candidate MEC hosts. According to an embodiment, the DNS server 1020 can record the IP address of the MEC host and the location information of the corresponding MEC host in the DNS response message. For example, when the DNS response message received after the DNS query in the DNS resolution includes the location information of the MEC host for the location record type (e.g., LOC record type) among the DNS types, the MSE 330 may select a neighboring MEC host based on the corresponding location information. According to an embodiment, the MSE 330 may obtain the location information (e.g., latitude, longitude, serving cell ID, city information or ID) of the MEC host from the DNS server 1020 in the DNS query operation of obtaining the IP address of the MEC host. For example, the location information of the MEC host may be included in the DNS type field.

[0281] In operation 1530, the MSE 330 may perform DNS caching in the DNS cache 1010. According to an embodiment, when a DNS response including address information is received from the DNS server 1020 in response to a DNS query, the MSE 330 may store the address information (e.g., an IP address corresponding to a URI (FQDN) associated with the MEC host) included in the DNS response in a local DNS cache for the MEC (e.g., DNS Cache 2). According to an embodiment, when the client application 310 makes a request for address information (e.g., a URI or IP address) of a MEC application, the MSE 330 may transmit the address information stored in the local DNS cache for the MEC. According to various embodiments, in conjunction with the management of the local DNS cache for the MEC (e.g., DNS Cache 2), management including management may be used. Fig.16 Local DNS cache for MEC (DNS cache 2) or Fig.17The method of managing a local DNS cache (eg, DNS cache 2) for MEC within MSE 330 in the embodiment. The operation of managing a local DNS cache for MEC according to the embodiment is described in detail with reference to the following drawings.

[0282] According to various embodiments, the electronic device 101 may receive multiple pieces of MEC host information (e.g., URI or IP address), wherein the MEC application may be executed in a communication process (e.g., discovery / application context creation) with the MMP server 370 based on the MEC host selection operation. According to an embodiment, the electronic device 101 may select a MEC host from among the received multiple MEC hosts and communicate with it. According to various embodiments, the electronic device 101 may select multiple MEC hosts from the executable MEC applications based on priority. According to an embodiment, the priority may be determined based on at least the waiting time measurement information between the electronic device 101 and the MEC host or the location information of the MEC host.

[0283] Hereinafter, according to various embodiments, the electronic device 101 maintains and / or manages the operation of DNS cache data for a MEC client application (MEC Client App) separately from DNS cache data for a general client application (General Client App).

[0284] Fig.16 An example is shown in which the electronic device 101 separately manages a local DNS cache for MEC according to various embodiments.

[0285] Reference Fig.16 , Fig.16 An example of configuring a local DNS cache for MEC separately from the MSE 330 of the electronic device 101 is shown. According to an embodiment, the general client application (general client App) 1610 may perform DNS caching in the first DNS cache 1620, and the MEC client application (MEC client App) 310 may perform DNS caching in the second DNS cache 1630. For example, the general client application 1610 may use the first DNS cache 1620, and the MEC client application 310 may use the second DNS cache 1630.

[0286] According to an embodiment, a DNS resolution API may be used to make a request only for a URI to be accessed by a client application, and its IP address may be received. For example, MSE 330 (e.g., DHL 335) (or a DNS processing module on the OS or architecture of electronic device 101) may change the corresponding request of the client application into a DNS query (e.g., FQDN), send the DNS query to DNS server 1020, receive the DNS response (e.g., the IP address corresponding to the FQDN), cache it, and send it to the client application. According to an embodiment, MSE 330 may determine which DNS cache will be used for each client application or each URI (FQDN), and thus the DHL ( Fig.17 ) or DNS processing module (for example, Fig.16 In the example of FIG. 16 , the DNS processing module or DHL may send an IP address to the client application with reference to the first DNS cache 1620 or the second DNS cache 1630. According to an embodiment, when there is an IP corresponding to the corresponding URI that refers to the DNS cache for the requested URI (FQDN), the DNS processing module or DHL may send the IP, and when there is no URI in the cache, a DNS query may be sent to the DNS server 1020.

[0287] Fig.17 An example is shown in which the electronic device 101 manages a local DNS cache for MEC within the MSE 330 according to various embodiments of the present disclosure.

[0288] Reference Fig.17 , Fig.17 An example of configuring a local DNS cache (e.g., a second DNS cache 1630) for MEC in the MSE 330 of the electronic device 101 is shown. According to an embodiment, the general client application 1610 may perform DNS caching in the first DNS cache 1620, and the MEC client application 310 may perform DNS caching in the second DNS cache 1630. For example, the general client application 1610 may use the first DNS cache 1620, and the MEC client application 310 may use the second DNS cache 1630.

[0289] According to an embodiment, a DNS resolution API may be used to make a request only for a URI to be accessed by a client application, and its IP address may be received. For example, MSE 330 (e.g., DHL 335) (or a DNS processing module on the OS or architecture of electronic device 101) may change the corresponding request of the client application into a DNS query (e.g., FQDN), send the DNS query to DNS server 1020, receive the DNS response (e.g., the IP address corresponding to the FQDN), cache it, and send it to the client application. According to an embodiment, MSE 330 may determine which DNS cache will be used for each client application or each URI (FQDN), and thus the DHL ( Fig.17 ) or DNS processing module (for example, Fig.16 In the example of FIG. 16 , the DNS processing module or DHL may send an IP address to the client application with reference to the first DNS cache 1620 or the second DNS cache 1630. According to an embodiment, when there is an IP corresponding to the corresponding URI that refers to the DNS cache for the requested URI (FQDN), the DNS processing module or DHL may send the IP, and when there is no URI in the cache, a DNS query may be sent to the DNS server 1020.

[0290] According to various embodiments, referring to the following drawings (for example, Fig.16 ) describes in detail the separate execution of DNS caching between the general client application 1610 and the MEC client application 310.

[0291] Fig.18 An example of a DNS resolution operation in a discovery process according to various embodiments of the present disclosure is shown.

[0292] like Fig.18 As shown, Fig.18 A DNS resolution operation is shown for a DNS query of the client application 310. According to an embodiment, the DNS resolution operation may include an operation in which the DNS server 1020 is in a deactivated state (eg, operation 1810) and an operation in which the DNS server 1020 is in an activated state (eg, operation 1830).

[0293] According to an embodiment, the DNS resolution operation in operation 1810 may indicate, for example, an example of an operation in which a local DNS cache (eg, the second DNS cache 1630) for MEC is in a deactivated state in the DNS cache 1010. Fig.18, the client application 310 may transmit a DNS query for the URI to the DNS cache 1010 (in operation 1811), and the DNS cache 1010 may transmit a response (e.g., a DNS cache response) 310 to the DNS query of the client application 310 to the client application 310 (in operation 1813). According to an embodiment, the DNS cache 1010 may store at least one of an application name, a domain name, or an IP address of a domain name of the MEC application. According to an embodiment, when there is no IP address of the MEC application corresponding to the URI in the DNS cache 1010 during the DNS query for the URI of the client application 310 (e.g., the DNS cache is lost), the client application 310 may transmit the DNS query to the DNS server 1020 (in operation 1815), and obtain the IP address from the DNS server 1020 based on the response 1817 corresponding to the DNS query.

[0294] According to an embodiment, the DNS resolution operation in operation 1830 may indicate an example of an operation in which a local DNS cache (eg, the second DNS cache 1630) for MEC is activated in the DNS cache 1010. Fig.18 , the client application 310 may transmit a DNS query for the URI to the DNS cache 1010 through the MSE 330 (in operations 1831 and 1833). According to an embodiment, the DNS cache 1010 may transmit a DNS response to the DNS query to the MSE 330 (in operation 1835). According to an embodiment, when there is no IP address of the MEC application of the corresponding URI in the DNS cache 1010 during the DNS query for the URI of the client application 310 (e.g., DNS cache loss), the MSE 330 may transmit the DNS query to the DNS server 1020 (in operation 1837), receive a response to the DNS query from the DNS server 1020 (in operation 1839), and forward the received response to the client application 310 (in operation 1841).

[0295] According to an embodiment, in the case where there is an IP address of the MEC application corresponding to the URI in the DNS cache 1010 during a DNS query for the URI of the client application 310, access to the MEC application can be performed through the corresponding address. According to an embodiment, in the case of a DNS cache loss in DNS resolution, access to a remote server (e.g., Figure 3A remote server 309) or a MEC application driven by a client application. According to an embodiment, when there is a DNS proxy in the DNS resolution, the DNS proxy can hook the DNS query of the client application and perform DNS resolution according to the MECapp list.

[0296] According to an embodiment, the MSE 330 may support DNS pre-resolution or DNS proxy functions in third-party applications. For example, when the client application 310 for MEC makes a DNS query for accessing a specific service in a state of making a data connection through an existing default PDU session, the DNS proxy may hook the DNS query and transmit the query to the DNS server through the domain name for MEC or look up and return the corresponding MEC domain IP address in the DNS cache 1010. Therefore, the third-party application can provide MEC services without any modification to the separate software and without any separate traffic filtering (or steering) work of the operator.

[0297] Meanwhile, the above signal flow chart can be combined and used with another signal flow chart when necessary. For example, in an authentication operation (e.g., Figures 4 to 6 After at least one of the authentication operations in Figure 7 Execute NAS signaling operations.

[0298] In addition, the above signal flow diagrams may be used and replaced with some of the other signal flow diagrams. Figures 4 to 6 The authentication operation in the figure may be replaced or implemented by an operation used in another figure.

[0299] The various embodiments of the present disclosure described and shown in the specification and the drawings are merely presented to easily explain the technical content of the present disclosure and to help understand specific examples of the present disclosure, and are not intended to limit the scope of the present disclosure. Therefore, the scope of the present disclosure should be interpreted as including, in addition to the embodiments disclosed herein, all changes and modifications derived from the technical concept of the present disclosure.

[0300] Industrial Applicability

[0301] The present disclosure can be used to provide edge computing services in a wireless communication system.

Claims

1. A method performed by a user equipment UE in a wireless communication system, the method comprising: sending a discovery request message to a server to retrieve information associated with an application server, wherein the discovery request message includes location information of the UE and an application client profile; as well as receiving a discovery response message from the server as a response to the discovery request message, the discovery response message including information associated with the application server based on the location information of the UE and the application client profile, The information associated with the application server includes a list of application servers and a uniform resource identifier URI, and The location information of the UE includes a cell identifier ID or a tracking area ID (TAI).

2. The method according to claim 1, wherein: The discovery request message further includes at least one of a discovery policy or a service type.

3. The method according to claim 1, wherein: The information associated with the application server also includes the lifecycle of the URI.

4. The method according to claim 1, wherein: The discovery request message also includes at least one of a device type, a context type, or a dynamic data network name (DNN).

5. A method performed by a server in a wireless communication system, the method comprising: receiving a discovery request message from a user equipment UE to retrieve information associated with an application server, wherein the discovery request message includes location information of the UE and an application client profile; retrieving information associated with the application server based on the location information of the UE and the application client profile; as well as As a response to the discovery request message, a discovery response message is sent to the UE, the discovery response message including information associated with the application server, The information associated with the application server includes a list of application servers and a uniform resource identifier URI, and The location information of the UE includes a cell identifier ID or a tracking area ID (TAI).

6. The method according to claim 5, wherein: The discovery request message further includes at least one of a discovery policy or a service type.

7. The method according to claim 5, wherein: The information associated with the application server also includes the lifecycle of the URI.

8. The method according to claim 5, wherein: The discovery request message also includes at least one of a device type, a context type, or a dynamic data network name (DNN).

9. A user equipment UE in a wireless communication system, the UE comprising: transceiver, and A controller is coupled to the transceiver, wherein the transceiver is configured to: sending a discovery request message to a server to retrieve information associated with an application server, wherein the discovery request message includes location information of the UE and an application client profile; as well as receiving a discovery response message from the server as a response to the discovery request message, the discovery response message including information associated with the application server based on the location information of the UE and the application client profile, The information associated with the application server includes a list of application servers and a uniform resource identifier URI, and The location information of the UE includes a cell identifier ID or a tracking area ID (TAI).

10. The UE according to claim 9, wherein: The discovery request message further includes at least one of a discovery policy or a service type.

11. The UE according to claim 9, wherein: The information associated with the application server also includes the lifecycle of the URI.

12. The UE according to claim 9, wherein: The discovery request message also includes at least one of a device type, a context type, or a dynamic data network name (DNN).

13. A server in a wireless communication system, the server comprising: transceiver, and A controller is coupled to the transceiver, wherein the transceiver is configured to: receiving a discovery request message from a user equipment UE to retrieve information associated with an application server, wherein the discovery request message includes location information of the UE and an application client profile; retrieving information associated with the application server based on the location information of the UE and the application client profile; as well as As a response to the discovery request message, a discovery response message is sent to the UE, the discovery response message including information associated with the application server, The information associated with the application server includes a list of application servers and a uniform resource identifier URI, and The location information of the UE includes a cell identifier ID or a tracking area ID (TAI).

14. The server according to claim 13, wherein: The discovery request message further includes at least one of a discovery policy or a service type.

15. The server according to claim 13, wherein: The information associated with the application server also includes the lifecycle of the URI, and The discovery request message further includes at least one of a device type, a context type, or a dynamic data network name (DNN).

Images