WO2020013677A1 - 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치 - Google Patents

엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치 Download PDF

Info

Publication number
WO2020013677A1
WO2020013677A1 PCT/KR2019/008730 KR2019008730W WO2020013677A1 WO 2020013677 A1 WO2020013677 A1 WO 2020013677A1 KR 2019008730 W KR2019008730 W KR 2019008730W WO 2020013677 A1 WO2020013677 A1 WO 2020013677A1
Authority
WO
WIPO (PCT)
Prior art keywords
mec
electronic device
application
server
information
Prior art date
Application number
PCT/KR2019/008730
Other languages
English (en)
French (fr)
Inventor
이원보
홍영기
이상철
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020190018833A external-priority patent/KR20200007634A/ko
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to EP19835024.1A priority Critical patent/EP3731495B1/en
Priority to CN201980010111.1A priority patent/CN111656754B/zh
Priority to AU2019300978A priority patent/AU2019300978B2/en
Priority to CN202211687835.XA priority patent/CN116232667A/zh
Priority claimed from KR1020190085343A external-priority patent/KR20200007754A/ko
Publication of WO2020013677A1 publication Critical patent/WO2020013677A1/ko
Priority to US16/938,824 priority patent/US11134127B2/en
Priority to US17/486,793 priority patent/US20220014595A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Definitions

  • Various embodiments disclose a method for supporting an edge computing service (eg, a multi-access edge computing service) and an electronic device thereof.
  • an edge computing service eg, a multi-access edge computing service
  • Edge computing techniques may include, for example, multi-access edge computing (MEC) or fog computing.
  • Edge computing technology provides data to an electronic device through a separate server (hereinafter referred to as an 'edge server' or 'MEC server') installed at or near the base station, for example, within or near the base station.
  • a separate server hereinafter referred to as an 'edge server' or 'MEC server'
  • DN external data network
  • Data can be sent and received through the installed edge server.
  • an application of a mobile communication electronic device may transmit and receive edge computing based data on an edge layer (or an edge server application) and an application layer.
  • a secure environment must be provided to execute a service between an electronic device (or user), a network, an operator, or an application provider.
  • an edge server (or MEC application (s)) may be authenticated to an electronic device (or client application) that has been authenticated and authorized (or authorized). You must provide a service (or access).
  • an application of the electronic device may communicate with an application of the edge server, and the edge server may authenticate the application of the electronic device and may authorize an authorization according to the authentication result.
  • the authorized applications may communicate with each other between the electronic device and the edge server.
  • the electronic device and the edge server may perform a discovery (eg, MEC discovery) procedure (or MEC service discovery procedure).
  • each of the applications may separately communicate with the edge server and the application layer in order to perform edge computing-based data transmission.
  • applications may individually perform authentication, authorization, and discovery procedures for using MEC services.
  • a method and apparatus for providing a service by executing a MEC application based on a more optimal MEC host for an electronic device is disclosed.
  • a service discovery operation is disclosed with respect to a method and apparatus for performing discovery by an electronic device (eg, a MEC service module) rather than an individual application.
  • an electronic device eg, a MEC service module
  • the MEC discovery may be performed by an electronic device (eg, a MEC service module) rather than an individual application, and thus, the MEC host may perform discovery more quickly and efficiently, and may be provided with an optimal quality.
  • an electronic device eg, a MEC service module
  • the MEC host may perform discovery more quickly and efficiently, and may be provided with an optimal quality.
  • a method and apparatus for providing a stable edge computing service by collectively managing a state of applications and a state of an electronic device through a MEC service module installed in an electronic device are disclosed.
  • An electronic device may include a network interface and a processor, and the processor may be configured to connect to at least one external server in the base station or through the base station using the network interface.
  • the processor may be configured to connect to at least one external server in the base station or through the base station using the network interface.
  • Obtain information about applications that can be provided by at least one external server select an external server including an application corresponding to a specified condition based on the information about the applications, and transmit data with the selected external server. Can be done.
  • An electronic device includes a network interface and a processor, wherein the processor obtains an app list of an application that can be serviced from a designated external server based on a discovery policy, and is based on the app list. Obtaining information related to an application associated with a client application of the electronic device and to be accessed from the designated external server, determining a host for data transmission based on the obtained information, and performing data transmission with the host can do.
  • An electronic device includes a network interface and a processor, wherein the processor obtains an app list of an application that can be serviced from a designated external server based on a discovery policy, and obtains a context of a client application. Based on the event related to the generation, obtain information related to the application associated with the client application from the designated external server, select a host for data transmission based on the obtained information, and Data transfer can be performed.
  • various embodiments of the present disclosure may include a computer-readable recording medium having recorded thereon a program for executing the method on a processor.
  • a service may be provided by executing a MEC application based on a more optimal MEC host for the electronic device.
  • the service discovery operation may be performed by an electronic device (eg, a service enabler) instead of an individual application.
  • the MEC discovery may not be performed by an individual application but may be performed by an electronic device (eg, a service enabler), so that discovery may be performed more quickly and efficiently, and an optimal quality may be provided. You can select the MEC host.
  • a stable edge computing service may be provided by integrally managing states of applications and states of electronic devices through a MEC service module installed in an electronic device.
  • FIG. 1 is a block diagram of an electronic device in a network environment according to various embodiments.
  • FIG. 2 is a block diagram of an electronic device for supporting legacy network communication and 5G network communication according to various embodiments.
  • FIG. 3 is a diagram schematically illustrating a MEC technology in a network environment according to various embodiments.
  • FIG. 4 is a diagram illustrating an electronic device and a MEC system for performing MEC-based data transmission in a network environment according to various embodiments.
  • FIG. 5 is a diagram illustrating an electronic device and an external server for supporting a MEC-based service in a network environment according to various embodiments.
  • FIG. 6 is a diagram illustrating an authentication and discovery procedure for supporting a MEC service according to various embodiments.
  • FIG. 7 is a flowchart illustrating a method of operating an electronic device according to various embodiments of the present disclosure.
  • FIG. 8 is a flowchart illustrating an operation method for an authentication procedure in an electronic device according to various embodiments of the present disclosure.
  • FIG. 9 is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • FIG. 10 is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • FIG. 11 is a flowchart illustrating an operating method for an authentication procedure in an electronic device according to various embodiments of the present disclosure.
  • FIG. 12 is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • FIG. 13 is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • FIG. 14 is a flowchart illustrating an operation method for an authentication procedure in an electronic device according to various embodiments of the present disclosure.
  • 15A is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • 15B is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • 16 is a flowchart illustrating a method of operating an electronic device according to various embodiments of the present disclosure.
  • 17 is a diagram illustrating an example policy update operation in an electronic device according to various embodiments of the present disclosure.
  • FIG. 18 is a diagram illustrating an example of a PDU session establishment operation in an electronic device according to various embodiments.
  • 19 is a flowchart illustrating a method of checking whether MEC-based data transmission is possible in an electronic device according to various embodiments of the present disclosure.
  • 20 is a diagram illustrating an example of a discovery procedure according to various embodiments of the present disclosure.
  • 21 is a flowchart illustrating an operation method for a discovery procedure in an electronic device according to various embodiments of the present disclosure.
  • 22 is a flowchart illustrating an operation method for a discovery procedure in an electronic device according to various embodiments of the present disclosure.
  • 23 is a diagram illustrating an example of a discovery procedure according to various embodiments.
  • 24 is a flowchart illustrating an operation method for a discovery procedure in an electronic device according to various embodiments of the present disclosure.
  • 25 is a diagram illustrating an example of a discovery procedure according to various embodiments.
  • 26 is a flowchart illustrating an operation method for a discovery procedure in an electronic device according to various embodiments of the present disclosure.
  • FIG. 27 is a diagram illustrating an example of an operation of obtaining an app list in a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 28 is a diagram illustrating an example in which an app list is provided according to various embodiments.
  • 29 is a diagram illustrating a life cycle of an application according to various embodiments.
  • FIG. 30 is a diagram illustrating an example of a context creation operation in a discovery procedure according to various embodiments.
  • 31 is a diagram illustrating an example of a context creation operation in a discovery procedure according to various embodiments.
  • 32 is a diagram illustrating an example of a context creation operation in a discovery procedure according to various embodiments.
  • FIG 33 is a diagram illustrating an example of a MEC host selection operation in a discovery procedure according to various embodiments.
  • FIG. 34 is a diagram illustrating an example of separately operating a local DNS cache for an MEC in an electronic device according to various embodiments of the present disclosure.
  • 35 is a diagram illustrating an example of operating a local DNS cache for an MEC in an MSE in an electronic device according to various embodiments of the present disclosure.
  • 36 is a diagram illustrating an operation of using an IP address for a domain name according to various embodiments.
  • 37 is a signal flow diagram for sharing an IP address according to various embodiments.
  • FIG. 38 is a flowchart illustrating a method of using an IP address for a domain name in an electronic device according to various embodiments of the present disclosure.
  • 39 is a flowchart illustrating a method of requesting an IP address from an electronic device according to various embodiments of the present disclosure.
  • FIG. 40 is a flowchart illustrating a method of performing MEC-based data transmission using an IP address in an electronic device according to various embodiments of the present disclosure.
  • FIG. 41 is a diagram illustrating an example of a DNS resolving operation in a discovery procedure according to various embodiments.
  • FIG. 41 is a diagram illustrating an example of a DNS resolving operation in a discovery procedure according to various embodiments.
  • FIG. 42 is a diagram illustrating an example of a service close operation in a discovery procedure according to various embodiments.
  • 43 is a diagram illustrating an example of a service close operation in a discovery procedure according to various embodiments.
  • FIG. 1 is a block diagram of an electronic device 101 in a network environment 100 according to various embodiments.
  • the electronic device 101 communicates with the electronic device 102 through a first network 198 (eg, a short range wireless communication network), or the second network 199.
  • the electronic device 104 may communicate with the server 108 through a long range wireless communication network.
  • the electronic device 101 may communicate with the electronic device 104 through the server 108.
  • the electronic device 101 may include a processor 120, a memory 130, an input device 150, an audio output device 155, a display device 160, an audio module 170, and a sensor module. 176, interface 177, haptic module 179, camera module 180, power management module 188, battery 189, communication module 190, subscriber identification module 196, or antenna module 197.
  • the components may be included.
  • at least one of the components may be omitted or one or more other components may be added to the electronic device 101.
  • some of these components may be implemented in one integrated circuit.
  • the sensor module 176 eg, fingerprint sensor, iris sensor, or illuminance sensor
  • the display device 160 eg, display
  • the processor 120 executes software (eg, the program 140) to execute at least one other component (eg, hardware or software component) of the electronic device 101 connected to the processor 120. It can control and perform various data processing or operations. According to one embodiment, as at least part of the data processing or operation, processor 120 may store instructions or data received from other components (eg, sensor module 176 or communication module 190) in volatile memory. 132, process instructions or data stored in the volatile memory 132, and store the result data in the non-volatile memory 134. According to an embodiment, the processor 120 may include a main processor 121 (eg, a central processing unit (CPU) or an application processor (AP)), and a coprocessor that may operate independently or together.
  • main processor 121 eg, a central processing unit (CPU) or an application processor (AP)
  • the coprocessor 123 (eg, a graphic processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)). Can be. Additionally or alternatively, the coprocessor 123 may be configured to use lower power than the main processor 121 or to be specialized for its designated function. The coprocessor 123 may be implemented separately from or as part of the main processor 121.
  • GPU graphic processing unit
  • ISP image signal processor
  • CP communication processor
  • the coprocessor 123 may, for example, replace the main processor 121 while the main processor 121 is in an inactive (eg, sleep) state, or the main processor 121 may be replaced by the main processor 121. Together with the main processor 121 while in an active (eg, running an application) state, at least one of the components of the electronic device 101 (eg, display device 160, sensor module 176). ), Or at least some of the functions or states associated with the communication module 190. According to one embodiment, the coprocessor 123 (eg, image signal processor or communication processor) may be implemented as part of other functionally related components (eg, camera module 180 or communication module 190). have.
  • the memory 130 may store various data used by at least one component (eg, the processor 120 or the sensor module 176) of the electronic device 101.
  • the data may include, for example, software (eg, the program 140) and input data or output data for a command related thereto.
  • the memory 130 may include a volatile memory 132 or a nonvolatile memory 134.
  • 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 an application 146. .
  • OS operating system
  • middleware middleware
  • application application
  • the input device 150 may receive a command or data to be used for a component (for example, the processor 120) of the electronic device 101 from the outside (for example, a user) of the electronic device 101.
  • the input device 150 may include, for example, a microphone, a mouse, a keyboard, or a digital pen (eg, a stylus pen).
  • the sound output device 155 may 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 multimedia playback or recording playback, and the receiver may be used to receive an incoming call.
  • the receiver may be implemented separately from or as part of a speaker.
  • the display device 160 may visually provide information to the outside (eg, a user) of the electronic device 101.
  • the display device 160 may include, for example, a display, a hologram device, or a projector and a control circuit for controlling the device.
  • the display device 160 may be a touch circuitry configured to sense a touch, or a sensor circuit configured to measure the strength of a force generated by the touch (eg, a pressure sensor). It may include.
  • the audio module 170 may convert sound into an electric signal or, conversely, convert an electric signal into a sound. According to an embodiment, the audio module 170 may acquire sound through the input device 150, or may output an external electronic device (for example, a sound output device 155 or directly or wirelessly connected to the electronic device 101). Sound may be output through the electronic device 102 (for example, a speaker or a headphone).
  • an external electronic device for example, a sound output device 155 or directly or wirelessly connected to the electronic device 101. Sound may be output through the electronic device 102 (for example, a speaker or a headphone).
  • the sensor module 176 detects an operating state (eg, power or temperature) of the electronic device 101, or an external environmental state (eg, a user state), and generates an electrical signal or data value corresponding to the detected state. can do.
  • the sensor module 176 may include, for example, a gesture sensor, a gyro sensor, a barometer sensor, a magnetic sensor, and an acceleration sensor. ), Grip sensor, proximity sensor, color sensor (e.g. red, green, blue sensor), infrared (IR) sensor, biometric sensor, temperature It may include a temperature sensor, a humidity sensor, or an illuminance sensor.
  • the interface 177 may support one or more specified protocols that may be used to directly or wirelessly connect with an external electronic device (eg, the electronic device 102) of the electronic device 101.
  • 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.
  • HDMI high definition multimedia interface
  • USB universal serial bus
  • SD secure digital
  • connection terminal 178 may include a connector through which the electronic device 101 may be physically connected to an external electronic device (eg, the electronic device 102).
  • the connection terminal 178 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).
  • the haptic module 179 may convert an electrical signal into a mechanical stimulus (eg, vibration or movement) or an electrical stimulus that can be perceived by the user through the sense of touch or movement.
  • the haptic module 179 may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.
  • the camera module 180 may capture still images and videos. According to one embodiment, the camera module 180 may include one or more lenses, image sensors, image signal processors, or flashes.
  • the power management module 188 may manage power supplied to the electronic device 101.
  • the power management module 188 may be implemented, for example, as at least part of a power management integrated circuit (PMIC).
  • PMIC power management integrated circuit
  • the battery 189 may supply power to at least one component of the electronic device 101.
  • the battery 189 may include, for example, a non-rechargeable primary cell, a rechargeable secondary cell, or a fuel cell.
  • the communication module 190 may establish a direct (eg wired) communication channel or wireless communication channel between the electronic device 101 and an external electronic device (eg, the electronic device 102, the electronic device 104, or the server 108). Establish and perform communication over established communication channels.
  • the communication module 190 may operate independently of the processor 120 (eg, an application processor) and include one or more communication processors supporting direct (eg, wired) or wireless communication.
  • the communication module 190 is a wireless communication module 192 (eg, a cellular communication module, a near field communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (eg It may include a local area network (LAN) communication module, or a power line communication module.
  • GNSS global navigation satellite system
  • the corresponding communication module of these communication modules may be 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. cellular network, the Internet). Or communicate with an external electronic device via a computer network (eg, a telecommunication network such as a LAN or a wide area network).
  • a computer network e.g, a telecommunication network such as a LAN or a wide area network.
  • These various types of communication modules may be integrated into one component (eg, a single chip) or may be implemented by a plurality of components (eg, a plurality of chips) separate from each other.
  • the wireless communication module 192 communicates with the first network 198 or the second network 199 using subscriber information (eg, international mobile subscriber identity (IMSI)) stored in the subscriber identification module 196.
  • subscriber information eg, international mobile subscriber identity (IMSI)
  • IMSI international mobile subscriber identity
  • the antenna module 197 may transmit or receive a signal or power to an external (eg, an external electronic device) or from the outside.
  • the antenna module 197 may include one antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (eg, a PCB).
  • the antenna module 197 may include a plurality of antennas. In this case, at least one antenna suitable for the communication scheme used in the communication network, such as the first network 198 or the second network 199, may be, for example, communicated from the plurality of antennas by the communication module 190. Can be selected.
  • the signal or power may be transmitted or received between the communication module 190 and the external electronic device through the at least one selected antenna.
  • other components eg, RFICs
  • peripheral devices eg, a bus, a general purpose input and output (GPIO), a serial peripheral interface (SPI), or a mobile industry processor interface (MIPI)
  • GPIO general purpose input and output
  • SPI serial peripheral interface
  • MIPI mobile industry processor interface
  • the 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 or different type as the electronic device 101.
  • all or part of operations executed in the electronic device 101 may be executed in one or more external devices of the external electronic devices 102, 104, or 108.
  • the electronic device 101 when the electronic device 101 needs to perform a function or service automatically or in response to a request from a user or another device, the electronic device 101 instead of executing the function or service itself.
  • the one or more external electronic devices 102 and 104 may be requested to perform at least a part of the function or the service.
  • the one or more external electronic devices 102 and 104 that have received the request execute at least some of the requested function or service, or additional functions or services related to the request, and return the result of the execution to the electronic device 101. I can deliver it.
  • the electronic device 101 may process the result as it is or additionally and provide it as at least part of a response to the request.
  • cloud computing, distributed computing, or client-server computing technology may be used.
  • the electronic device 101 may be a device of various types.
  • the electronic device 101 may include, for example, a portable communication device (eg, a smart phone), a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance.
  • a portable communication device eg, a smart phone
  • portable multimedia device e.g., a portable multimedia device
  • portable medical device e.g., a portable medical device
  • camera e.g., a camera
  • a wearable device e.g., a smart bracelet
  • any (eg. first) component is referred to as “coupled” or “connected” with or without the term “functionally” or “communicatively” to another (eg second) component. If so, it means that any component can be connected directly to the other component (eg, by wire), wirelessly, or via a third component.
  • module may include a unit implemented in hardware, software, or firmware, for example, logic, logic block, component. Or, interchangeably with the term circuit.
  • the module may be an integral part or a minimum unit or part of the component, which performs one or more functions.
  • the module may be implemented in the form of an application-specific integrated circuit (ASIC).
  • ASIC application-specific integrated circuit
  • Various embodiments of this document may include one or more stored in a storage medium (eg, internal memory 136 or external memory 138) that can be read by a machine (eg, electronic device 101). It may be implemented as software (eg, program 140) that includes instructions.
  • a processor eg, the processor 120 of the device (eg, the electronic device 101) may call and execute at least one command among one or more instructions stored from the storage medium. This enables the device to be operated to perform at least one function in accordance with the at least one command invoked.
  • the one or more instructions may include compiler generated code or code that may be executed by an interpreter.
  • the device-readable storage medium may be provided in the form of a non-transitory storage medium.
  • 'non-transitory' means only that the storage medium is a tangible device and does not contain a signal (e.g. electromagnetic wave), and the term is used when the data is stored semi-permanently on the storage medium. It does not distinguish cases where it is temporarily stored.
  • a signal e.g. electromagnetic wave
  • a method according to various embodiments disclosed in the present disclosure may be included in a computer program product.
  • the computer program product may be traded between the seller and the buyer as a product.
  • the computer program product may be distributed in the form of a device-readable storage medium (eg CD-ROM, compact disc read only memory) or through an application store (eg Play Store TM ) or two user devices (eg Can be distributed (eg, downloaded or uploaded) directly, online between smartphones.
  • a device-readable storage medium eg CD-ROM, compact disc read only memory
  • an application store eg Play Store TM
  • two user devices eg Can be distributed (eg, downloaded or uploaded) directly, online between smartphones.
  • at least a portion of the computer program product may be stored at least temporarily or temporarily created on a device-readable storage medium such as a server of a manufacturer, a server of an application store, or a memory of a relay server.
  • each component eg, a module or a program of the above-described components may include a singular or plural entity.
  • one or more of the aforementioned components or operations may be omitted, or one or more other components or operations may be added.
  • a plurality of components eg, a module or a program
  • the integrated component may perform one or more functions of the component of each of the plurality of components the same as or similar to that performed by the corresponding component of the plurality of components before the integration. .
  • operations performed by a module, program, or other component may be executed sequentially, in parallel, repeatedly, or heuristically, or one or more of the operations may be executed in a different order. May be omitted, omitted, or one or more other actions may be added.
  • FIG. 2 is a block diagram 200 of an electronic device 101 for supporting legacy network communication and 5G network communication according to various embodiments.
  • 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, and a second communication processor 212.
  • the electronic device 101 may further include a processor 120 and a memory 130.
  • the network 199 may include a first network 292 and a second network 294.
  • the electronic device 101 may further include at least one of the components described in FIG. 1, and the network 199 may further include at least one other network.
  • 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 form at least a portion of the wireless communication module 192.
  • the fourth RFIC 228 may be omitted or included as part of the third RFIC 226.
  • the first communication processor 212 may support the establishment of a communication channel of a band to be used for wireless communication with the first network 292, and legacy network communication through the established communication channel.
  • the first network 292 may be a legacy network including a second generation (2G), 3G, 4G, or long term evolution (LTE) network.
  • the second communication processor 214 establishes a communication channel corresponding to a designated band (for example, about 6 GHz to about 60 GHz) of bands to be used for wireless communication with the second network 294, and 5G network communication through the established communication channel.
  • a designated band for example, about 6 GHz to about 60 GHz
  • the second network 294 may be a 5G network defined in 3GPP.
  • the first communication processor 212 or the second communication processor 214 corresponds to another designated band (eg, about 6 GHz or less) of the bands to be used for wireless communication with the second network 294. It can support the establishment of a communication channel, and 5G network communication through the established communication channel.
  • the first communication processor 212 and the second communication processor 214 may be implemented in a single chip or a single package.
  • the first communication processor 212 or the second communication processor 214 may be formed in a single chip or a single package with the processor 120, the coprocessor 123, or the communication module 190. have.
  • the first RFIC 222 transmits a baseband signal generated by the first communication processor 212 to the first network 292 (eg, a legacy network) for transmission, from about 700 MHz to about 3 GHz. Can be converted into a radio frequency (RF) signal.
  • RF radio frequency
  • an RF signal is obtained from a first network 292 (e.g., legacy network) via an antenna (e.g., first antenna module 242) and via an RFFE (e.g., first RFFE 232). It can be preprocessed.
  • the first RFIC 222 may convert the preprocessed RF signal into a baseband signal for processing by the first communication processor 212.
  • the second RFIC 224 upon transmission, uses the baseband signal generated by the first communication processor 212 or the second communication processor 214 for the second network 294 (eg, 5G network).
  • a sub-band eg, about 6 GHz or less
  • a 5G Sub6 RF signal can be converted into an RF signal (hereinafter, referred to as a 5G Sub6 RF signal).
  • a 5G Sub6 RF signal is obtained from a second network 294 (eg 5G network) via an antenna (eg second antenna module 244), and RFFE (eg second RFFE 234). Can be pre-treated via.
  • the second RFIC 224 may convert the preprocessed 5G Sub6 RF signal into a baseband signal for processing by the corresponding communication processor of the first communication processor 212 or the second communication processor 214.
  • the third RFIC 226 uses the baseband signal generated by the second communication processor 214 in the 5G Above6 band (eg, about 6 GHz to about 60 GHz) to be used in the second network 294 (eg, 5G network). Can be converted into a signal (hereinafter, referred to as a 5G Above6 RF signal).
  • a 5G Above6 RF signal may be obtained from the second network 294 (eg, 5G network) via an antenna (eg, antenna 248) and preprocessed via third RFFE 236.
  • the third RFIC 226 may convert the preprocessed 5G Above6 RF signal into a baseband signal for processing by the second communication processor 214.
  • the third RFFE 236 may be formed as part of the third RFIC 226.
  • the electronic device 101 may include the fourth RFIC 228 separately or at least as a part of the third RFIC 226.
  • the fourth RFIC 228 converts the baseband signal generated by the second communication processor 214 into an RF signal (hereinafter, IF signal) in an intermediate frequency band (for example, about 9 GHz to about 11 GHz).
  • IF signal may be transferred to the third RFIC 226.
  • the third RFIC 226 may convert the IF signal into a 5G Above6 RF signal.
  • a 5G Above6 RF signal may be received from the second network 294 (eg, 5G network) via an antenna (eg, 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 for processing by the second communication processor 214.
  • the first RFIC 222 and the second RFIC 224 may be implemented as a single chip or at least part of a single package.
  • the first RFFE 232 and the second RFFE 234 may be implemented as a single chip or at least part of a single package.
  • at least one antenna module of the first antenna module 242 or the second antenna module 244 may be omitted or combined with another antenna module to process RF signals of a corresponding plurality of bands.
  • the third RFIC 226 and the antenna 248 may be disposed on the same substrate to form the third antenna module 246.
  • the wireless communication module 192 or the processor 120 may be disposed on a first substrate (eg, a main PCB).
  • the third RFIC 226 is located in some areas (eg, the bottom) of a second substrate (eg, a sub PCB) that is separate from the first substrate, and the antenna is located in another area (eg, the top).
  • 248 may be disposed to form a third antenna module 246.
  • This may reduce, for example, the loss (eg, attenuation) of a high frequency band (eg, about 6 GHz to about 60 GHz) used by 5G network communications by the transmission line.
  • the electronic device 101 may improve the quality or speed of communication with the second network 294 (eg, a 5G network).
  • the antenna 248 may be formed as an antenna array including a plurality of antenna elements that may be used for beamforming.
  • the third RFIC 226 may include a plurality of phase shifters 238 corresponding to the plurality of antenna elements, for example, as part of the third RFFE 236.
  • each of the plurality of phase converters 238 may convert a phase of a 5G Above6 RF signal to be transmitted to the outside of the electronic device 101 (eg, a base station of a 5G network) through a corresponding antenna element. .
  • each of the plurality of phase converters 238 may convert a phase of the 5G Above6 RF signal received from the outside to the same or substantially the same phase through a corresponding antenna element. This enables transmission or reception through beamforming between the electronic device 101 and the outside.
  • the second network 294 may operate independently of the first network 292 (eg, legacy network) (eg, Stand-Alone (SA)), or may be connected to and run (eg, Non-Stand Alone (NSA)).
  • a 5G network may have only an access network (eg, 5G radio access network (RAN) or next generation RAN (NG RAN)) and no core network (eg, next generation core (NGC)).
  • the electronic device 101 may access an external network (eg, the Internet) under the control of a core network (eg, an evolved packed core (EPC)) of the legacy network after accessing the access network of the 5G network.
  • RAN radio access network
  • NG RAN next generation RAN
  • EPC evolved packed core
  • Protocol information (e.g., LTE protocol information) for communication with a legacy network or protocol information (e.g., New Radio (NR) protocol information) for communication with a 5G network is stored in the memory 230, so that other components (e.g., processors 120, first communication processor 212, or second communication processor 214.
  • NR New Radio
  • the 5G network technology described in the drawings and the description refers to a standard specification defined by an international telecommunication union (ITU) or 3GPP (eg, a technical specification (TS) 23.501), and the MEC technology is an ETSI (European telecommunication standards). Reference may be made to standard specifications (eg, MEC 001 to MEC 016) defined by an institute. In the following, the content is described based on the MEC technology, but the same or similar principles may be applied to the fog computing technology defined by the openfog consortium.
  • ITU international telecommunication union
  • 3GPP eg, a technical specification (TS) 23.501
  • ETSI European telecommunication standards
  • standard specifications eg, MEC 001 to MEC 016
  • the content is described based on the MEC technology, but the same or similar principles may be applied to the fog computing technology defined by the openfog consortium.
  • FIG. 3 is a diagram schematically illustrating a MEC technology in a network environment 300 according to various embodiments.
  • each of the components included in the network environment 300 may mean a physical entity unit or perform a separate function. It may mean a software unit or a module unit.
  • the electronic device 101 may mean a device used by a user.
  • the electronic device 101 may be, for example, a terminal, a user equipment (UE), a mobile station, a subscriber station, a remote terminal, or a wireless terminal. ), Or a user device.
  • UE user equipment
  • the access network (AN) 302 may provide a channel for wireless communication with the electronic device 101.
  • the AN 302 may be a radio access network (RAN), a base station (eNB), an eNodeB (eNB), a 5G node (5G node), a transmission / reception point (TRP), or a 5th generation NodeB (5GNB). May mean.
  • RAN radio access network
  • eNB base station
  • eNodeB eNodeB
  • 5G node 5G node
  • TRP transmission / reception point
  • 5GNB 5th generation NodeB
  • the core network (CN) 303 may include subscriber information of the electronic device 101, mobility of the electronic device 101, access authorization of the electronic device 101, and data packets. At least one of the traffic (traffic), or the charging policy may be managed.
  • CN 303 is at least one of a user plane function (UPF) node, an access & mobility management function (AMF) node, a session management function (SMF) node, an unified data management (UDM) node, or a policy control function (PCF) node. It may include.
  • UPF user plane function
  • AMF access & mobility management function
  • SMF session management function
  • UDM unified data management
  • PCF policy control function
  • a data network (eg, a first DN 304-1 and a second DN 304-2) is transmitted to the electronic device 101 through the CN 303 and the AN 302.
  • a service eg, an internet service or an IP multimedia subsystem (IMS) service
  • IMS IP multimedia subsystem
  • DNs 304-1 and 304-2 may be managed by a telecommunications provider.
  • the first DN 304-1 may be connected to a remote server 306, and the second DN 304-2 may be connected to an edge server 305 (eg, an MEC server).
  • an edge server 305 eg, an MEC server
  • the remote server 306 may provide content associated with the application.
  • the remote server 306 may be managed by the content provider.
  • the plurality of applications (eg, the first application (first app) 310-1, the second application (second app) 310-2,...) May be used in the electronic device 101. Can be installed (or stored).
  • a plurality of applications for example, be one of the applications provided by the default application, carrier pre-installed on the electronic device 101, or a 3 rd party (party) applications.
  • the plurality of applications may include data transmission rate, latency (or latency), reliability, the number of electronic devices accessed to the network, the network connection period of the electronic device 101, or the average data usage. Different network services may be required based on at least one.
  • Different network services may include, for example, enhanced mobile broadband (eMBB), ultra-reliable and low latency communication (URLLC), or massive machine type communication (mMTC).
  • eMBB may mean, for example, a network service requiring a high data transmission rate and a low latency, such as a smartphone service.
  • URLLC may refer to a network service requiring low latency and high reliability, such as, for example, a disaster relief network or a vehicle to everything (V2X).
  • V2X vehicle to everything
  • mMTC may refer to a network service that does not require low latency while being connected to a plurality of entities such as the Internet of things (IoT).
  • IoT Internet of things
  • the edge server 305 may be located inside a base station (eg, AN 302) to which the electronic device 101 is connected, or at a location geographically close to the base station, and the remote server ( Content at least partially identical to the content provided by 306 may be provided.
  • the edge server 305 may be disposed inside the CN 303 or may be disposed on a separate user computer.
  • the remote server 306 provides content to the electronic device 101 regardless of the location of the electronic device 101, while the edge server 305 is located at a location adjacent to the edge server 305. It may have locality to provide content to the device 101.
  • the plurality of applications 310-1 and 310-2 of the electronic device 101 perform data transmission with the remote server 306, or edge computing (eg, with the edge server 305). Data transmission based on MEC) can be performed.
  • the plurality of applications 310-1 and 310-2 of the electronic device 101 may remotely based on a required service type (eg, a network service type, an application service type, and / or a requirement).
  • Data transmission may be performed with the server 306 or data based on edge computing with the edge server 305.
  • the first application 310-1 may perform data transmission with the remote server 306.
  • the second application (second app) 310-2 may perform data transmission with the edge server 305.
  • the plurality of applications 310-1 and 320-2 may be based on whether the electronic device 101 (or the application) is subscribed to the edge computing service without considering a separate requirement. Data transfer can be performed. According to another embodiment, if the application is an application provided by a service provider, the application may perform data transmission without considering a separate request or subscription of an edge computing service.
  • FIG. 4 is a diagram illustrating an electronic device 101 and a MEC system 405 that perform MEC-based data transmission in a network environment 400 according to various embodiments.
  • the MEC host 447 illustrated in FIG. 4 may correspond to the edge server 305 as described in the description with reference to FIG. 3, and although not illustrated in FIG. 4, the electronic device ( 101 is wirelessly communicated via AN 302 disposed between MEC host 447 or MEC Management Proxy (MMP) server 430 (e.g., a life cycle management (LCM) proxy server). Can be performed.
  • MMP MEC Management Proxy
  • LCM life cycle management
  • FIG. 4 illustrates a service agent 412 (eg, MSA, multi-access) in the electronic device 101, for example, for an edge computing service (eg, MEC service).
  • network entities interacting with a MEC service module (or MEC service layer) 410 including a service agent and a service enabler 414 (eg, a multi-access service enabler).
  • MEC service module or MEC service layer
  • service enabler 414 eg, a multi-access service enabler
  • the MEC user plane may include applications (or applications) to provide a service to a user of the electronic device 101.
  • Client application e.g., first App 310-1, second App 310-2, ...) and MEC host 447 (e.g., edge server 305 (or MEC server) MEC Apps (or edge applications or multi-access edge (ME) applications) (e.g., first MEC App 460-1, second MEC App 460-2)
  • MEC control plane is a path for transmitting control information of an edge computing system (eg, the MEC system 405) for user data packets transmitted and received on the user plane (eg, a control path). control path)).
  • a control path (eg, MEC) interworking between the service agent (eg, MSA) 412 and the service enabler (eg, MSE) 414 and the MMP server 430.
  • the applications of the electronic device 101 eg, the first App 310-1 and the second App 310-2
  • the MEC applications of the MEC host 447 eg, : MEC data service
  • a data path eg, a MEC user plane
  • the electronic device 101 may perform data communication with a DNS server through a domain name system (DNS) query / response data path.
  • DNS domain name system
  • the MEC system 405 may be located in a network of a carrier and used for data transmission based on the MEC.
  • the MEC system 405 may include an MMP server 430, an operation support system (OSS) 435, an orchestrator 440, a ME platform manager 445, and a MEC host 447. Can be.
  • OSS operation support system
  • ME platform manager 445 ME platform manager 445
  • MEC host 447 MEC host 447.
  • the MMP server 430 is a user application interface (eg: MEC system 405) to an edge computing system (e.g., the MEC system 405) on a user equipment (e.g., the electronic device 101).
  • ETSI MEC 016 standard For example, the electronic device 101 may request the MMP server 430 for information (eg, a list of available applications) regarding the application (s) that the MEC system 405 can provide, and request the MEC system 405. You can pass requests to launch applications (such as context creation) and stop requests (such as context termination).
  • the MMP server 430 manages the life cycle (eg,) of applications installed on the MEC system 405 (eg, 460-1, 460-2, ). Can be done.
  • the MMP server 430 receives a request from the electronic device 101 and forwards the received request to the MEC system 405 (eg, the OSS 435 and the orchestrator 440). Management of the life cycle of the applications (for example, 460-1, 460-2, ...) installed in the 405 may be performed.
  • the OSS 435 may grant the instantiation of an application or the termination of the application.
  • An instance of an application may be a set of instructions (or instructions) for executing an application, and instantiation may refer to an operation of a processor of the MEC host 447 executing the MEC application through the instance.
  • orchestrator 440 is one of available resources, available MEC services, application rules and requirements, operator policies, or topology. Based on at least one, you can manage and maintain the overall functionality of the MEC-based data transfer. For example, the orchestrator 440 selects a MEC host suitable for the application of the electronic device 101 (eg, the MEC host 447 of FIG. 4), or triggers or terminates the instantiation of the application. Can be.
  • a MEC host suitable for the application of the electronic device 101 (eg, the MEC host 447 of FIG. 4), or triggers or terminates the instantiation of the application. Can be.
  • the MEP manager 445 may manage at least one of an application rule, a requirement, a service approval, or a traffic rule.
  • the MEC host 447 may include at least one MEC application corresponding to at least one application (for example, 310-1, 310-2, ...) installed in the electronic device 101. 460-1, 460-2).
  • the MEC host 447 may include an ME platform 450.
  • the ME platform 450 may receive traffic rules from the MEP manager 445 and adjust traffic rules on the MEC user plane.
  • the MEC host 447 may include a MEC enabling layer (MEL) server 455 configured to exchange data with the MEC service module (or MEC service layer) 410 of the electronic device 101.
  • MEL MEC enabling layer
  • the MEL server 455 may perform the same or similar function as the MMP server 430, for example.
  • the MEC service module 410 may perform control data exchange described below with the MMP server 430 or the MEL server 455.
  • the MEL server 455 may be an application (or service) running on the MEC host 447.
  • the MEL server 455 may be disposed outside the MEC host 427.
  • the MEL server 455 may be connected to at least one of the OSS 435, the orchestrator 440, or the MEP manager 445. According to an embodiment, the MEL server 455 may not be included in a component of the MEC host 447. For example, in FIG. 4, the MEL server 455 may be omitted (or excluded).
  • control data may include data about at least one of application discovery, life cycle synchronization (LCS), or authentication procedure that the MEC system 405 may provide. It may include.
  • LCS life cycle synchronization
  • the electronic device 101 may include an application layer 446 (eg, the application 146 of FIG. 1) including a plurality of applications (eg, 310-1, 310-2, ). And a MEC service module 410 for integrally managing the MEC-based data transmission.
  • Each of the application layer 446 and the MEC service module 410 may mean a software or a program module.
  • the software or program module may be composed of instructions executed by a processor (eg, the processor 120 of FIG. 1) included in the electronic device 101.
  • the electronic device 101 processes data for each layer and transmits data through a network interface 420 (or a communication circuit) (for example, the wireless communication module 192 of FIG. 1 or 2). can do.
  • the network interface 420 may be at least part of the coprocessor 123 or the communication module 190 of FIG. 1.
  • the MEC service module (or MEC service layer) 410 configured as a layer separate from the application layer 446 is illustrated.
  • at least a part of the MEC service module 410 is an application layer ( 446 may be configured in the form of an application included in.
  • the MEC service module 410 may include a service agent (eg, MSA) 412 and a service enabler (eg, MSE) 414.
  • the MEC service module 410 may be configured to authenticate and authorize (eg, authentication / authorization) and policies (eg, application routing policy) in accordance with various embodiments.
  • a discovery policy (or a monitoring policy) (eg, a list of information to be monitored) may be received and processed.
  • the MEC service module 410 receives an authentication / authorization (AA) and a policy (eg, a list of information to be monitored) using a service agent (eg, MSA) 412, and a service enabler. (Eg, MSE) 414 may be used to perform route establishment and MEC discovery procedures based on the received policy.
  • AA authentication / authorization
  • a policy eg, a list of information to be monitored
  • the MEC service module 410 may include at least one of an entity (eg, a service agent (MSA) 412 or a service enabler (MSE) 414) within the MEC service module 410. Either one may be operable to perform monitoring for the MEC discovery condition and may be operable to communicate the results monitored by that entity to the service enabler (MSE) 414.
  • the MEC service module 410 may enable (or receive) AA and discovery related policies via a service agent (MSA) 412.
  • MSA service agent
  • the service agent 412 monitors the MEC discovery condition, and when the condition is met, the MEC is sent to the service enabler (MSE) 414.
  • the discovery request may be forwarded and the MEC discovery procedure may be performed through the service enabler 414.
  • the service enabler 414 performs monitoring
  • the service agent 412 forwards the policy to the service enabler 414, and the service enabler 414 passes the policy.
  • the MEC discovery procedure can be performed when the conditions are met.
  • the service agent 412 may monitor context information of the electronic device 101.
  • the context information may be, for example, information about an application supporting data transmission based on the MEC among applications (eg, 310-1, 310-2, ...) installed in the electronic device 101, the electronic device 101. ) May mean at least one of information related to mobility of the mobile terminal, life cycle information of an application, information about a state of the electronic device 101, information obtained by a sensor, or network performance.
  • the information related to the mobility of the electronic device 101 may include, for example, information indicating the movement of the electronic device 101, information related to a change of a base station connected to the electronic device 101, or an area to which the electronic device 101 is designated. It may include at least one of information related to entering.
  • the designated area may be, for example, a local area data network (LADN), a tracking area (TA), a cell of a base station, an area where handover between base stations occurs, or a location based service (e.g., cellular, It may mean at least one of an area determined by a satellite or a location measurement technology based on wireless fidelity (Wi-Fi).
  • the life cycle information of an application may indicate, for example, a state (eg, a life cycle) of an application having a series of cycles.
  • the information regarding the state of the electronic device 101 may include, for example, an on / off state of a display (for example, the display device 160 of FIG. 1), a battery (for example, the battery 189 of FIG. 1).
  • memory eg, memory 130 of FIG. 1 usage state
  • received signal strength e.g. 1
  • time-out information e.g. 1
  • CPU e.g. processor 120 of FIG. 1 usage state
  • the information obtained by the sensor may refer to information obtained by the sensor module 176 described with reference to FIG. 1, for example.
  • network performance may refer to at least one of a frequency bandwidth or a latency of a network to which the electronic device 101 is connected.
  • the service agent 412 is described in detail with reference to the following drawings in accordance with various embodiments.
  • the service enabler 414 may manage (or process) MEC based data transmission of applications (eg, 310-1, 310-2, ...) based on the monitored context information. Can be.
  • a plurality of applications do not individually request information from the MEC system 405, and the service enabler 414 according to various embodiments.
  • applications eg, MEC applications 460-1 and 460-
  • MEC applications 460-1 and 460- that the MEC system 405 can provide to the MMP server 430 or the MEC host 447. 2, ...)
  • the service enabler 414 may include at least one of MEC applications 460-1, 460-2, ... or applications (eg, 310-1, 310-2, ).
  • the application may determine whether the application satisfies the specified condition for performing the MEC-based data transmission, and may notify the application to at least one application satisfying the specified condition to perform the MEC-based data transmission. If at least one application that satisfies the specified condition is not installed in the electronic device 101, the service enabler 414 may install the application layer 446 and / or a framework (eg, middleware) to install the application. 144 and / or operating system 142).
  • a framework eg, middleware
  • the application layer 446 and / or the framework may allow a new application to be installed in the electronic device 101 according to a request of the service enabler 414.
  • the electronic device 101 may receive (or obtain) information about a new application (eg, a URI or an IP address, an application name) from the MEC system 405 (eg, the MEC host 447). Can be.
  • the service enabler 414 may perform life cycle synchronization with the MMP server 430 (eg, LCM proxy server) or edge server when a specified condition related to life cycle synchronization (hereinafter referred to as a second condition) is detected.
  • the service enabler 414 may notify the MMP server 430 whether the applications 310-1, 310-2,...
  • MEC applications e.g. 460-1, 460-2, ...) only operate when applications (e.g. 310-1, 310-2, ...) are in use.
  • the service enabler 414 tells the MMP server 430 whether to use the applications 310-1, 310-2, ... as described above, so that the MEC host 447 (or It is possible to efficiently manage the resources of the edge server (305).
  • the resource allocation of the MEC application may be released to the unused application to reduce the resource consumption of the MEC host 447.
  • the service enabler 414 may be reduced by integrally performing the authentication procedure for the electronic device 101 with the MMP server 430 (or the edge server 305).
  • FIG. 5 is a diagram illustrating an electronic device 101 and an external server 500 for supporting a MEC-based service in a network environment according to various embodiments.
  • the electronic device 101 of FIG. 5 may represent an example of a software architecture for a MEC Authentication / Authorization (MEC AA) procedure and a MEC discovery procedure.
  • MEC AA MEC Authentication / Authorization
  • the electronic device 101 may include application (s) for multi-access edge computing services (hereinafter, referred to as 'MEC services') (hereinafter, referred to as 'client application (application)'. 510), service agent (e.g., MSA) 520 (hereinafter referred to as "MSA 520"), service enabler (e.g., MSE) 530 (hereinafter, referred to as "MSE").
  • 530 ' the electronic device 101 may include a network interface 540 (eg, the wireless communication module of FIG. 1 or FIG. 2) for establishing a protocol data unit (PDU) session related to data transmission.
  • PDU protocol data unit
  • a network driver for controlling the driving of the network interface 540 may be included.
  • the client application 510, the MSA 520, and the MSE 530 may be configured to be mounted in software or have a physical configuration in the electronic device 101.
  • the MSA 520 and the MSE 530 may be driven as part of a processor (eg, the processor 120 of FIG. 1).
  • the MSA 520 and the MSE 530 may be separate hardware configurations that operate independently of the processor 120.
  • the MSA 520 and the MSE 540 may be software (eg, the program 140 of FIG. 1).
  • the MSA 520 and MSE 540 in software form are stored in the form of instructions (or instructions) in a memory (eg, memory 130 of FIG. 1 or 2) and the processor 120. Operations of the MSA 520 and the MSE 530 may be executed by the.
  • client application 510 may include a 3 rd party (party) application that is installed in the electronic device 101 by the user.
  • the client application 510 may be an application using a MEC service such as MEC or fog computing.
  • the client application 510 may include an application that uses a differentiated service, such as a free of charge (FOC) service.
  • FOC free of charge
  • the client application 510 for the MEC may include a MEC application (eg, the first MEC App 460-1 of FIG. 4) that runs on the MEC host (eg, the MEC host 447 of FIG. 4). This may mean an application of the electronic device 101 that is connected to the second MEC App 460-2.
  • the MEC application may mean an application installed and executed in the MEC host 447 adjacent to the user to communicate with the client application 510.
  • the client application 510 may be authenticated through an MSA 520 (eg, a service agent) serving as a separate authentication client.
  • the client application 510 connects to the network based on a specific PDU session (eg, a MEC dedicated PDU session) via the network interface 540, or the MSE 530.
  • a specific PDU session eg, a MEC dedicated PDU session
  • a DNS proxy function of a service enabler eg, a service enabler
  • the client application 510 for the unpaid service may mean an application of the electronic device 101 to which the data free policy is applied.
  • a corresponding unique identifier is provided through a client application routing policy (CARP) or a UE route selection policy (URSP). Routing rules are registered, and traffic generated in the corresponding UID may be transmitted and received through an unpaid PDU session.
  • CARP client application routing policy
  • URSP UE route selection policy
  • the URSP represents an electronic device 101 (eg, user terminal) path selection (or setup) policy defined in the 3GPP standard, and is included in a non-access stratum (NAS) message to transmit the electronic device (ASP) 101 may be received through a modem (or communication processor (CP)) of the modem.
  • CARP is an electronic device 101 path selection (or setting) policy defined in various embodiments, for example, an application layer of the electronic device 101 in an environment in which URSP of 3GPP is not available. (application layer) (eg, MSA 520 or MSE 530).
  • MSA 520 e.g., service agent
  • MSA 520 is responsible for authentication procedures (e.g. authentication) associated with Authentication / Authorization (AA) server 580 (e.g., authentication server) of external server 500 and MEC services.
  • authorization (AA, Authentication / Authorization) procedure For example, the MSA 520 may include delivering URSP rules and / or MEC connection tokens received as a result of the AA to the MSE 530.
  • the MSA 520 may include a role of detecting an application event (eg, launch or termination) or delivering a specific event to the application.
  • the MSA 520 of the electronic device 101 may include an AA client 525.
  • the AA client 525 may be provided by a producer (or a manufacturer) or an operator (eg, a service provider) that produces the electronic device 101.
  • the MSA 520 may perform authentication (Authentication / Authorization) based on the subscriber identification information of the electronic device 101 based on the AA client 525.
  • 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 generic public subscription identifier (GPSI).
  • SIM subscriber identity module
  • USIM universal SIM
  • IMEI international mobile equipment identity
  • GPSI generic public subscription identifier
  • the MSA 520 may authenticate and authorize to use a service (eg, an MSE service) by the MSE 530 through communication with the AA server 580 based on subscriber identification information.
  • the MSE service may collectively refer to a service such as MEC, FOC, MMS, or ultra-reliable and low latency communications (URLLC), which are serviced through the MSE 530.
  • a service such as MEC, FOC, MMS, or ultra-reliable and low latency communications (URLLC), which are serviced through the MSE 530.
  • URLLC ultra-reliable and low latency communications
  • the MSE 530 when the MSA 520 receives the MSE service authentication and authorization through communication with the AA server 580, the MSE 530 using the MSE application programming interface (API) for the authorized service type.
  • Enable / disable e.g. enable / disable MSE service
  • register UIDs and rules e.g. ApnSettings
  • route You can request a routing setting.
  • the MSE API may include an API provided by the electronic device 101 as a higher application layer for activating / deactivating for each MSE service type and setting a routing rule for each UID.
  • the MSE API may include an API for setting at least one policy, such as a policy for a MEC discovery procedure or a context monitoring policy.
  • the client application 510 may access a corresponding service (eg, MEC, FOC) through an authentication and authorization procedure with the MSA 520.
  • the MSA 520 if the MSA 520 is implemented by an operator (e.g., a service provider), for example, if the operator develops an MSA (e.g., an operator MSA) using an MSE service directly, the MSA 520 ) May directly perform the authentication and authorization procedure for using the MSE service through the AA server 580.
  • the MSA 520 may perform an authentication and authorization procedure between the MSA 520 and the electronic device 101 in order to use the MSE API.
  • the MSA 520 when the MSA 520 is mounted in the electronic device 101 in advance, the MSA 520 may be authenticated with a platform key through the signing of the MSA app APK.
  • the electronic device 101 when the electronic device 101 includes (or supports) an authentication module, after the installation of the MSA 520, the electronic device 101 uses an MSE API through a separate authentication procedure from the authentication module in the electronic device 101. You can also get permission.
  • the MSA 520 may call the MSE API based on the received policy to perform creation / end of the PDU session and routing rule setting.
  • various entities of the MSE 530 may be used.
  • a data path e.g., path a, path
  • UHL handling layer
  • DNS domain name system
  • DHL domain name system
  • B or path c can be set.
  • the electronic device 101 uses a default PDU session (eg, a path a) or sets a separate dedicated PDU session when setting a data path of an MEC application.
  • the data path of the path b or the path c may be determined depending on whether the MEC discovery procedure is performed through the MEL 531 of the MSE 530.
  • the MSA 520 forms a dedicated PDU session by directly requesting the UHL 533 of the MSE 530 without passing through the MEL 531 of the MSE 530 (eg, : You can set the service's path as path ⁇ .
  • the MSA 520 requests the UHL 533 to establish a dedicated PDU session for a corresponding service. Can be provided through.
  • the MSA 520 further generates separate information for identifying the service with the UHL 533. Alternatively, it may be received from an external server and provided.
  • the electronic device 101 may include an MSE 530 (eg, a service enabler) in a lower layer of the MSA 520.
  • MSE 530 eg, a service enabler
  • the MSE 530 may provide an MSE API to the MSA 520 such that the client application 510 can use the MEC service (or MSE service) through the MSA 520, and thus A routing table for an application-specific PDU session may be set.
  • the MSE 530 may set a routing table for a PDU session path to be used for each application ID or URI, and store the routing table in a memory (eg, the memory 130 of FIG. 1 or 2).
  • the MSE 530 may set at least one of an application ID and a URI as a target of setting a PDU session path.
  • the URI may include a domain name or an IP address form.
  • the PDU session path setting for each application ID may be set as, for example, "AppID 1: PDU session 1, AppID 2: PDU session1, AppID 3: PDU session 2".
  • the PDU session path setting for each URI may be set as, for example, “URI 1: PDU session 1 and URI 2: PDU session2”.
  • PDU session path setting for each application ID may be set as, for example, "AppID 1 & URI 1: PDU session 3, AppID 2 & URI 1: PDUsession 1".
  • the MEC service may collectively refer to a procedure required for using a MEC application (or mobile edge application), a service provided through the MEC application, and an information related service provided to the MEC application.
  • the MSE 530 may perform MEC service discovery, location verification, route selection, performance verification, or mobility support for the MEC service. support additional features).
  • the MSE 530 is configured as a dedicated PDU session to provide a specific service while connected to at least one MEC host (eg, the MEC host 447 of FIG. 4) (or the MEC application). Or a basic PDU session.
  • information required for configuring a dedicated PDU session or a basic PDU session may be, for example, in a modem (or CP, communication processor) of the electronic device 101, from the AMF / PCF server 590 to the NAS ( It can be received through non-access stratum information.
  • MSE 530 may include MEL 531, UHL 533, and DHL 535.
  • the MEL 531 may perform a task necessary for using the MEC service among the MSE services.
  • MEL 531 may include MEC service registration, MEC service discovery, route selection (eg, DNN handling), performance pre-measurement, Handle operations of location services, and / or mobility handling.
  • the MEC service registration may be performed based on the USIM or account (eg, log-in) information of the electronic device 101, or the MMP server 430 (or the LCM proxy server).
  • the MEC service provider may be authenticated by the MEC solution provider server, and may receive a token (eg, a cookie) corresponding to the MEC service permission level to receive a memory (eg, FIG. 1 or FIG. 2).
  • Memory 130 may be stored in the memory 130. Subsequent MEC services can use the token to fulfill the service request for the time that the token is valid.
  • the MEC service discovery may be detected by the MEL 531 when the electronic device 101 enters an area in which the MEC service is available (eg, a specific cell ID connection or an LADN area entry).
  • Receive at least one of a list of apps available in your region e.g., MEC App (name) list
  • domain name e.g., domain name per MEC application
  • the MEL 531 may provide for available MEC application notifications, DNS proxying, and / or MEC application activation, depending on user settings.
  • MEL 531 may provide a notification for an available MEC application.
  • the currently available MEC application may be displayed in a notification window or an application icon (eg, an app icon).
  • the installation of the client application corresponding to the corresponding MEC application may be notified on the electronic device 101.
  • the MEL 531 may provide DNS proxying. For example, when a client application generates a DNS query for a corresponding domain name to access a MEC application, at least one of the application name or the DNS query matches the MEC app list ( If the matching is performed, the MEL 531 may transmit the corresponding DNS query to the DNS server for the MEC, receive the access IP address for the corresponding MEC application, and return it to the client application 510.
  • the corresponding IP address may be stored, for example, in the DNS cache for the MEC in the electronic device 101 during the validity period.
  • the MEC DNS resolving of domain names on the MEC app list may be performed by the MEL 531 itself and stored in the DNS cache for the MEC separately from the DNS query of the client application.
  • MEL 531 may provide MEC application activation.
  • MEC client application installed in the electronic device 101 when the MEC client application installed in the electronic device 101 is in use or is expected to be used, it may request activation of an MEC application (for example, instantiation) linked thereto.
  • MEC application for example, instantiation
  • the device when the corresponding MEC application is not installed in the access area MEC host of the electronic device 101, the device may request an installation (for example, including a package URI).
  • route selection (e.g., DNN handling) does not use a default PDU session, but instead of using a dedicated PDU session for the MEC service or MEC application, routing rules for the UID of the client application. rule) can be set.
  • the MSE 530 receives dedicated DNN information for a MEC service or MEC application from a predefined profile or AA server 580 and uses a UHL API (not shown) The creation of a dedicated PDU session may be requested.
  • the performance pre-measurement may include, for example, the MEL 531 pre-performance testing against a plurality of candidate MEC hosts.
  • the MEL 531 may select an optimal MEC host through preliminary performance (eg, ping probing, bandwidth estimation) test.
  • the location service may include, for example, providing a service based on an area where the electronic device 101 is located.
  • the MEL 531 may provide information about service availability (or location accuracy) at a corresponding location of the electronic device 101.
  • the information about service availability may include information such as, for example, location confirmed, location not found, or location spoofed.
  • mobility handling may provide, for example, handling for service continuity in the area where handover occurs.
  • the MEL 531 may handle handover from a MEC host to another MEC host or from a MEC host to a remote host.
  • the MEL 531 discovers the MEC application of the MEC host (eg, the MEC host 447 of FIG. 4) through communication with an MMP server (eg, the MMP server 430 of FIG. 4).
  • MEC host eg, the MEC host 447 of FIG. 4
  • MMP server eg, the MMP server 430 of FIG. 4
  • MEL 531 may identify a service by means of a predefined MSE API call.
  • the MEL 531 may identify a service according to a policy received from an operator server (eg, the AA server 580) or the MMP server 430.
  • the MEL 531 sets a path (eg, a path a) of the service via the DHL 535 in the case of a service identification result, for example, a service using a basic PDU session.
  • the MEC service may be provided by the MEL 531 and the DHL 535.
  • the MEL 531 in the case of the data path a for the MEC application, the MEL 531 may be configured to provide a service through a basic PDU session.
  • the MEL 531 is a result of identifying the service, for example, a service route via the MEL 531, the UHL 533, and the DHL 535 when the service uses a dedicated PDU session.
  • the corresponding service may be provided by MEL 531, UHL 533, and DHL 535.
  • the MEL 531 may request the UHL 533 to provide a service through a dedicated PDU session.
  • the MSA 520 further provides separate information to the MEL 531 in order to identify the various services described above, or the MEL 531 receives (or obtains) relevant information from the MMP server 430. You can do that.
  • the UHL 533 may request a dedicated PDU session for each service type according to an API call and bind to a dedicated PDU session configured for the corresponding application.
  • DHL (535) may support a pre-DNS resolving (pre-resolving) or DNS proxy function in the 3 rd party applications. For example, if a client application for a MEC issues a DNS query for a particular service connection with a data connection over an existing default PDU session, the DNS proxy intercepts the DNS query and queries the DNS server with the domain name for the MEC. You can either pass in or return the MEC domain IP address by looking up in the DNS cache. Through this, 3 rd party applications can provide services without the MEC (or steering) without any software modifications, and additional filtering traffic (traffic filtering) for operator action.
  • pre-DNS resolving pre-resolving
  • DNS proxy intercepts the DNS query and queries the DNS server with the domain name for the MEC. You can either pass in or return the MEC domain IP address by looking up in the DNS cache.
  • 3 rd party applications can provide services without the MEC (or steering) without any software modifications, and additional filtering traffic (traffic filtering) for operator
  • AA server 580 may provide authentication and authorization for use of the MSE service.
  • the MSA 520 of the electronic device 101 may be authorized by service type according to authentication and subscriber information through the AA server 580.
  • the MSA 520 may authenticate the MSE service enabled client application.
  • the authentication procedure between the AA server 580 and the MSA 520 of the electronic device 101 does not go through a separate PDU session, for example, the current Internet (e.g., through communication such as LTE or Wi-Fi). You can use the default PDU session connected to the internet.
  • the MMP server 430 may mean a proxy server that communicates with the electronic device 101 for authentication or MEC control of the electronic device 101.
  • the MMP server 430 may perform a request / response message exchange based on, for example, a hypertext transfer protocol (HTTP).
  • HTTP hypertext transfer protocol
  • the LCM proxy may not be needed.
  • the authentication request message of the MSA 520 is forwarded to the AA server 580 to perform authentication, and the MEC control message is sent to the MEC solution providing server. Can be delivered.
  • the interworking API between the MSA 520 and the MMP server 430 or entitlement server may be omitted, and the information needed in the AA procedure (eg, authentication and authorization procedure) may be Can be received.
  • the access and mobility function (AMF) / policy control function (PCF) server 590 supports MMP information and URPS rules in the PCF when MEC is supported in the 5G new radio (NR) standard. rule) is registered, and the corresponding information may be received from the AMF through NAS signaling.
  • AMF access and mobility function
  • PCF policy control function
  • the MSA 520 may communicate with the AA server 580 to perform authentication and request desired information (eg, authentication and authorization), and request the requested information from the AA server ( 580 can be received and obtained.
  • the MSE 530 may request desired information by communicating with the MMP server 530 and may receive and obtain the requested information from the MMP server 530.
  • the MSE 530 may communicate with the MMP server 430 to obtain a MEC app list, or perform a MEC service discovery procedure and establish a connection with at least one particular MEC host (or MEC application). .
  • a scenario of a first data path (eg path a) (eg MSE on Single PDU Session)
  • path a eg MSE on Single PDU Session
  • a scenario of a first data path may include a MEC using a basic PDU session (or public data network (PDN) connection) that a client application is using for existing internet data. It can represent a scenario connecting to an application.
  • the MEL 531 may perform a MEC discovery procedure to request the MEC host driving and connecting to the MEC host close to the electronic device 101 and receive a URI of the corresponding MEC application.
  • the client application 510 requests access to the corresponding MEC application, the client application 510 may perform access to the MEC application IP address obtained through DNS resolving of the URI.
  • the scenario of the first data path (eg, MSE on Single PDU Session) does not use a separate PDU session for the MEC service, so that the UHL 533 which controls the URSP rule does not intervene in operation. You may not.
  • Scenario B eg MSE on Multiple PDU Sessions with MEL
  • a second data path eg path b
  • the MEC dedicated PDU session creation is in accordance with the operator (e.g., mobile network operator (MNO) or MMP server 430) policy, and the MSA 520 or authenticated client application 510 uses the MSE API.
  • MNO mobile network operator
  • MMP server 430 MMP server 430
  • the MEC dedicated PDU session may always keep one or more PDU sessions open in addition to the basic PDU session, and may be dynamically created or released by the request of the MEL 531 at a specific point in time.
  • a predefined rule e.g., a CARP or URSP rule
  • an external server e.g., MMP server 430, AA server 580, or AMF / PCF server 590
  • the UHL 533 of the MSE 530 may support traffic of a corresponding client application (or UID) or a connection URI to a MEC dedicated PDU session.
  • the scenario of the third data path may represent a scenario in which only a dedicated PDU session is generated and used for a specific service without the function of the MEL 531.
  • the MSA 520 or the authenticated client application 510 creates a separate dedicated PDU session using the MSE API, registers an application (eg, UID) rule using the PDU session, Traffic of the application can be routed to the corresponding PDU session.
  • an application eg, UID
  • Traffic of the application can be routed to the corresponding PDU session.
  • various types of services eg FOC, MMS, or URLLC
  • FOC FOC
  • MMS Mobility Management Entity
  • the electronic device 101 includes a network interface 420 and a processor 120, and the processor 120 uses the network interface in the base station or the base station.
  • At least one external server connectable through an external server, wherein the external server obtains information on applications provided by the at least one external server and includes an application corresponding to a specified condition based on the information on the applications. Select and perform data transmission with the selected external server.
  • the processor 120 transmits a request message for requesting information about the applications to the at least one external server, and receives information about the applications from the at least one external server. Receive a response message that includes, and obtains information about the applications from the response message.
  • the processor 120 may designate a condition of the information about the applications in the request message and transmit the condition to the at least one external server.
  • the request message may include at least one of clientappName, locationInfo, deviceType, serviceType, contextType, or URI Request.
  • the response message may include at least one of referenceURI, clientAppName, clientAppPackageURL, uriTTL, uriLOC, carpRule, DNN, S-NSSAI, accessType, sessionType, mptcp, or fqdnList.
  • the electronic device 101 includes a network interface 420 and a processor 120, and the processor 120 may be serviced from a designated external server based on a discovery policy.
  • Acquire an app list of an application obtain information related to an application to be connected to and associated with a client application of the electronic device based on the app list, from the designated external server, and based on the obtained information, to transmit data
  • a host may be determined, and data transmission may be performed with the host.
  • the processor 120 may communicate with the external server to perform an operation related to authentication and authorization, obtain a list of apps by communicating with the external server, and discover a discovery. It may include a service enabler for performing an operation related to (discovery).
  • the processor 120 activates the service enabler through an API between the service agent and the service enabler, and discovers a procedure with the external server through the service enabler. Can be performed.
  • the processor 120 includes setting the discovery policy from the service agent to the service enabler, wherein the discovery policy includes a client application name (clientAppName) and a discovery policy (discoveryPolicy).
  • the discovery policy may include at least one of whether a dynamic DNN (dynamicDnn) is used, location information (locationInfo), a device type (deviceType), a service type (serviceType), or a contextType (contextType). Can be.
  • the processor 120 activates the service enabler based on reception of the discovery policy from the service agent, and satisfies a condition specified according to the discovery policy through a permanent service enabler. You can ask the proxy server for a list of apps.
  • the processor 120 when there is no application associated with the client application in the app list, the processor 120 requests a URI of the application to the proxy server through the service enabler, and the app list. If there is an application associated with the client application, it may be transmitted to the proxy server including the application name of the application.
  • the processor 120 may obtain an application package URI for downloading or installing the application from the proxy server.
  • the processor 120 performs a DNS query with a URI for the application through the service enabler, and obtains an IP address obtained by a DNS response corresponding to the DNS query. It can be stored in a local DNS cache.
  • the processor 120 when a candidate IP list for a plurality of hosts is received from the external server, the processor 120 is configured to select the host based on additional information.
  • the additional information may include information regarding host location, user current location, user speed, or host performance.
  • the electronic device 101 includes a network interface 420 and a processor 120, and the processor 120 may be serviced from a designated external server based on a discovery policy.
  • Obtain an app list of an application obtain information related to an application associated with the client application and to be connected from the designated external server based on an event related to context creation by a client application, and based on the obtained information
  • a host for data transmission may be selected and data transmission may be performed with the host.
  • the event related to generating the context may include at least one of executing the client application, requesting to create a context by the client application, or generating a DNS query by the client application.
  • the discovery policy may include a client application name (clientAppName) and a discovery policy, and the discovery policy may include whether a dynamic DNN is used and location information. It may include at least one of (locationInfo), a device type (deviceType), a service type (serviceType), or a context type (contextType).
  • clientAppName client application name
  • discovery policy may include whether a dynamic DNN is used and location information. It may include at least one of (locationInfo), a device type (deviceType), a service type (serviceType), or a context type (contextType).
  • the processor 120 may request a proxy server for an app list that satisfies a specified condition according to the discovery policy.
  • the processor 120 when there is no application associated with the client application in the app list, the processor 120 requests the URI of the application from the proxy server and associates the client application with the app list. If there is an application, the application name of the application is transmitted to the proxy server, and if there is no application in the proxy server, the application server obtains an application package URI for downloading or installing the application from the proxy server. You can do that.
  • the processor 120 performs a DNS query with a URI for the application and stores an IP address obtained in a DNS response corresponding to the DNS query in a local DNS cache. You can save it.
  • authentication and authorization for example, authentication / authorization (AA)
  • policy for example, authentication / authorization (AA)
  • AA authentication / authorization
  • the operations performed by the electronic device 101 described below are at least one processor (eg, at least one processor including processing circuitry) of the electronic device 101, for example, the processor 120 of FIG. 1. (Hereinafter referred to as 'processor 120').
  • operations performed by the electronic device 101 are stored in a memory (for example, the memory 130 of FIG. 1) (hereinafter, referred to as “memory 130”). It may be executed by instructions that cause 120 to operate.
  • FIG. 6 is a diagram illustrating an authentication and discovery procedure for supporting a MEC service according to various embodiments.
  • FIG. 6 illustrates an example of a signal flow diagram for performing an authentication (eg, authentication & authorization) and discovery procedure of applications for a MEC service.
  • an authentication eg, authentication & authorization
  • FIG. 6 an example in which the electronic device 101 exchanges a signal (or data) with the MEC system 405 is illustrated.
  • the electronic device 101 may use the MEC system 405 through the AN 302. ) May exchange signals with components (eg, AA server 580, MMP server 430, and / or AMF / PCF server 590 of FIG. 5).
  • components eg, AA server 580, MMP server 430, and / or AMF / PCF server 590 of FIG. 5).
  • the electronic device 101 may include a client application 510, an MSA 520 (or a service agent), and an MSE 530 (or service initiation) as described in the description of FIGS. 4 and 5.
  • MEC system 405 may correspond to MEC system 405 as described in the description with reference to FIGS. 4 and 5, and may include AA server 580, MMP server 430, and / or AMF / PCF server 590 may be included.
  • the MSA 520 of the electronic device 101 may perform an authentication (eg, MEC authentication) procedure with the MEC system 405.
  • the authentication procedure may be an AA procedure, for example, an authentication and / or authorization grant procedure.
  • the authentication procedure may include a series of actions to verify that the MEC service is available (or to determine a user), and the authorization procedure may include a MEC service level (e.g., May include a series of operations for checking QoS or resource amount).
  • the MSA 520 may make an initial connection with the MMP server 430 or the AA server 580 to perform user (or subscriber) authentication, and the MMP server 430 or the AA server ( 580 may receive MMP information (MMP Info (information)) and information necessary for authorization, traffic paths, or control data such as CARP or URSP rules for establishing a PDU session.
  • MMP information MMP Info (information)
  • control data such as CARP or URSP rules for establishing a PDU session.
  • the MSA 520 may access the corresponding MMP server 430 to perform an authentication procedure.
  • the MSA 520 may perform authentication information for accessing the MEC system 405 from the MEC system 405 (eg, the MMP server 430) according to a result of performing the authentication procedure.
  • an access token may be obtained (or received).
  • the access token MAT may include a key required for the application to receive a service from the MEC system 405. Description of the authentication procedure according to various embodiments is described in detail with reference to the drawings to be described later.
  • authentication and authorization may include, for example, authentication of the electronic device 101 and / or a user.
  • the electronic device 101 performs authentication on the electronic device 101 (eg, a user terminal) or a subscriber through the MSA 520, and when the authentication is completed, the client application of the electronic device 101 ( 510 may be allowed to connect for the MEC service.
  • the client application 510 may be an application that is internally authenticated (or authenticated) by the MSA 520, and provides a separate access token (eg, a MAT) to the client application 510. This can be omitted.
  • the electronic device 101 (for example, the MSA 520 may be a client application that may perform data transmission based on the MEC among a plurality of applications installed in the electronic device 101).
  • the authentication procedure may be performed based on an OAuth standard, and according to another embodiment, the electronic device 101 may be connected to the MEC system 405.
  • the electronic device 101 may provide an access token to the authenticated client application 510.
  • connection token may be a token used to allow for a connection request that uses that connection token through authentication, for example, an unauthenticated request that does not use that token may limit service provision.
  • the authentication procedure for the client application may be omitted or may be performed before operation 610.
  • the MSE 530 of the electronic device 101 may perform a discovery (eg, MEC service discovery) procedure with the MEC system 405.
  • the MSE 530 may use the received authentication information (eg, MAT) to perform a discovery procedure to be located closest to the electronic device 101 or to access an optimal MEC application.
  • the discovery procedure identifies (or discovers) application (s) (eg, MEC application (s) 460-1, 460-2 of FIG. 4) available to the MEC system 405. May include a series of procedures. Description of the discovery procedure according to various embodiments is described in detail with reference to the drawings to be described later.
  • the electronic device 101 performs an authentication procedure (for example, operation 610) according to various embodiments, and after the authentication procedure, performs an discovery procedure according to various embodiments as described below. can do.
  • the electronic device 101 refers to, for example, a message exchange method for an operation (eg, application lookup, context create / delete) defined in the MEC standard of the European telecommunication standards institute (ETSI). It can also be done.
  • ETSI European telecommunication standards institute
  • the electronic device 101 may perform data transmission with the MEC system 405 after the discovery procedure.
  • the client application 510 of the electronic device 101 performs DNS resolving from a URI of an MEC host (for example, an edge server or a MEC server) to which the electronic device 101 is to be connected, and thereby the electronic device 101. You can obtain (or receive) the IP address of the MEC host closest to the to access the optimal MEC application.
  • the client application 510 may perform data transmission without performing an additional authentication procedure with the MEC system 405 based on the provided connection token.
  • FIG. 6 illustrates an embodiment in which one client application 510 performs data transmission, when a plurality of applications perform data transmission, the plurality of applications may separately perform an authentication procedure with the MEC system 405.
  • the network load may be reduced since data transmission may be performed through an access token (MAT) obtained through the MSA 520 without the need.
  • MAT access token
  • FIG. 7 is a flowchart illustrating a method of operating the electronic device 101 according to various embodiments.
  • the operations illustrated in FIG. 7 may include, for example, the electronic device 101 or a component included in the electronic device 101 (eg, the processor 120 of FIG. 1 and the MEC service of FIG. 4). Module 410).
  • the electronic device 101 may detect an event related to mobility of the electronic device 101.
  • the electronic device 101 may provide context information (eg, information about an application, information related to mobility, life cycle information of an application, information about a state of the electronic device 101, sensor information, or network performance information).
  • Information related to mobility for example, information indicating movement of the electronic device 101, information related to a change of a base station connected to the electronic device 101, or the electronic device 101
  • the electronic device 101 may perform operation 701 or may omit it.
  • the electronic device 101 may perform an authentication procedure with the MEC system 405 using the MEC service module 410 (eg, the MSA 520). For example, the electronic device 101 may perform an authentication procedure in response to detecting that the electronic device 101 enters a designated area. According to an embodiment of the present disclosure, the electronic device 101 may perform an authentication procedure according to an authentication procedure according to various embodiments, which will be described later, and may include an MEC system 405 (eg, an AA server 580 and an MMP server 430). ), You can obtain an access token (eg MAT).
  • MEC system 405 eg, an AA server 580 and an MMP server 430.
  • the electronic device 101 may transmit data for at least one application based on an authentication procedure performed between the MEC service module 410 and the MEC system 405.
  • various authentication scenarios may be provided based on a service provision form (or model).
  • FIG. 8 is a flowchart illustrating an operation method for an authentication procedure in an electronic device 101 according to various embodiments of the present disclosure.
  • the processor 120 (or the MSA 520 of FIG. 5) of the electronic device 101 may transmit a first authentication (eg, an AA server 580 of FIG. 5) to an authentication server.
  • a first authentication eg, an AA server 580 of FIG. 5
  • the MSA 520 of the electronic device 101 may transmit a message for an authentication request to the AA server 580 based on at least one specified authentication scheme.
  • the MSA 520 may request authentication using the AA server 580 and a generic public subscription identifier (GPSI) based Application-layer AKA scheme, ID / password based Login scheme, or GBA scheme.
  • GPSI generic public subscription identifier
  • the processor 120 may obtain first authentication information according to an authentication result from the authentication server.
  • the MSA 520 of the electronic device 101 may perform authentication with the AA server 580 and obtain (or receive) authentication information according to the authentication result from the AA server 580.
  • 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”).
  • MMP Info MMP related information
  • Auth Code an authorization code
  • the authentication information is in addition to the above information, additionally (or optionally) necessary information, for example, identification token for authentication (eg ID_token) or CARP or URSP rules for MEC data service. It may further include at least one of.
  • MMP Info may include, for example, information related to MMP server 430 connection (eg, MMP access address).
  • MMP Info may include address information (eg, a uniform resource identifier (URI) or an IP address) of a new MMP server 430 to be connected to, and information related to the valid time and / or location of the address information.
  • the Auth Code may include, for example, a code (eg, based on OAuth2.0) required to request an access token (eg, MAT) from the MMP server 430.
  • the CARP or URSP rule may include, for example, DNN configuration related information, information related to available applications (or application groups) per DNN, or a list of configurable DNNs or configurable thereafter. It may include information related to the maximum number of DNNs.
  • the processor 120 may set up (eg, update a policy) a PDU session (eg, a dedicated PDU session for a MEC) for a client application.
  • a PDU session eg, a dedicated PDU session for a MEC
  • the MSA 520 of the electronic device 101 may establish a PDU session through the MSE 530 according to a CARP rule or a URSP rule (eg, a DNN).
  • the MSA 520 of the electronic device 101 may perform a policy update with the MSE 530 (eg, establish a PDU session).
  • the MSA 520 may change the default PDU session or additionally set up a new dedicated PDU session.
  • the PDU session establishment operation for the policy update of operation 807 may be performed, for example, when the MSA 520 is provided with a CARP or URSP rule from the AA server 580.
  • the MSA 520 may perform initial PDU session establishment according to a CARP or URSP rule (eg, a DNN).
  • the MSA 520 may update the URSP rule using the MSE API.
  • the processor 120 may transmit a second request message for a second authentication (eg, authorization) to the MMP server 430 based on the first authentication information.
  • the second authentication eg, authorization
  • the second authentication may include a request for authorization for service use and a procedure for obtaining authorization (eg, issuing an access token) according to the authorization request.
  • the MSA 520 of the electronic device 101 sends a message for an authorization request after completion of authentication (or after performing or omitting a policy update with the MSE 530). It may transmit to the MMP server 430.
  • the MSA 520 may request authentication from the MMP server 430 based on authentication information obtained from the AA server 580 (eg, including an Auth Code or an additional identification token ID_token). .
  • the processor 120 may obtain second authentication information according to the authentication result from the MMP server 430.
  • the MSA 520 of the electronic device 101 may perform an authorization procedure with the AA server 580 through the MMP server 430, and may provide authentication information according to the authentication result with the MMP server 430. ) Can be obtained (or received).
  • the authentication information may include, for example, an access token (eg, MAT) and MMP Info.
  • the processor 120 may access the corresponding MMP server 430 based on the second authentication information and perform a discovery procedure.
  • the MSA 520 of the electronic device 101 receives authentication information (eg, MAT) according to the authentication result from the MMP server 430
  • the MSA 520 may receive the received authentication information from the electronic device 101.
  • the MSE 530 may be delivered to the MSE 530.
  • the MSA 520, along with the authentication information includes a connection address (e.g., URI or IP address), DNS server address, or DNN to use of the new MMP server 430 to connect to perform the MEC discovery procedure.
  • the at least one additional information may be delivered to the MSE 530 through the MSE API.
  • the MSE 530 of the electronic device 101 is based at least on the authentication information (eg, MAT) and / or other additional information (eg, MMP Info, DNS server address, or DNN to use). MEC discovery procedures can be performed. According to an embodiment, the MSE 530 may perform the MEC discovery procedure after connecting to the corresponding MMP server 430 using MMP Info and MAT. According to an embodiment, when the second authentication information does not include MMP Info related to the new MMP server 430, the processor 120 performs a MEC discovery procedure based on MMP Info included in the first authentication information. You may.
  • the authentication procedure shown in FIG. 8 may include, for example, a scenario in which the client application 510 connects to a MEC application using a basic PDU session (or PDN).
  • the MSE 530 eg, the MEL 531
  • the MSE 530 performs a MEC discovery procedure, requests the MEC host close to the electronic device 101 to start and connect the MEC application, and receives a URI of the MEC application. can do.
  • the client application 510 requests to access the corresponding MEC application, the client application 510 may access the MEC application IP address obtained through DNS resolving of the URI.
  • the authentication procedure shown in FIG. 8 may include, for example, a scenario in which a client application creates a separate MEC dedicated PDU session in addition to the basic PDU session (or PDN) and connects to the MEC application.
  • a client application creates a separate MEC dedicated PDU session in addition to the basic PDU session (or PDN) and connects to the MEC application.
  • the creation of a MEC-only PDU session is subject to the operator (e.g., MNO or MMP server 430) policy, and can be created via UHL 533 by the MSA 520 or an authenticated client application using the MSE API. have.
  • the MEC dedicated PDU session may always open one or more PDU sessions in addition to the basic PDU session, and may be dynamically created or released at the request of the MEL 531 as needed at a specific time.
  • a predefined rule e.g., a CARP or URSP rule
  • an external server e.g., MMP server 430, AA server 580, or AMF / PCF server 590
  • the UHL 533 of the MSE 530 may support traffic for a corresponding client application (or UID) or access URI according to the received routing rule to the MEC dedicated PDU session.
  • the authentication procedure illustrated in FIG. 8 may include, for example, a scenario in which only a dedicated PDU session is generated and used for a specific service.
  • the MSA 520 or the authenticated client application 510 creates a separate dedicated PDU session using the MSE API, registers an application (eg, UID) rule using the PDU session, Traffic of the corresponding application may be routed to the corresponding PDU session.
  • an application eg, UID
  • FIG. 9 is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • the electronic device 101 may include an MSA (or service agent) 520 (eg, including an AA client 525) and an MSE (or service enabler) 530 (eg, MEL ( 531), including the UHL 533).
  • MSA or service agent
  • MSE or service enabler
  • the MSA 520 of the electronic device 101 performs an authentication (eg, first authentication) request based on at least one authentication scheme (eg, first authentication) specified. May send a message (eg, a first request message) to the AA server 580.
  • the MSA 520 may request authentication using the AA server 580 and a generic public subscription identifier (GPSI) based Application-layer AKA scheme, ID / password based Login scheme, or GBA scheme.
  • GPSI generic public subscription identifier
  • the MSA 520 may perform authentication with the AA server 580.
  • the MSA 520 may perform GPSI based user authentication with the AA server 580.
  • the AA server 580 performs authentication with the electronic device 101.
  • the authentication information (eg, first authentication information) according to the present disclosure may be provided (or transmitted) to the electronic device 101 (eg, the MSA 520).
  • 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').
  • the MMP server 430 additionally (or optionally) needs additional information, for example, at least one of ID_token for authentication or CARP or URSP rules for MEC data service. It may be provided by including in the authentication information.
  • MMP Info may include, for example, information related to MMP server 430 connection (eg, MMP access address).
  • MMP Info may include address information (eg, a uniform resource identifier (URI) or an IP address) of a new MMP server 430 to be connected to, and information related to the valid time and / or location of the address information.
  • the Auth Code may include, for example, a code (eg, OAuth2.0 based) required to request an access token (eg, MAT, MEC access token) from the MMP server 430. have.
  • the CARP or URSP rule may include, for example, related information (eg, a DNN) for PDU session setup, information related to an available application (or application group) per DNN, or It may include a list of configurable DNN lists or information related to the maximum number of configurable DNNs.
  • related information eg, a DNN
  • information related to an available application (or application group) per DNN or It may include a list of configurable DNN lists or information related to the maximum number of configurable DNNs.
  • the MSA 520 may perform a policy update (eg, PDU session setup) with the MSE 530.
  • the MSA 520 may perform PDU session establishment according to a CARP rule or a URSP rule (eg, a DNN).
  • the MSA 520 may identify a policy regarding whether to perform PDU session establishment according to the CARP rule or the URSP rule, and the MSE 530 may request a PDU session establishment request through the MSE API according to the CARP rule or the URSP rule. Can be delivered to.
  • the MSE 530 may perform PDU session establishment in response to the PDU session establishment request of the MSA 520.
  • the MSA 520 may change the default PDU session or additionally establish a new dedicated PDU session.
  • the policy update operation of the MSA 520 and the MSE 530 in operation 907 may occur, for example, when the MSA 520 is provided with a CARP or URSP rule from the AA server 580. Can be done.
  • the MSA 520 may not perform a policy update with the MSE 530 when no CARP or URSP rules are provided from the AA server 580.
  • the MSA 520 may not perform the policy update through the MSA 520's own decision or information exchange with the MSE 530 even if the CARP or URSP rules are provided from the AA server 580. .
  • the MSA 520 sends a message (eg, an authorization request) for authorization (eg, second authentication) after authentication is completed (or after performing or omitting a policy update with the MSE 530).
  • a message eg, an authorization request
  • authorization eg, second authentication
  • Second request message to the MMP server 430.
  • the MSA 520 may request authentication from the MMP server 430 based on authentication information obtained from the AA server 580 (eg, including an Auth Code or additionally ID_token).
  • the MSA 520 may perform authentication (eg, an authorization procedure) with the AA server 580 through the MMP server 430. According to an embodiment, the MSA 520 may perform service authorization based on the AA server 580 and the Auth Code.
  • authentication eg, an authorization procedure
  • the MSA 520 may perform service authorization based on the AA server 580 and the Auth Code.
  • the MMP server 430 may transmit authentication information (eg, the second authentication information) according to the authentication result to the electronic device 101 (eg, the MSA 520 may be provided (or transmitted).
  • the authentication information may include, for example, an access token (eg, MAT, MEC access Token) and MMP Info.
  • the MMP server 430 may transmit a response including the access token to the MSA 520 during or after performing authentication of the MSA 520.
  • the MSA 520 may activate the MSE 530.
  • the authentication information eg, an access token (MAT)
  • the MSE 530 may be activated by transmitting the received authentication information (eg, an access token (MAT)) to the MSE 530.
  • MSA 520 along with authentication information (e.g., access token (MAT)), access address (e.g. URI or IP address) of new MMP server 430 to connect to perform the MEC discovery procedure.
  • authentication information e.g., access token (MAT)
  • access address e.g. URI or IP address
  • At least one additional information such as a DNS server address or a DNN to be used may be transmitted to the MSE 530.
  • the MSA 520 may enable the MSE 530 based on the received access token (MAT) and / or other additional information.
  • the MSA 520 performs authentication (eg, authorization) with the MMP server 430
  • the MSA 520 receives an access token (eg, MAT) from the MMP server 430 as a result of authentication.
  • MMP access information (MMP Info) and access token (MAT) may be delivered to the MSE 530 by calling enableMecEnablingLayer (true, MMP Info, MAT) of the MSE API.
  • the MSE 530 receives authentication information (eg, MAT) and / or other additional information (eg, MMP Info, DNS server address, or DNN to use), and applies the authentication information and / or additional information to the MSE 530.
  • the MEC discovery procedure can be performed based at least on.
  • the MSE 530 may perform the MEC discovery procedure after connecting to the corresponding MMP server 430 using MMP Info and MAT.
  • the MSE 530 may perform authentication (eg, service authorization of operation 911) with the MMP server 430.
  • authentication eg, authorization
  • the MSA 520 when the MSE 530 performs authentication (eg, authorization) with the MMP server 580, the MSA 520, which has completed authentication, first receives the MMP from the MMP server 430 as an authentication result.
  • Info and Auth Code and / or other additional information e.g. identification token (ID_token)
  • ID_token identification token
  • enableMecEnablingLayer truee, MMP Info, Auth Code, [ID-Token]
  • the MSE 530 may directly authenticate with the MMP server 430 from the information received from the MSA 520, and receive (or obtain) the MAT as a result.
  • the MSA 520 and the MSE 530 may be divided into a subject performing a service authentication procedure for authorization in an internal configuration of the electronic device 101. have.
  • FIG. 10 is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • FIG. 10 may illustrate an example of a signal flow for an authentication procedure (eg, scenario A regarding authentication / authorization (AA) and policy update) according to various embodiments.
  • FIG. 10 illustrates an example of an MEC service authentication flow for scenario A of an authentication procedure according to various embodiments, and includes “User Authentication” corresponding to operations 901, 903, and 905 according to FIG. 9. Or Subscriber Authentication) ”(eg, operation 1010) and operations according to the detailed embodiment of“ MEC Service Authorization ”corresponding to operation 909, operation 911, and operation 913 according to FIG. Operation 1020).
  • scenario A for updating the MEC AA and the policy illustrates a scenario of performing the MEC Service Authorization (eg, operation 1020) after User Authentication (eg, operation 1010). Can be represented.
  • the MSA 520 of the electronic device 101 may transmit a message for authentication request to the entitlement server 1000.
  • the entitlement server 1000 may determine an authentication method.
  • the entitlement server 1000 may determine an authentication method corresponding to the authentication request of the electronic device 101 in at least one specified authentication method.
  • the at least one authentication scheme may include, for example, authentication of an application-layer AKA or Login (eg, ID / password) scheme using GPSI.
  • the MSA 520 may request the authorization code while transmitting subscriber identification information (or terminal identification information) (eg, GPSI or IMSI) to the entitlement server 1000.
  • the MSA 520 and the entitlement server 1000 may perform user authentication in an application-layer AKA or logging manner as in operation 1010.
  • the MSA 520 performs an authentication (eg, MEC subscriber authentication) procedure based on an Application-layer AKA scheme between the AA server 580 via the entitlement server 1000.
  • an authentication response including authentication information according to the authentication result may be obtained from the AA server 580.
  • the MSA 520 performs an authentication procedure based on the ID / password based login scheme with the entitlement server 1000, and in operation 1009, the entitlement server ( An authentication response including authentication information according to the authentication result may be obtained from the entitlement server 1000 based on the login success.
  • the MSA 520 may receive an authentication response corresponding to the authentication request.
  • the MSA 520 may perform authentication information (eg, MMP Info, Auth Code) according to an authentication result from the AA server 580 through the entitlement server 1000 or the entitlement server 1000.
  • ID_token, CARP rule, or URSP rule can be obtained.
  • the MSA 520 may receive MMP related information (eg, MMP access address) to perform the MEC discovery procedure as a result of authentication, an authorization code (eg, an Auth code) and ID_token for authorization. have.
  • the MSA 520 may receive information related to a CARP or URSP rule for the MEC data service based on whether the AA server 580 is supported.
  • the MSA 520 may perform “MEC Service Authorization” as in operation 1020 after “User Authentication” as in operation 1010.
  • the MSA 520 may transmit a message for an authorization request to the MMP server 430.
  • the MSA 520 may transmit the obtained authentication information (eg, an Auth Code or additional ID_token) to the MMP server 430 and request authorization from the MMP server 430.
  • the MSA 520 may access the MMP server 430 using the MMP access address and perform an authorization procedure.
  • the MMP server 430 may request an access token from the entitlement server 1000, and in operation 1017, obtain an access token from the entitlement server 1000.
  • the MMP server 430 communicates with the entitlement server 1000 or with the AA server 580 through the entitlement server 1000, so that the electronic device 101 is a MEC service subscriber. You can check whether or not.
  • the MMP server 430 may issue (eg authorize) an access token (eg MAT) to the MSA 520. Can be.
  • the MMP server 430 transmits the MMP information and the authorization code to the entitlement server 1000 (or AA server 580), and requests an access token for accessing user profile information. Can be obtained.
  • the MMP server 430 may transmit an authorization response corresponding to the authorization request to the MSA 520.
  • the MMP server 430 checks the user profile using the corresponding access token, and MMP Info, MAT, or CARP to the MSA 520 when it is determined that the MEC service is available based on the user profile. You can pass an Authorization response including a rule.
  • the MSA 520 may obtain an access token (eg, a MAT) as a result of the authorization procedure.
  • an access token eg, a MAT
  • the MSA 520 receives an access token as a result of the authorization procedure, and the MSE 530 through the MSE API. It can pass MMP information and access token.
  • the MSE 530 performs an authorization procedure with the MMP server 430
  • the MMP information and authorization code received from the entitlement server 1000 by the MSA 520, which has completed authentication first is first obtained.
  • (Auth code) and optionally ID_token may be delivered to the MSE 530 through the MSE API.
  • the MSE 530 may directly perform an authorization procedure with the MMP server 430 based on the information transmitted from the MSA 520, and receive the access token as a result.
  • the MSA 520 may perform the MEC discovery procedure using the MMP Info and the access token through the MSE 530.
  • 11 is a flowchart illustrating an operating method for an authentication procedure in an electronic device 101 according to various embodiments.
  • the processor 120 (or the MSA 520 of FIG. 5) of the electronic device 101 may transmit a request message for authentication to the MMP server 430.
  • the MSA 520 of the electronic device 101 may transmit a message (eg, an authorization request message) for an authorization request for using a service based on at least one authentication scheme specified. And transmit to 430.
  • the MNO information and the Device ID (eg, IMSI, IMEI, GPSI, or separately assigned unique) At least one or all of the identifiers) may be transmitted to the MMP server 430.
  • the Device ID may include an identifier (eg, a UID) in which the MMP server 430 may uniquely identify the electronic device 101.
  • the processor 120 may obtain authentication information according to the authentication result from the MMP server 430.
  • the MSA 520 of the electronic device 101 may perform authentication (eg, AA, authentication & authorization) with the MMP server 430, and may provide authentication information according to the authentication result with the MMP server 430.
  • the authentication information may include, for example, MMP Info and an access token (eg, MAT).
  • the authentication information may further include (or alternatively) necessary information, for example, at least one of CARP or URSP rules for the MEC data service, in addition to the above information.
  • MMP Info may include, for example, information related to MMP server 430 connection (eg, MMP access address).
  • MMP Info may include address information (eg, URI or IP address) of a new MMP server 430 to be accessed and information related to the valid time and / or place of the address information.
  • the connection token eg, MAT
  • the CARP or URSP rule may include, for example, DNN configuration related information, information related to available applications (or application groups) per DNN, or a list of configurable DNNs or configurable thereafter. It may include information related to the maximum number of DNNs.
  • the processor 120 may set up a PDU session (eg, a dedicated PDU session for the MEC) for the client application.
  • a PDU session eg, a dedicated PDU session for the MEC
  • the MSA 520 of the electronic device 101 may perform a policy update with the MSE 530 (eg, establish a PDU session).
  • the MSA 520 may perform initial PDU session establishment according to a CARP or URSP rule (eg, a DNN).
  • the MSA 520 may update the URSP rule using the MSE API.
  • the processor 120 may access the corresponding MMP server 430 based on the authentication information and perform a discovery procedure.
  • the MSA 520 of the electronic device 101 receives authentication information (eg, MAT) according to the authentication result from the MMP server 430
  • the MSA 520 may receive the received authentication information from the electronic device 101.
  • the MSE 530 may be delivered to the MSE 530.
  • the MSA 520, along with the authentication information includes a connection address (e.g., URI or IP address), DNS server address, or DNN to use of the new MMP server 430 to connect to perform the MEC discovery procedure.
  • the at least one additional information may be delivered to the MSE 530 through the MSE API.
  • the MSE 530 of the electronic device 101 is based at least on the authentication information (eg, MAT) and / or other additional information (eg, MMP Info, DNS server address, or DNN to use). MEC discovery procedures can be performed. According to an embodiment, the MSE 530 may perform the MEC discovery procedure after connecting to the corresponding MMP server 430 using MMP Info and MAT.
  • the authentication information eg, MAT
  • additional information eg, MMP Info, DNS server address, or DNN to use.
  • MEC discovery procedures can be performed.
  • the MSE 530 may perform the MEC discovery procedure after connecting to the corresponding MMP server 430 using MMP Info and MAT.
  • the authentication procedure shown in FIG. 11 may include, for example, a scenario in which the client application 510 connects to a MEC application using a basic PDU session (or PDN).
  • the MSE 530 eg, the MEL 531
  • the MSE 530 performs a MEC discovery procedure, requests the MEC host close to the electronic device 101 to start and connect the MEC application, and receives a URI of the MEC application. can do.
  • the client application 510 requests to access the corresponding MEC application, the client application 510 may access the MEC application IP address obtained through DNS resolving of the URI.
  • the authentication procedure shown in FIG. 11 may include, for example, a scenario in which a client application creates a separate MEC dedicated PDU session in addition to the basic PDU session (or PDN) and connects to the MEC application.
  • a client application creates a separate MEC dedicated PDU session in addition to the basic PDU session (or PDN) and connects to the MEC application.
  • the creation of a MEC-only PDU session is subject to the operator (e.g., MNO or MMP server 430) policy, and can be created via UHL 533 by the MSA 520 or an authenticated client application using the MSE API. have.
  • the MEC-only PDU session may always keep one or more PDU sessions open in addition to the basic PDU session, and may be dynamically created or released by request of the MEL 531 at a specific point in time.
  • a predefined rule e.g., a CARP or URSP rule
  • an external server e.g., MMP server 430, AA server 580, or AMF / PCF server 590
  • the UHL 533 of the MSE 530 may support traffic for a corresponding client application (or UID) or access URI according to the received routing rule to the MEC dedicated PDU session.
  • the authentication procedure illustrated in FIG. 11 may include a scenario in which only a dedicated PDU session is generated and used for a specific service, for example, without the function of the MEL 531.
  • the MSA 520 or the authenticated client application 510 creates a separate dedicated PDU session using the MSE API, registers an application (eg, UID) rule using the PDU session, Traffic of the corresponding application may be routed to the corresponding PDU session.
  • an application eg, UID
  • FIG. 12 is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • the electronic device 101 may include an MSA (or service agent) 520 (eg, including an AA client 525) and an MSE (or service enabler) 530 (eg, MEL ( 531), including the UHL 533).
  • MSA or service agent
  • MSE or service enabler
  • the MSA 520 of the electronic device 101 may transmit a message (eg, an authorization request message) for an authorization request for using a service based on at least one authentication scheme specified. ) May be transmitted to the MMP server 430.
  • a message eg, an authorization request message
  • the mobile network operator (MNO) eg, the entitlement server 1000
  • the device ID eg At least one or both of IMSI, IMEI, GPSI, or a separately assigned unique identifier
  • the Device ID may include an identifier that allows the MMP server 430 to uniquely identify the electronic device 101.
  • the MSA 520 may perform an authentication and authorization (eg, AA) procedure with the AA server 580 through the MMP server 430 or the MMP server 430. For example, when the MSA 520 forwards an authorization request to the MMP server 430, the message exchange between the MSA 520, the MMP server 430, and the AA server 580 may be performed. Example: see FIG. 13 to be described later).
  • the MSA 520 may perform user authentication and service authorization (or authorization) with the MMP server 430.
  • the MSA 520 may perform a procedure for identifying whether the electronic device 101 is a registered user and perform a procedure for identifying whether a corresponding service can be provided.
  • the MMP server 430 since the MMP server 430 may have a different AA scheme according to the MNO information, the MMP server 430 may perform AA using a scheme suitable for the MNO information.
  • the MMP server 430 performs authentication with the electronic device 101, and when the authentication is completed (for example, the authentication procedure is completed), the MMP server 430 is included in the authentication result.
  • the authentication information may be provided (or transmitted) to the electronic device 101 (for example, the MSA 520).
  • the authentication information may include, for example, MMP Info and an access token (eg, MAT).
  • the MMP server 430 may additionally (or optionally) add, in addition to the above information, authentication information to at least one of CARP or URSP rules for MEC data services, for example. Including can be provided.
  • the MSA 520 may receive all of the authentication information (eg, MMP Info, MAT, and CARP or URSP rule) based on the authentication result from the MMP server 430.
  • the MSA 520 receives a portion of authentication information (eg, MMP Info, MAT for discovery) from the MMP server 430, and the CARP rule (or URSP rule) is described below. As shown in the example of FIG. 13, it may be received from the AA server 580 as a result of user authentication.
  • MMP Info may include, for example, information related to MMP server 430 connection (eg, MMP access address).
  • MMP Info may include address information (eg, a uniform resource identifier (URI) or an IP address) of a new MMP server 430 to be connected to, and information related to the valid time and / or location of the address information.
  • the connection token eg, MAT
  • the CARP or URSP rule may include, for example, DNN configuration related information, information related to available applications (or application groups) per DNN, or a list of configurable DNNs or configurable thereafter. It may include information related to the maximum number of DNNs.
  • the MSA 520 may perform a policy update (eg, PDU session setup) with the MSE 530.
  • the MSA 520 may perform initial PDU session establishment according to a CARP or URSP rule (eg, a DNN). For example, if there is a URSP rule in the information received from the MMP server 430, the MSA 520 may update the URSP rule using the MSE API.
  • the policy update operation of the MSA 520 and the MSE 530 in operation 1207 may be performed, for example, when the MSA 520 is provided with a CARP or URSP rule from the AA server 580. have.
  • the MSA 520 may not perform a policy update with the MSE 530 when no CARP or URSP rules are provided from the AA server 580.
  • the MSA 520 may not perform the policy update through the MSA 520's own decision or information exchange with the MSE 530 even if the CARP or URSP rules are provided from the AA server 580. .
  • the MSA 520 may activate the MSE 530.
  • the authentication information eg, an access token (MAT)
  • the MES 530 may be activated by passing the received authentication information (eg, an access token (MAT)) to the MSE 530.
  • At least one additional information such as a DNS server address or a DNN to be used may be transmitted to the MSE 530.
  • the MSA 520 may enable the MSE 530 based on the received access token (MAT) and / or other additional information.
  • the MSA 520 may receive an access token (eg, MAT) from the MMP server 430 as an authentication result. For example, by calling enableMecEnablingLayer (true, MMP Info, MAT) of the MSE API, MMP access information (MMP Info) and access token (MAT) may be delivered to the MSE 530.
  • the MSE 530 receives authentication information (eg, MAT) and / or other additional information (eg, MMP Info, DNS server address, or DNN to use) and applies the authentication information and / or additional information.
  • the MEC discovery procedure can be performed based at least on.
  • the MSE 530 may perform the MEC discovery procedure after connecting to the corresponding MMP server 430 using MMP Info and MAT.
  • FIG. 13 is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • FIG. 13 may illustrate an example of a signal flow for an authentication procedure (eg, scenario B regarding AA and policy update) according to various embodiments.
  • FIG. 13 illustrates an example of an MEC service authentication flow for scenario B of an authentication procedure according to various embodiments, and illustrates detailed embodiments corresponding to operations 1201, 1203, and 1205 according to FIG. 12. It may include.
  • an “User Authentication (or Subscriber Authentication)” operation eg, operation 1320
  • an “MEC Service Authorization” operation eg, operation 1310
  • scenario B for updating the MEC AA and policy as shown in Fig. 13, a scenario example of performing the MEC Service Authorization (eg, operation 1310) prior to User Authentication (eg, operation 1320). Can be represented.
  • the MSA 520 of the electronic device 101 may transmit an authorization request message for an authorization request to the MMP server 430.
  • the authority request message may include at least one or both of MNO information and a Device ID (eg, IMSI, IMEI, GPSI, or a uniquely assigned unique identifier).
  • the MMP server 430 may determine an authentication method. According to an embodiment of the present disclosure, the MMP server 430 may determine an authentication scheme corresponding to the authorization request of the electronic device 101 in at least one specified authentication scheme. According to an embodiment, the at least one authentication scheme may include, for example, an application-layer AKA or login (eg, ID / password) scheme.
  • the MSA 520 may transmit the URI of the entitlement server 1000 to the MMP server 430.
  • the MMP server 430 may request an authorization code from the entitlement server 1000.
  • the MSA 520 passes subscriber identification information (or terminal identification information) (eg, GPSI or IMSI) to the MMP server 430
  • the MMP server 430 sends the information to the MNO side.
  • An authorization code may be requested while passing to the title server 1000 or the AA server 580.
  • user authentication may be performed using an application-layer AKA or login method. ) Can be performed.
  • the authentication scheme may be different according to the MNO information, and the AA server 580 may perform authentication using a scheme corresponding to the MNO information.
  • the MSA 520 may perform authentication based on the AA server 580 and at least one authentication scheme specified.
  • the MSA 520 may perform an authentication procedure based on an application-layer AKA scheme between the AA servers 580 through the entitlement server 1000.
  • the MSA 520 performs an authentication procedure based on the ID / password based login scheme with the entitlement server 1000, and in operation 1313, the entitlement server ( The authentication process can be performed by logging in to 1000.
  • the MMP server 430 when the MMP server 430 receives an authorization code response corresponding to the authorization code request from the entitlement server 1000, in operation 1317, confirming a user profile with the AA server 580. Request the access token for the entitlement server 1000, and may receive the access token from the entitlement server 1000.
  • the AA server 580 when authentication for the corresponding electronic device 101 is completed, the AA server 580 may transfer a CARP or URSP rule to the MSA 520 as needed, and the MMP server 430 requests The authorization code may be transmitted to the MMP server 430.
  • the MMP server 430 may transmit the MMP information and the authorization code to the entitlement server 1000 or the AA server 580, and may request and receive an access token for accessing user profile information. .
  • the MMP server 430 may obtain a user profile using the access token.
  • the MSA 520 may transmit the MEC service subscriber authentication and authorization code of the electronic device 101 to the MMP server 430 through the AA server 580.
  • the MMP server 430 and the AA server 580 may check the subscriber profile based on the access token issued using the authorization code.
  • the MMP server 430 may transmit an authorization response corresponding to the authorization request to the MSA 520.
  • the MMP server 430 checks the user profile using the access token, and if it is determined that the MEC service is available based on the user profile, the MMP server 430 results in an access token (eg, as a result of the authorization procedure).
  • MAT MMP Info
  • / or route policy e.g., CARP or URSP rules (e.g., dedicated DNN)
  • route policy e.g., CARP or URSP rules (e.g., dedicated DNN)
  • the MSA 520 may obtain an access token (eg, a MAT) as a result of the authorization procedure.
  • an access token eg, a MAT
  • the MSA 520 receives an access token as a result of the authorization procedure, and the MSE 530 through the MSE API. It can pass MMP information and access token.
  • the MSE 530 performs an authorization procedure with the MMP server 430, first, the MA 520, which has completed authentication, receives the MMP information and authorization code (Auth) code) and optionally ID_token may be delivered to the MSE 530 via the MSE API.
  • the MSE 530 may directly perform an authorization procedure with the MMP server 430 based on the information transmitted from the MSA 520, and receive the access token as a result.
  • the MSA 520 may perform the MEC discovery procedure using the MMP Info and the access token through the MSE 530.
  • FIG. 14 is a flowchart illustrating an operating method for an authentication procedure in an electronic device 101 according to various embodiments.
  • the processor 120 (or the MSE 530 of FIG. 5) of the electronic device 101 may be required to access the MMP server 430 from the AMF / PCF server 590 based on access communication.
  • the first authentication information may be obtained.
  • the MSE 530 of the electronic device 101 may perform a NAS signaling procedure with an AMF / PCF server 590 (eg, AMF).
  • the AMF / PCF server 590 may provide the first authentication information to the electronic device 101 based on NAS signaling.
  • the first authentication information may include MMP Info, Auth Code, and may further include ID_token and / or CARP or URSP rule.
  • the MSE 530 may receive a NAS signaling message that the modem (or communication processor (CP)) of the electronic device 101 receives from the AMF through the UHL 533 of the MSE 530.
  • the MSA 520 obtains at least one information of MMP Info and Auth Code, ID_token, or CARP or URSP rule from a NAS signaling message, and uses the obtained information as a UHL 533. May be delivered to the MSA 520.
  • the processor 120 may establish a PDU session for the client application.
  • the MSE 530 of the electronic device 101 may obtain first authentication information (eg, at least one information of MMP Info, Auth Code, and / or ID_token) from the NAS signaling message.
  • the first authentication information may be transferred to the MSA 520.
  • the MSA 520 of the electronic device 101 may perform a policy update with the MSE 530 using the MSE API when the obtained mediation includes the CARP or URSP rule.
  • the MSA 520 may not perform a policy update with the MSE 530 when the CARP or URSP rule is not provided among the information obtained through the NAS signaling message.
  • the MSA 520 may not perform a policy update through the MSA 520's own decision or information exchange with the MSE 530 even if a CARP or URSP rule is provided.
  • the processor 120 may transmit a second request message for the authorization request to the MMP server 430 based on the first authentication information.
  • the MSA 520 of the electronic device 101 sends a message for an authorization request after completion of authentication (or after performing or omitting a policy update with the MSE 530). It may transmit to the MMP server 430.
  • the MSA 520 may request authorization from the MMP server 430 based on the first authentication information (eg, an Auth Code or additionally ID_token) obtained from the NAS signaling message.
  • the first authentication information eg, an Auth Code or additionally ID_token
  • the processor 120 may obtain second authentication information according to the authentication result from the MMP server 430.
  • the MSA 520 of the electronic device 101 may perform authentication (eg, an authorization procedure) with the AA server 580 through the MMP server 430, and according to the second authentication result Authentication information may be obtained (or received) from the MMP server 430.
  • the second authentication information may include, for example, an access token (eg, MAT) and MMP Info.
  • the processor 120 may access the MMP server 430 based on the second authentication information and perform a discovery procedure.
  • the MSA 520 of the electronic device 101 receives the second authentication information (eg, MAT) according to the authentication result from the MMP server 430
  • the MSA 520 electronically receives the received second authentication information. It may forward to the MSE 530 of the device 101 and activate the MSE 530.
  • the MSA 520 along with the MAT, may use a connection address (e.g., URI or IP address), DNS server address, or DNN to use of the new MMP server 430 to contact to perform the MEC discovery procedure.
  • At least one additional information may be delivered to the MSE 530 through the MSE API.
  • the MSE 530 of the electronic device 101 may perform the MEC discovery procedure based at least on the MAT and / or other additional information (eg, MMP Info, DNS server address, or DNN to use). Can be.
  • the MSE 530 may perform the MEC discovery procedure after connecting to the corresponding MMP server 430 using MMP Info and MAT.
  • the authentication procedure shown in FIG. 14 may include, for example, a scenario in which the client application 510 connects to a MEC application using a basic PDU session (or PDN).
  • the MSE 530 eg, the MEL 531
  • the MSE 530 performs a MEC discovery procedure, requests the MEC host close to the electronic device 101 to start and connect the MEC application, and receives a URI of the MEC application. can do.
  • the client application 510 requests to access the corresponding MEC application, the client application 510 may access the MEC application IP address obtained through DNS resolving of the URI.
  • the authentication procedure shown in FIG. 14 may include, for example, a scenario in which a client application creates a separate MEC dedicated PDU session in addition to the basic PDU session (or PDN) and connects to the MEC application.
  • a client application creates a separate MEC dedicated PDU session in addition to the basic PDU session (or PDN) and connects to the MEC application.
  • the creation of a MEC-only PDU session is subject to the operator (e.g., MNO or MMP server 430) policy, and can be created via UHL 533 by the MSA 520 or an authenticated client application using the MSE API. have.
  • the MEC dedicated PDU session may always open one or more PDU sessions in addition to the basic PDU session, and may be dynamically created or released at the request of the MEL 531 as needed at a specific time.
  • a predefined rule e.g., a CARP or URSP rule
  • an external server e.g., MMP server 430, AA server 580, or AMF / PCF server 590
  • the UHL 533 of the MSE 530 may support traffic for a corresponding client application (or UID) or access URI according to the received routing rule to the MEC dedicated PDU session.
  • the authentication procedure shown in FIG. 14 may include a scenario in which only a dedicated PDU session is created and used for a specific service, for example, without the function of the MEL 531.
  • the MSA 520 or the authenticated client application 510 creates a separate dedicated PDU session using the MSE API, registers an application (eg, UID) rule using the PDU session, Traffic of the corresponding application may be routed to the corresponding PDU session.
  • an application eg, UID
  • 15A is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • the electronic device 101 may include an MSA (or service agent) 520 (eg, including an AA client 525) and an MSE (or service enabler) 530 (eg, MEL ( 531), including the UHL 533).
  • MSA or service agent
  • MSE or service enabler
  • URSP may be added in the PCF of the AMF / PCF server 590 to manage information (eg, MMP Info, Auth Code, or ID_token) required for MMP access.
  • the MSE 530 of the electronic device 101 may perform a NAS signaling procedure with an AMF / PCF server 590 (eg, AMF).
  • the AMF / PCF server 590 may provide MMP Info, Auth Code to the electronic device 101, and may additionally provide ID_token and / or CARP or URSP rules.
  • the MSE 530 may receive a NAS signaling message that the modem (or communication processor) of the electronic device 101 receives from the AMF 590 through the UHL 533 of the MSE 530. .
  • the modem of the electronic device 101 obtains at least one information of MMP Info and Auth Code, ID_token, or CARP or URSP rule from a NAS signaling message received from the AMF, and obtains the obtained information from the UHL 533. It may be delivered to the MSA 520 through.
  • MMP Info may include, for example, information related to MMP server 430 connection (eg, MMP access address).
  • MMP Info may include address information (eg, a uniform resource identifier (URI) or an IP address) of a new MMP server 430 to be connected to, and information related to the valid time and / or location of the address information.
  • URI uniform resource identifier
  • the CARP or URSP rule may include, for example, DNN configuration related information, information related to available applications (or application groups) per DNN, or a list of configurable DNNs or configurable thereafter. It may include information related to the maximum number of DNNs.
  • At least one of MMP Info, Auth Code, ID_token, or CARP or URSP rules provided from the AMF / PCF server 590 may be obtained at the MSA 520 through the MSE 530.
  • the MSA 520 may perform a policy update (eg, PDU session establishment) with the MSE 530.
  • the MSA 520 may perform PDU session establishment according to a CARP or URSP rule (eg, a DNN). For example, if there is a URSP rule in the information received from the MMP server 430, the MSA 520 may update the URSP rule using the MSE API.
  • the MSA 520 may perform policy update with the MSE 530 when the CARP or URSP rule is included in the information obtained through the NAS signaling message.
  • the MSA 520 may not perform a policy update with the MSE 530 when the CARP or URSP rule is not provided among the information obtained through the NAS signaling message. According to another embodiment, the MSA 520 may not perform a policy update through the MSA 520's own decision or information exchange with the MSE 530 even if a CARP or URSP rule is provided. According to an embodiment, PDU session establishment may be performed when a policy is updated between the MSA 520 and the MSE 530.
  • the MSA 520 authorizes a request (eg, a service permission request). May transmit a message (eg, an authorization request message) to the MMP server 430.
  • a request eg, a service permission request
  • the MSA 520 may request the MMP server 430 to authorize the use of a service based on authentication information (eg, an Auth Code or additionally ID_token) obtained from the NAS signaling message.
  • the MSA 520 may perform authentication (eg, an authorization procedure) with the AA server 580 through the MMP server 430.
  • the MSA 520 provides (or transmits) the AA server 580 and at least one or both of an Auth Code or ID_token to the MMP server 430, thereby granting service authorization. You can request authentication (eg, an authorization procedure) with the AA server 580 through the MMP server 430.
  • the MSA 520 provides (or transmits) the AA server 580 and at least one or both of an Auth Code or ID_token to the MMP server 430, thereby granting service authorization. You can request
  • the MMP server 430 provides (or transmits) authentication information to the electronic device 101 (eg, the MSA 520) in response to the authorization request (eg, an authorization request message) of the MSA 520. )can do.
  • the authentication information may include, for example, a connection token (eg, MAT) and MMP Info.
  • the MMP server 430 may transmit a response including the access token and MMP Info to the MSA 520 during or after performing authentication of the MSA 520.
  • the MSA 520 may activate the MSE 530.
  • the MSA 520 receives authentication information (eg, access token (MAT), MMP Info) from the MMP server 430
  • the MSA 520 receives the received authentication information (eg, access token (MAT), MMP Info) may be delivered to the MSE 530 to activate the MSE 530.
  • the MSA 520 along with the access token (MAT), access address (eg, URI or IP address) of the new MMP server 430 to contact to perform the MEC discovery procedure, DNS server address, or At least one additional information such as a DNN to be used may be delivered to the MSE 530.
  • the MSA 520 may enable the MSE 530 based on the received access token (MAT) and / or other additional information.
  • the MSA 520 may receive an access token (eg, a MAT) from the MMP server 430. For example, by calling enableMecEnablingLayer (true, MMP Info, MAT) of the MSE API, MMP access information (MMP Info) and access token (MAT) may be delivered to the MSE 530.
  • the MSE 530 receives authentication information (eg, MAT) and / or other additional information (eg, MMP Info, DNS server address, or DNN to use), and receives the authentication information and / or additional information.
  • the MEC discovery procedure can be performed based at least on.
  • the MSE 530 may perform the MEC discovery procedure after connecting to the corresponding MMP server 430 using MMP Info and MAT.
  • 15B is a diagram illustrating an example of an authentication procedure according to various embodiments.
  • FIG. 15B may show an example of signal flow for an authentication procedure (eg, scenario C for AA and policy update) according to various embodiments.
  • FIG. 15B illustrates an example of an MEC service authentication flow for scenario C (eg, an authentication procedure according to FIG. 15A) of an authentication procedure according to various embodiments, and illustrates a 5G NAS-based model (5G NAS-based Mode). ) Can be used to represent a scenario.
  • scenario C eg, an authentication procedure according to FIG. 15A
  • 5G NAS-based Model 5G NAS-based Mode
  • the MSA 520 of the electronic device 101 receives an MMP Info (eg, URI, DNN), Auth from a NAS message received through an AMF / PCF server 590 and NAS signaling.
  • MMP Info eg, URI, DNN
  • Auth e.g., URI, DNN
  • NAS message may further include an ID-token.
  • the MSA 520 uses the information obtained as a result of NAS signaling to send a message (eg, an authorization request message) to an authorization request (eg, a service permission request) to the MMP server 430. ) Can be sent.
  • the MSA 520 may transfer the obtained information (eg, MMP Info, Auth Code, CARP, or URSP rule) to the MMP server 430 and request authorization from the MMP server 430.
  • the MMP server 430 may request an access token for accessing user profile information from the AA server 580.
  • the MMP server 430 may request an access token from the AA server 580. Can be obtained.
  • the MMP server 430 may obtain a user profile using the access token.
  • the MMP server 430 may transfer the MMP information and the authorization code to the AA server 580 and may request and obtain an access token for accessing user profile information.
  • the MMP server 430 may transmit an authorization response corresponding to the authorization request to the MSA 520.
  • the MMP server 430 checks the user profile using the access token, and if it is confirmed that the MEC service is available based on the user profile, the MMP for MEC discovery as a result of the authorization procedure
  • Authorization response may be sent to MSA 520 including Info, access token (eg MAT), and / or route policy (eg CARP or URSP rules) for MEC data services.
  • the MSA 520 may obtain a connection token (eg, a MAT) as a result of the authorization procedure.
  • a connection token eg, a MAT
  • the MSA 520 receives an access token as a result of the authorization procedure, and the MSE 530 through the MSE API. It can pass MMP information and access token.
  • the MSE 530 performs an authorization procedure with the MMP server 430, first, the MA 520, which has completed authentication, receives the MMP information and authorization code (Auth) code) and optionally ID_token may be delivered to the MSE 530 via the MSE API.
  • the MSE 530 may directly perform an authorization procedure with the MMP server 430 based on the information transmitted from the MSA 520, and receive the access token as a result.
  • the MSA 520 may perform the MEC discovery procedure using the MMP Info and the access token through the MSE 530.
  • 16 is a flowchart illustrating a method of operating the electronic device 101 according to various embodiments.
  • the processor 120 (or the MEC service module 410 of FIG. 4) of the electronic device 101 may use the MSA 520 (or service agent) to designate an external server of a network.
  • MSA 520 or service agent
  • authentication for MEC services eg user authentication or service authentication
  • the processor 120 may receive authentication information according to an authentication result from an external server.
  • the processor 120 selectively selects the MSE 530 (or service enabler) and policy update based on receiving the authentication information. It can be done with
  • the processor 120 may obtain a token for accessing the MMP Info and the MMP server 430 based on the authentication information.
  • the processor 120 may transmit the MMP Info and the token to the MSE 530 through the MSE API to activate the MSE 530.
  • the processor 120 may access the MMP server 430 through the MSE 530 to perform a MEC discovery procedure.
  • 17 is a diagram illustrating an example policy update operation in the electronic device 101 according to various embodiments of the present disclosure.
  • FIG. 17 may represent an example of PDU session establishment during policy update (eg, PDU session establishment), and PDU session establishment (or PDN connection establishment).
  • An operation example for dedicated DNN activation may be illustrated in FIG.
  • the PDU session setup may be used to create a new PDU session establishment, release an existing PDU session, and update an existing PDU session (eg, characteristics per PDU session). Configuration (for example, QoS information such as bandwidth or latency)), and FIG. 17 shows an example of generating a PDU session.
  • the electronic device 101 may include an MSA (or service agent) 520, an MSE (or service enabler) 530, and a modem (or CP, communication processor) 1700. have.
  • the MSA 520 provides the MSE 530 with a first message (eg, setUrspDNN) instructing to set the DNN when obtaining (or receiving) information about the DNN configuration ( Or transfer).
  • a first message eg, setUrspDNN
  • the MSE 530 may update (eg, update DNN Info) DNN information based on a first message (eg, setUrspDNN) provided from the MSA 520.
  • a first message eg, setUrspDNN
  • the MSA 520 may provide a second message (eg, requestPduSession) to the MSE 530 instructing to create a PDU session (or PDN connection).
  • a second message eg, requestPduSession
  • the MSE 530 when receiving the second message (eg, requestPduSession), the MSE 530 provides the modem 1700 with a third message (eg, setup data call) instructing to set up a data call. can do.
  • a third message eg, setup data call
  • the modem 1700 when the modem 1700 receives a third message (eg, setup data call) from the MSE 530, the modem 1700 sets up a data call based on preconfigured information for processing of a service (eg, an MEC service). Or set up a data call based on the indicated information and provide a fourth message (eg, a response message) corresponding to the third message to the MSE 520.
  • the PDU session may be generated based on the modem 1700 requesting the core network (eg, SMF) to create a PDU session by a third message (eg, setup data call).
  • a fifth message (eg, notifying that a PDU session has been established) is received. onAvaible) may be provided to the MSA 520.
  • the MSA 520 may send a sixth message (eg, to indicate setting of the URSP rule when the URSP rule is received using one of the above-described schemes or through another scheme).
  • setUrspRules may be provided to the MSE 530.
  • the MSA 520 sends a seventh message (eg, setMaServiceEnableMode (true)) to the MSE 530 instructing it to execute a MEC service activation mode (eg, MSE activation). Can provide.
  • the MSE 530 generates (or adds) a routing table based on the sixth message (eg, setUrspRules) and the seventh message (eg, setMaServiceEnableMode (true)) received from the MSA 520. (add)).
  • the URSP rule may include application-specific or URI-used PDU session information.
  • the electronic device 101 when generating a PDU session, sets the setUrspRules API to set the data path for the corresponding application ID (AppID) or URI to the PDU session on the URSP rule. You can set up a routing table.
  • AppID application ID
  • URI URI
  • FIG. 18 is a diagram illustrating an example of a PDU session establishment operation in the electronic device 101 according to various embodiments.
  • FIG. 18 may show an example of a PDU session release during a policy update (eg, PDU session establishment), and release a PDU session (or PDN connection) ( An example of the operation to release) may be shown.
  • the PDU session setup may be used to create a new PDU session establishment, release an existing PDU session, and update an existing PDU session (eg, characteristics per PDU session). Configuration (for example, QoS information such as bandwidth or latency)), and FIG. 17 shows an example of PDU session release.
  • the electronic device 101 may include an MSA (or service agent) 520, an MSE (or service enabler) 530, and a modem (or CP, communication processor) 1700. have.
  • the MSA 520 when the MSA 520 needs to release information on DNN configuration, the MSA 520 sends a first message (eg, setUrspDNN) instructing to release the corresponding DNN to the MSE 530. Can be provided (or delivered).
  • a first message eg, setUrspDNN
  • the MSE 530 sends a second message (eg, release data call) to instruct to release a data call based on a first message (eg, setUrspDNN) provided from the MSA 520. May be provided to the modem 1500.
  • a second message eg, release data call
  • a first message eg, setUrspDNN
  • the modem 1700 when the modem 1700 receives a third message (eg, a release data call) from the MSE 530, the modem 1700 releases a configuration configured for processing of a corresponding service (eg, an MEC service), and the MSE 530. ) May provide a fourth message (eg, a response message) corresponding to the third message.
  • the PDU session may be released based on the modem 1700 requesting the PDU session release from the core network (eg, SMF) by a third message (eg, release data call).
  • the MSA 520 may provide a fifth message (eg, setMaServiceEnableMode (false)) to the MSE 530 instructing to execute a MEC service deactivation mode (eg, MSE deactivation).
  • a fifth message eg, setMaServiceEnableMode (false)
  • MSE deactivation mode eg, MSE deactivation
  • the MSE 530 stores (or creates) in a memory (eg, memory 130 of FIG. 1 or 2) based on a fifth message (eg, setMaServiceEnableMode (false)) received from the MSA 520.
  • Deleted routing tables can be deleted from memory.
  • 19 is a flowchart illustrating a method of checking whether MEC-based data transmission is possible in the electronic device 101 according to various embodiments of the present disclosure.
  • the operations shown in FIG. 19 may be performed, for example, when the electronic device 101 attaches to the operator network, when the operator network changes (eg, roaming abroad). , According to a specified period, or when at least one of the subscriber information is changed.
  • the electronic device 101 may determine whether a network to which the electronic device 101 is connected is a network capable of transmitting MEC-based data.
  • the MEC service module 410 eg, the MSE 530
  • the MEC service module 410 may include a cell ID, a public land mobile network (PLMN), or a data network name (DNN) of a network to which the electronic device 101 is connected. It may be determined whether MEC-based data transmission is possible based on at least one of an access point name (APN)
  • APN access point name
  • at least one of a cell ID, a PLMN, or a DNN is pre-registered in the electronic device 101. The information may be obtained from the electronic device 101 by requesting the MEC system 405.
  • the electronic device 101 may check the MEC service level of the network to which the electronic device 101 is connected.
  • the MEC service level may include, for example, at least one of an MEC usage right or an MEC quality of service (QoS).
  • QoS MEC quality of service
  • the MEC QoS may refer to information about a quality of service grade that is differentially applied according to subscription information for each user.
  • premium subscribers may provide more types of MEC service applications and / or MEC host resources (eg, resources such as bandwidth, memory, cpu, or gpu).
  • the electronic device 101 may check the MEC service level by using at least one of information related to a SIM (or USIM) or user subscription information (eg, IMEI) of the electronic device 101.
  • SIM or USIM
  • IMEI user subscription information
  • the electronic device 101 when the network to which the electronic device 101 is connected is capable of transmitting MEC data and has the authority to use the MEC of the electronic device 101, the electronic device 101 may perform a discovery procedure. According to an embodiment, the electronic device 101 may prevent unnecessary discovery by checking whether the MEC data can be transmitted or the MEC service level before performing the discovery procedure.
  • the MEC discovery procedure may include obtaining an app list (eg, MEC Application Look-up, Application Context Create, MEC host selection, and / or DNS resolving). ) May be included.
  • an app list eg, MEC Application Look-up, Application Context Create, MEC host selection, and / or DNS resolving.
  • 20 is a diagram illustrating an example of a discovery procedure according to various embodiments of the present disclosure.
  • the MEC service module 410 may detect an event (eg, a discovery trigger) related to mobility of the electronic device 101.
  • an event related to mobility may include, for example, detecting a movement of the electronic device 101, detecting a change of a base station connected to the electronic device 101, or an electronic device 101. It may include an operation for detecting entering the designated area.
  • the designated area may mean, for example, at least one of an LADN, a TA, a cell of a base station, an area where handover between base stations occurs, or an area determined by a location based service.
  • the electronic device 101 may be configured to detect an event related to mobility (eg, at least one sensor of a sensor module 176 of FIG. 1, a communication processor, such as a coprocessor of FIG. 1). 123)), LADN sensing module, or GPS sensing module).
  • the MEC service module 410 receives an event regarding a mobility related event of the electronic device 101 from the corresponding module or monitors an event related to mobility of the electronic device 101 by monitoring the corresponding module. It can be detected.
  • the MEC service module 410 may perform a MEC discovery procedure.
  • the MEC discovery procedure may, for example, perform a series of operations in which the electronic device 101 identifies (or discovers) application (s) (eg, MEC application (s)) that can be provided by the MEC system 405. Can mean.
  • the MEC discovery procedure can include operations 2003-2005.
  • the MEC service module 410 may provide the client application 510 with information indicating that an event related to mobility of the electronic device 101 is detected.
  • the MEC service module 410 provides the MEC system 405 (eg, the MMP server 430 or the LCM proxy server) with information regarding the applications that the MEC system 405 can provide. You can request For example, the MEC service module 410 may transmit an application lookup request message to the MEC system 405. According to one embodiment, the information about the applications that the MEC system 405 can provide may be referred to as an app list. According to an embodiment of the present disclosure, the data packet transmitted in operation 2003 may be a first data packet including control data and may include a first address associated with the MEC service module 410.
  • the MEC service module 410 may request information about applications that the MEC system 405 can provide from a third server (not shown) separate from the MEC system 405.
  • the third server may be disposed inside or outside the operator network to which the electronic device 101 is connected.
  • the electronic device 101 may obtain information about the operator network from the network information, and request the third server for information about applications that the MEC system 405 can provide, based on the obtained information.
  • the MEC service module 410 may receive information (eg, an app list of available applications) about applications that the MEC system 405 can provide from the MEC system 405. .
  • the MEC service module 410 sends an application lookup request message to the MEC system 405 (eg, operation 2003) and the corresponding application lookup response from the MEC system 405.
  • the application list of available applications may be obtained by receiving an application lookup response message.
  • an example of a parameter (for example, an app list request parameter) that may be included in an application lookup request message may be represented as shown in Table 1 below.
  • the app list request parameter may include, for example, clientappName, locationInfo, deviceType, serviceType, contextType, or URI request in addition to the parameters defined in the ETSI MEC standard. It may include at least one.
  • clientappName may indicate application names (eg, AppNames) received from the MSA 520.
  • “Location Info” may include a connection cell ID, a tracking area ID, area information (eg, city, ward, town, building,...), or preferred location information specified by a user. Can be represented.
  • “Device Type” may indicate the type of electronic device 101 such as a smartphone, tablet, wearable, IoT, car, or drone.
  • “Service Type” may indicate a type of service such as Game, V2X, AR / VR, LBO, Enterprise, or Web.
  • “Context Type” may indicate whether context information of a user or an application is required for driving the MEC application.
  • the “URI Request Flag” may indicate a flag requesting that the URI be included in the response when the URI of the MEC application is available.
  • an example of a parameter (eg, an app list response parameter) that may be included in the application lookup response message may be represented as shown in Table 2 below.
  • Table 2 below may show an example of an app list of available applications that the MEC service module 410 receives from the MEC system 405.
  • Y appInfo Structure One
  • Y appDId String One Identifier of this MEC application descriptor. It is equivalent to the appDId defined in clause 6.2.1.2 of ETSI GS MEC 010-2 [1].
  • This attribute shall be globally unique.
  • Y appName String One Name of the MEC application.The length of the value shall not exceed 32 characters.
  • Y appProvider String One Provider of the MEC application.The length of the value shall not exceed 32 characters.
  • Y appSoftVersion String One Software version of the MEC application.The length of the value shall not exceed 32 characters.
  • Y appDVersion String One Identifies the version of the application descriptor. It is equivalent to the app DVersion defined in clause 6.2.1.2 of ETSI GS MEC 010-2 [1].
  • Y appDescription String One Human readable description of the MEC application (see note 2).
  • Y referenceURI URI 0 ... 1 Address of the MEC application.This can be provided if the address of the MEC application is currently available.
  • N clientAppName String 0 ... N Client app name that is allowed to connect to the mec application.
  • N clientAppPackageURL String 0 ... 1 Address for downloading the corresponding client application package to connect with the MEC application
  • N uriTTL uint32 0 ...
  • Time-to-live of the reference URI N >> uriLOC String 0 ... 1 Location (range) where the reference URI is available N >> carpRule Structure 0 ... 1 Client App Routing Policy Rules N >>> DNN String 0 ... 1 DNN selection for this application N >>> S-NSSAI String 0 ... 1 Network slice selection for this application N >>> accessType String 0 ... 1 Preferrend access type for this application (e.g., 4G, 5G, WiFi, etc) N >>> sessionType String 0 ... 1 Ipv4, ipv6, etc N >>> mptcp Boolean 0 ... 1 Indicates whether to use MPTCP for the matching application N >> fqdnList StringArray 0 ...
  • the app list response parameter may include, for example, referenceURI, clientAppName, clientAppPackageURL, uriTTL, uriLOC, carpRule, DNN, It may include at least one of S-NSSAI, accessType, sessionType, mptcp, or fqdnList.
  • information regarding applications that may be provided by the MEC system 405 may include an identifier of a base station to which the electronic device 101 is currently connected. , At least one piece of information available in correspondence with at least one location information of an ID, GPS information, tracking area (TA), or Wi-Fi ID of a neighboring base station.
  • the information about the applications that the MEC system 405 may provide may include information about a state of the electronic device 101 requested by the application (for example, a moving (or moving) speed of the electronic device 101, One or more pieces of information available for the screen on / off, battery level, base station received signal strength, timeout information, or distance information between the electronic device 101 and the MEC host.
  • a state of the electronic device 101 requested by the application for example, a moving (or moving) speed of the electronic device 101, One or more pieces of information available for the screen on / off, battery level, base station received signal strength, timeout information, or distance information between the electronic device 101 and the MEC host.
  • the information about the applications that the MEC system 405 can provide may include a domain name of an application that the MEC system 405 can provide.
  • the electronic device 101 can access the MEC application using a domain name.
  • an embodiment in which the electronic device 101 uses a domain name will be described with reference to the following drawings (eg, FIGS. 36 to 40).
  • the information regarding the applications that the MEC system 405 may provide may include the IP addresses of the MEC system 405 (or the MEC host 447 or the MEC application (eg, 460-1, 460-2). It may further include.
  • the MEC service module 410 may perform a MEC discovery procedure in association with establishment of a LADN dedicated PDU session. For example, the MEC service module 410 may perform a MEC discovery procedure when a PDU session (eg, a LADN only session) is established, or perform a MEC discovery procedure to obtain a suitable result (eg, the name or app of a specified application). If a list is received, a PDU session (eg, a LADN-only session) may be established.
  • a PDU session eg, a LADN-only session
  • the MEC service module 410 may directly perform operation 2007 without performing a discovery procedure.
  • the MEC service module 410 does not perform a discovery procedure when an app list of available applications is already stored in the electronic device 101, and a specified cycle of updating the app list has not passed or there is no update request. You may not.
  • the MEC service module 410 may further include checking whether the MEC-based data transmission is possible in the network to which the electronic device 101 is connected before performing the discovery procedure.
  • the MEC service module 410 may monitor context information of the electronic device 101 before or after an event related to mobility of the electronic device 101 is detected. It may be.
  • the MEC service module 410 may monitor context information before operation 2001, after operation 2001, after operation 2003, or after operation 2005.
  • the context information may be monitored while the application processor (AP) of the electronic device 101 (eg, the processor 120 of FIG. 1) is continuously activated.
  • AP application processor
  • a separate module eg, at least one of the communication module 190 or the sensor module 176 of FIG. 1 that senses that the same condition is satisfied may deliver a message to the MEC service module 410.
  • the MEC service module 410 may include at least one application (eg, a client application) among applications installed in the electronic device 101 based on at least one of an app list or monitored context information. 510) may determine that a condition (eg, a first condition) for using data transmission based on the MEC is satisfied.
  • the MEC service module 410 may include (1) an application corresponding to an application for which data transmission based on the MEC is available in the received app list, or (2) the electronic device 101 may have an application.
  • the MEC service module 410 receives 'information about the state of the electronic device 101 in which the application is available' (for example, the moving speed of the electronic device 101 and the screen ON) received in operation 2005. / OFF, battery level, base station received signal strength, time-out information)) if there is at least one available application corresponding to the first condition can be determined to be satisfied.
  • the first application indicates that the electronic device 101 lasts about 1 minute or more in a state of no mobility, the screen is turned on, and the base station signal strength is greater than or equal to the threshold.
  • State information of the electronic device 101 may be requested.
  • the second application eg, the second App 310-2 of FIG. 3
  • the MEC service module 410 may determine that the first condition is satisfied when the state of the electronic device 101 matches state information requested by each application.
  • the MEC service module 410 may perform operation 2009 without performing operation 2007.
  • the MEC service module 410 may transmit a notification message indicating that the MEC-based data transmission is available to the client application 510.
  • the MEC service module 410 may apply the application layer 446 to the application layer. You can send a message to guide the installation (or storage) of.
  • the MEC service module 410 may not perform operation 2009.
  • the MEC service module 410 may include a graphical user interface (GUI) indicating that MEC-based data transmission of a specific application is available on a display (eg, the display device 160 of FIG. 1) of the electronic device 101. ) Can be displayed on the icon of the application.
  • GUI graphical user interface
  • the MEC service module 410 may display the MEC performance (eg, signal strength) of an application for which MEC-based data transmission is available. The signal strength may be expressed as, for example, 'good', 'normal', or 'bad'.
  • the MEC service module 410 may make a request (eg, context create) to execute a MEC application included in the MEC system 405.
  • a request eg, context create
  • the context creation may be performed not only in the MEC service module 410 but also in the client application 510.
  • the MEC service module 410 may perform context creation. For another example, the MEC service module 410 may perform context creation according to a specified period. For another example, the MEC service module 410 may generate a context when an event related to mobility of the electronic device 101 is detected.
  • domain name e.g. a uniform resource identifier (URI)
  • URI uniform resource identifier
  • the MEC service module 410 may perform context creation with the MEC system 405 (eg, the MMP server 430) on the MEC control plane.
  • the MEC system 405 eg, the MEP manager 445
  • the MEC system 405 may execute the MEC application.
  • the MEC system 405 eg, the MEC host 447. If the MEC application is not installed, the MEC system 405 (for example, the MEP manager 445) may be executed after installing the MEC application.
  • the client application 410 may perform data transfer with the MEC system 405.
  • the client application 410 may perform data communication with the MEC application (eg, 460-1 or 460-2) of the MEC system 405 on the user plane.
  • the data packet transmitted and received in operation 2013 may be a second data packet including user data and may include a second address associated with the client application 410 (or the MEC application).
  • the MEC service module 410 obtains the IP address of the MEC host 447 (or MEC application) before operation 2013, the client application 410 transmits data using the obtained IP address. Can be performed. An embodiment of obtaining the IP address of the MEC host 447 or the MEC application is described below with reference to FIGS.
  • the client application 410 may perform data transmission based on hypertext transfer protocol (HTTP) on an application layer (eg, the user plane of FIG. 3).
  • HTTP hypertext transfer protocol
  • the electronic device 101 may perform data transmission based on another protocol in addition to HTTP.
  • the electronic device 101 may be based on a remote procedure call (RPC) protocol or may be a lower layer of the application layer 446 (eg, transmission control protocol / internet protocol) or UDP / IP (user datagram). protocol / internet protocol)).
  • RPC remote procedure call
  • the MEC service 410 may request termination of the MEC application (eg, context delete) in response to detecting that the electronic device 101 has moved out of the designated area.
  • termination of the MEC application eg, context delete
  • the electronic device 101 allows the MEC service module 410 to collectively trigger the MEC-based data transmission of a plurality of applications according to a specified condition through the above-described various methods, thereby resulting in individual data transmission.
  • the load on the electronic device 101 can be reduced.
  • the electronic device 101 may receive a MEC based service from an enterprise or a school.
  • the electronic device 101 detects an event related to mobility of the electronic device 101 (for example, operation 2001)
  • the electronic device 101 transmits to the enterprise or school through the MEC discovery procedure (for example, operation 2003 to operation 2005).
  • the provided MEC-based service (or an application supporting the MEC-based data transmission) may be identified.
  • the electronic device 101 may be a location (eg, enterprise) of the electronic device 101 determined using at least one of a positioning technology (eg, a positioning technology based on cellular, satellite, or Wi-Fi) or the sensor module 176. Alternatively, it may be detected that there is a MEC application available in the school (eg, operation 2007).
  • the electronic device 101 receives a beacon signal from a beacon device installed inside an enterprise (or school) or is used by the electronic device 101 through near field communication (NFC) tagging. It can detect that there is a possible MEC application.
  • the MEC service module 410 may transmit a notification message to an application capable of performing MEC-based data transmission in an enterprise or a school (eg, operation 2009).
  • the application receiving the notification message may be automatically executed in the electronic device 101 or may display a user interface indicating that the corresponding application is available through a display (for example, the display device 160 of FIG. 1).
  • the electronic device 101 may receive a service from a company or a school through data transmission based on the MEC (eg, operation 2013).
  • the electronic device 101 may receive a MEC based service from a place (eg, a department store or a shopping mall) that provides an advertisement or a coupon.
  • a place eg, a department store or a shopping mall
  • the electronic device 101 may identify a MEC-based service provided in a department store or a shopping mall through a MEC discovery procedure (for example, operation 2003 to operation 2005).
  • MEC discovery procedure for example, operation 2003 to operation 2005.
  • the electronic device 101 detects that there is a MEC application available at the location of the electronic device 101 (eg, a specific area of a department store (or shopping mall)) determined using at least one of the location measuring technology or the sensor module 176. Can be done (eg operation 2007).
  • the MEC service module 410 transmits a notification message to an application capable of performing MEC-based data transmission in a department store or a shopping mall (for example, operation 2009), and the application receiving the notification message may display an advertisement or a coupon in a pop-up form. Can be.
  • the electronic device 101 may receive a game service.
  • the electronic device 101 may obtain information about game applications through a MEC discovery procedure (for example, operations 2003 to operation 2005). Based on at least the information disclosed in Table 1, the electronic device 101 may use a criterion (eg, required by a game application installed in the electronic device 101) among game applications provided by the MEC system 405 (eg, the MEC server). A game application that satisfies memory, delay time, or frequency band may be determined (eg, operation 2007).
  • the electronic device 101 may detect the movement of the electronic device 101.
  • the MEC service module 410 transmits a notification message to the game application (for example, operation 2009), and when the game application is executed, the electronic device 101 may receive a service through data transmission based on the MEC (for example, Behavior 2013).
  • 21 is a flowchart illustrating an operation method for a discovery procedure in an electronic device 101 according to various embodiments of the present disclosure.
  • the operations illustrated in FIG. 21 may include, for example, the electronic device 101 or a component included in the electronic device 101 (eg, the processor 120 of FIG. 1 or the MEC service of FIG. 4). Module 410).
  • the electronic device 101 may detect an event related to mobility of the electronic device 101.
  • the electronic device 101 may determine location information (eg, LADN ID, TA ID, base station ID, or cell) received from a base station (eg, AN 302 of FIG. 3) to which the electronic device 101 is connected. Based on at least one of the IDs, based on a location measurement technology, or through an additional sensor module 176 mounted in the electronic device 101.
  • location information eg, LADN ID, TA ID, base station ID, or cell
  • the electronic device 101 may request information (eg, an app list) regarding applications that may be provided by the MEC system 405. According to an embodiment, the electronic device 101 may request an app list from the MMP server 430.
  • information eg, an app list
  • the electronic device 101 may request an app list from the MMP server 430.
  • the electronic device 101 may receive information about applications that the MEC system 405 can provide.
  • Information about applications that the MEC system 405 can provide includes, for example, information disclosed in Table 1, an ID of a base station to which the electronic device 101 is currently connected, an ID of a neighboring base station, and GPS information.
  • the electronic device 101 may receive information about applications that the MEC system 405 can provide.
  • Information about applications that the MEC system 405 can provide includes, for example, information disclosed in Table 1, an ID of a base station to which the electronic device 101 is currently connected, an ID of a neighboring base station, and GPS information.
  • the electronic device 101 may determine that an application (eg, the client application 510) installed in the electronic device 101 is based on at least one of information or context information about applications that the MEC system 405 may provide. It may be determined whether a first condition for performing data transmission based on the MEC is satisfied.
  • an application eg, the client application 510
  • the electronic device 101 may determine that an application (eg, the client application 510) installed in the electronic device 101 is based on at least one of information or context information about applications that the MEC system 405 may provide. It may be determined whether a first condition for performing data transmission based on the MEC is satisfied.
  • the electronic device 101 may perform data transmission through an application that satisfies the first condition.
  • an application that satisfies the first condition may perform data transmission on the application layer and the MEC application installed in the MEC system 405 (eg, the MEC server).
  • 22 is a flowchart illustrating an operation method for a discovery procedure in an electronic device 101 according to various embodiments of the present disclosure.
  • the processor 120 of the electronic device 101 obtains a MEC discovery policy from the MEC system 405 (or Receive).
  • the MSA 520 of the electronic device 101 may receive the MEC discovery policy from the MEC system 405 and transmit the MEC discovery policy to the MSE 530.
  • the MEC service module 410 may acquire the MEC discovery policy using the MSA 520 and perform a discovery procedure based on the received MEC discovery policy using the MSE 530.
  • the MSE 530 of the electronic device 101 may receive a MEC discovery policy from the MSA 520 through the MSE API.
  • the MEC discovery policy may include parameters as illustrated in Table 1.
  • the MEC discovery policy may include client application names (e.g. clientAppNames), location (e.g. locationInfo), device type (e.g. deviceType), service type (e.g. serviceType), context type (contextType), application URI request ( For example, it may include at least one of a URI request) or a dynamic DNN (eg, dynamicDnn).
  • the client application name may be information for requesting an app list for checking whether the MEC is available
  • the location is information for requesting a location-based app list according to the current location of the electronic device 101.
  • the dynamic DNN may be information for confirming whether to use a dynamic DNN update.
  • the electronic device 101 may request a list of apps corresponding to each type, including a device type and a service type, in the MEC discovery policy, and also transmit a context need of an application including a context type. It may be.
  • the electronic device 101 may include an application URI request in the MEC discovery policy and request to include the URI in the app list when the URI of the MEC application is available.
  • the processor 120 may obtain an app list of a serviceable MEC application from a designated external server (eg, the MMP server 430) based on the MEC discovery policy.
  • the MSE 530 of the electronic device 101 may perform an acquisition procedure (eg, MEC Application Look-up) to obtain an app list based on the MEC discovery policy received from the MSA 520. Can be.
  • the MSE 530 may request and receive a list of apps related to a serviceable MEC application to the MMP server 430 according to the MEC discovery policy.
  • the processor 120 may create an application context of the client application 510 (eg, an Appliction Context Create).
  • the MEC service module 410 may make a request (eg, context create) to execute a MEC application included in the MEC system 405.
  • the context creation may be performed not only in the MEC service module 410 but also in the client application 510.
  • the MEC service module 410 may detect the execution of the client application 510 by the MSA 520 itself, and the Context Create API provided by the MSA 520 or the MSE 530.
  • the client application 510 may call the corresponding API.
  • the client application 510 may provide (or deliver) an App Launch Detected or API (eg, Context Create API) call to the MSA 520.
  • App Launch Detected may indicate, for example, when the client application 510 is executed.
  • the API (Context Create) call may indicate, for example, a request for a URI for a MEC application name (eg, MEC App Name) to be connected.
  • the MSA 520 when the MSA 520 receives an App Launch Detected or API (Context Create) call, the MSA 520 sends a status notification message (for example, notifyClientAppState) that notifies the state of the client application 510. May be provided to the MSE 530.
  • a status notification message for example, notifyClientAppState
  • the status notification message includes, for example, the state (eg START) of the client application and the name (eg clientAppName) (and / or UID) of the client application (eg notifyClientAppState (START, clientAppName).
  • the MSA 520 may notify the MSE 530 of the execution state of the client application 510 by an MSE API call.
  • an external server eg, MMP
  • MMP an external server that is associated with the client application 510 and provides information related to the MEC application to which the client application 510 is to be connected, based on the app list.
  • the information related to the MEC application may include, for example, at least one of a URI for the MEC App Name, dedicated DNN information, or a MEC Application Package URI (eg, no MEC Application). It may include one.
  • the MSE 530 of the electronic device 101 receives a status notification message from the MSA 520, and based on the received status notification message, the MEC application (or the MEC host including the corresponding MEC application) For example, an edge server or an MEC server) may be performed (eg, application context create).
  • the application context generation may be activated by an MSE API call when the MSA 520 detects the execution of the client application 510.
  • the application context creation may be activated when the client application 510 calls a context create API.
  • the processor 120 may select a MEC host based on the obtained information.
  • the MSE 530 of the electronic device 101 may perform a host selection procedure (eg, MEC Host Selection) for selecting a DNS server and an MEC host.
  • the host selection procedure may be determined using preset information and / or information inquired by a DNS server, or information (or configuration) inquired by a DNS server and / or a user may be selected (or configured). Can be done.
  • the processor 120 may perform data transmission with the selected MEC host.
  • the client application 510 may perform data transmission on the application layer and the MEC application installed in the MEC system 405 (eg, the MEC server).
  • 23 is a diagram illustrating an example of a discovery procedure according to various embodiments.
  • FIG. 23 may show an example of an application state-based MEC discovery procedure.
  • the electronic device 101 may include a client application (or client app) 510, an MSA (or service agent) 520, an MSE (or service enabler) 530 (eg, an MEL 531). , UHL 533), and DNS cache 2310.
  • client application or client app
  • MSA or service agent
  • MSE or service enabler
  • the MSA 520 of the electronic device 101 may set a MEC discovery policy with the MSE 530.
  • the MEC discovery policy may include a client application name (for example, clientAppNames) and a discovery policy (for example, discoveryPolicy).
  • the discoveryPolicy may include whether to use a dynamic DNN (eg, dynamicDnn), and may include location (eg, locationInfo), device type (eg, deviceType), service type (eg, serviceType), or context type ( For example, contextType) may be provided, including at least one of the information of Table 1).
  • the MSA 520 receives the location of the app list including the locationInfo (eg, locationInfo), device type (eg, DeviceType), and service type (eg, ServiceType) in the discoveryPolicy, and restricts only the list of apps that meet the corresponding conditions. You can also do that.
  • the MSA 520 may include information on whether an application context is required by including a context type (eg, contextType) in the discoveryPolicy.
  • the MSA 520 may include the URI Request Flag in the discoveryPolicy and request to include the URI in the app list when the URI of the MEC application is available.
  • the client application names may be information for requesting an app list for checking whether the MEC is available
  • the location is a location-based app according to the current location of the electronic device 101. It may be information for requesting a list
  • dynamic DNN may be information for confirming whether to use dynamic DNN update.
  • the MSE 530 performs an acquisition procedure (eg, MEC Application Look-up) to obtain an app list (eg, AppList) based on information received from the MSA 520 (eg, MEC discovery policy). Can be done.
  • an acquisition procedure eg, MEC Application Look-up
  • MEC Application Look-up may be started between the MSA 520 and the MSE 530 to acquire an app list according to the MEC discovery policy setting.
  • the MSE 530 may activate the MEC Application Look-up, and the specific condition (eg, electronic) of the electronic device 101 may be activated.
  • the device 101 may perform (or start) when the access base station Cell ID is changed while moving.
  • the MSE 530 may request and receive an app list (eg, MEC AppList) related to a serviceable MEC application (eg, MEP App) to the MMP server 430 according to the MEC discovery policy.
  • the MSE 530 may request the MMP server 430 by writing a MEC discovery policy to the MEC AppList request message Parameter as illustrated in Table 1, and the MMP server 430 may be configured accordingly.
  • a service available app list (eg, MEC AppList in Table 2) may be provided to the MSE 530 to respond to a request of the MSE 530.
  • An app list acquisition procedure (eg, MEC Application Look-up) according to various embodiments will be described in detail with reference to the accompanying drawings.
  • the client application 510 may provide (or deliver) an App Launch Detected or API (Context Create) call to the MSA 520.
  • the case of App Launch Detected may represent a case where the client application 510 is executed.
  • the API (Context Create) call may represent a case of requesting a URI for a MEC application name (eg, MEC App Name) to be accessed.
  • a notification message (eg, notifyClientAppState) to notify the state of the client application 510. ) Can be provided.
  • a notification message (eg, notifyClientAppState) includes, for example, the state of the client application (eg START) and the name of the client application (eg clientAppName) (and / or UID) (eg, notifyClientAppState). (START, clientAppName)).
  • the MSE 530 receives a notification message (eg, notifyClientAppState) from the MSA 520, and based on the received notification message, the MEC application (or an MEC host including the MEC application (eg, an edge server or MEC server)) (for example, application context create) can be performed.
  • the MSE 530 may activate the creation of an application context when receiving an event related to the execution of the client application 510 from the MSA 520.
  • the MSE 530 may perform an application context creation operation for finding a MEC host including a desired MEC application through the MMP server 430 based on the received notification message (eg, notifyClientAppState). Can be.
  • the application context creation may be activated (or performed) by an MSE API call when the MSA 520 detects the execution of the client application 510.
  • the application context creation may be activated (or performed) when the client application 510 calls a context create API.
  • the MSE 530 may request and receive a URI for the MEC application name (eg, MEC App Name) to be accessed from the MMP server 430.
  • the MSE 530 may request and receive information about a dedicated DNN from the MMP server 430 as needed.
  • the MMP server 430 may transmit a MEC application package URI to the MSE 530.
  • the MSE 530 may perform a host selection procedure (eg, MEC Host Selection) for selecting the DNS server 2320 and the MEC host.
  • a host selection procedure eg, MEC Host Selection
  • the MSE 530 may select a host selection procedure (eg, MEC) for selecting one of the MEC hosts and the DNS server 2320. Host Selection).
  • the host selection procedure for selecting one MEC host may be determined using preset information and / or information inquired by the DNS server 2320, or the DNS server 2320. Information and / or the user can be asked to select (or configure) a particular MEC host.
  • preset information for configuring a specific MEC host may include priority information.
  • the host selection procedure may include a DNS pre-resolving operation and a MEC host prioritization operation.
  • DNS pre-resolving is the DNS for the fully qualified domain name (FQDN) for the MEC itself, for example, in the MSE 530 itself, regardless of the DNS query of the client application 510. Performing resolving.
  • DNS resolving may be performed using a URI or a domain name received through the MEC Application Look-up step of the operation 2303 or the Application Context Creat step of the operation 2309.
  • MEC Host Prioritization may include, for example, setting an IP priority when a plurality of IP addresses are received in a DNS query response.
  • a host selection procedure eg, MEC Host Selection
  • MEC Host Selection is described in detail with reference to the following drawings.
  • the client application 510 may perform a DNS resolving operation using the information obtained through the above operation.
  • DNS resolving may be performed, for example, when a DNS query is generated by the client application 510.
  • DNS resolving may include, for example, client-driven normal DNS resolving or DNS proxying (hooking DNS query). DNS resolving according to various embodiments is described in detail with reference to the following drawings.
  • 24 is a flowchart illustrating an operation method for a discovery procedure in an electronic device 101 according to various embodiments of the present disclosure.
  • the processor 120 (or the MEC service module 410 of FIG. 4) of the electronic device 101 may receive a MEC discovery policy.
  • the MSA 520 of the electronic device 101 may set the MEC discovery policy to the MSE 530.
  • the MSE 530 of the electronic device 101 may receive a MEC discovery policy from the MSA 520 through the MSE API.
  • the MEC discovery policy may include at least one of information (or parameters) as described in the description with reference to ⁇ Table 1>.
  • the processor 120 may obtain an app list of a serviceable MEC application from a designated external server (eg, the MMP server 430) based on the MEC discovery policy.
  • the MSE 530 of the electronic device 101 may perform an acquisition procedure (eg, MEC Application Look-up) to obtain an app list based on the MEC discovery policy received from the MSA 520. Can be.
  • the MSE 530 may request and receive a list of apps related to a serviceable MEC application to the MMP server 430 according to the MEC discovery policy.
  • the processor 120 may detect and hook a DNS query generated by the client application 510.
  • the client application 510 of the electronic device 101 may transmit a message (eg, a DNS query message) for a DNS query to the MSE 530.
  • the DNS query may occur in the client application 510, and in general, the DNS query may be forwarded to the DNS server 2320 to provide a response to the DNS query at the DNS server 2320.
  • the DNS query may be detected by the MSE 530 (eg, DHL 535) of the electronic device 101.
  • the DNS query generated by the MSE 530 is detected and hooked before being delivered to the DNS server 2320, an operation 2407 described below. (Eg, Context Create) and operation 2409 (eg, DNS resolving), which will be described later, and then forward a DNS response to the client application 510.
  • Context Create e.g., Context Create
  • operation 2409 e.g, DNS resolving
  • the processor 120 may determine information related to the MEC application that is associated with the client application 510 and to which the client application 510 is to be connected, based on the app list. : May be obtained from the MMP server 430.
  • the information related to the MEC application may include, for example, at least one of a URI for the MEC App Name, dedicated DNN information, or a MEC Application Package URI (eg, no MEC Application). It may include one.
  • the MSE 530 of the electronic device 101 may perform an application context creation operation with the MMP server 430 in response to a DNS query from the client application 510.
  • the MSE 530 may generate an application context for the corresponding MEC application when a DNS query (with FQDN) message is generated in the client application 510.
  • the processor 120 may select a MEC host based on the obtained information.
  • the MSE 530 of the electronic device 101 may perform a host selection procedure (eg, MEC Host Selection) for selecting the DNS server 2320 and the MEC host.
  • the host selection procedure may be determined using preset information and / or information inquired by the DNS server 2320, or information inquired by the DNS server 2320 and / or a user in order to determine a specific MEC. You can select (or configure) a host.
  • the processor 120 may transmit a DNS response to the client application after selecting the MEC host.
  • the MSE 530 of the electronic device 101 may provide the client application 510 with information obtained through the above procedures as a DNS response.
  • the MSE 530 may transmit a DNS response corresponding to the DNS query to the client application 510 that provides the DNS query after selecting the MEC host.
  • the processor 120 may perform data transmission with the selected MEC host.
  • the client application 510 may perform data transmission on the application layer and the MEC application installed in the MEC system 405 (eg, the MEC server).
  • 25 is a diagram illustrating an example of a discovery procedure according to various embodiments.
  • FIG. 25 may show an example of a DNS Query-based MEC discovery procedure.
  • the electronic device 101 may include a client application (or client app) 510, an MSA (or service agent) 520, an MSE (or service enabler) 530 (eg, an MEL 531). , UHL 533), and DNS cache 2310.
  • the MSA 520 of the electronic device 101 may set a MEC discovery policy with the MSE 530.
  • the MEC discovery policy may include a client application name (for example, clientAppNames) and a discovery policy (for example, discoveryPolicy).
  • the discoveryPolicy may include whether to use a dynamic DNN (eg, dynamicDnn), and may include location (eg, locationInfo), device type (eg, deviceType), service type (eg, serviceType), or context type ( For example, contextType) may be provided, including at least one of the information of Table 1).
  • the MSA 520 receives the location of the app list including the locationInfo (eg, locationInfo), device type (eg, DeviceType), and service type (eg, ServiceType) in the discoveryPolicy, and restricts only the list of apps that meet the corresponding conditions. You can also do that.
  • the MSA 520 may include information on whether an application context is required by including a context type (eg, contextType) in the discoveryPolicy.
  • the MSA 520 may include the URI Request Flag in the discoveryPolicy and request to include the URI in the app list when the URI of the MEC application is available.
  • the MSE 530 performs an acquisition procedure (eg, MEC Application Look-up) for obtaining an app list (eg, AppList) based on information received from the MSA 520 (eg, MEC discovery policy). Can be done.
  • an acquisition procedure eg, MEC Application Look-up
  • MEC Application Look-up may be started between the MSA 520 and the MSE 530 to acquire an app list according to the MEC discovery policy setting.
  • the MSE 530 may activate the MEC Application Look-up, and the specific condition (eg, electronic) of the electronic device 101 may be activated.
  • the device 101 may perform (or start) when the access base station Cell ID is changed while moving.
  • the MSE 530 may request and receive an app list (eg, MEC AppList) related to a serviceable MEC application (eg, MEP App) to the MMP server 430 according to the MEC discovery policy.
  • the MSE 530 may request the MMP server 430 by writing a MEC discovery policy to the MEC AppList request message Parameter as illustrated in Table 1, and the MMP server 430 may be configured accordingly.
  • a service available app list (eg, MEC AppList in Table 2) may be provided to the MSE 530 to respond to a request of the MSE 530.
  • An app list acquisition procedure (eg, MEC Application Look-up) according to various embodiments will be described in detail with reference to the accompanying drawings.
  • the client application 510 may forward a message (eg, a DNS query message) for a DNS query to the MSE 530.
  • a message eg, a DNS query message
  • the MSE 530 may perform an Application Context Create operation with the MMP server 430 in response to a DNS query from the client application 510.
  • the MSE 530 when a DNS query (with FQDN) message is generated in the client application 510, and detects the FQDN for the MEC through FQDN filtering, the corresponding MEC application (eg, MEC App) Application Context Create can be executed.
  • the MSE 530 may request and receive a URI for the MEC application name (eg, MEC App Name) to be accessed from the MMP server 430.
  • the MSE 530 may request and receive information about a dedicated DNN from the MMP server 430 as needed.
  • the MMP server 430 may transmit a MEC application package URI to the MSE 530.
  • the MSE 530 may perform a host selection procedure (eg, MEC Host Selection) for selecting the DNS server 2320 and the MEC host in response to a DNS query from the client application 510.
  • a host selection procedure eg, MEC Host Selection
  • the MSE 530 may be one of the DNS servers 2320 and one MEC.
  • a host selection procedure eg, MEC Host Selection
  • MEC Host Selection can be performed to select a host.
  • the host selection procedure for selecting one MEC host may include preset information and / or information received by requesting from the DNS server 2320 (eg, IP address, IP location). Information) or request information from the DNS server 2320 and / or the user to select (or set) a particular MEC host through a user interface (e.g., a select button). have.
  • preset information for configuring a specific MEC host may include priority information.
  • the priority information for example, when the host priority includes information that is prioritized for each URI, or when there are a plurality of IP addresses resulting from DNS resolving of one URI.
  • the priority of each IP address may include information determined.
  • the host selection procedure may include a DNS resolving operation and a MEC Host Prioritization operation.
  • DNS resolving may include, for example, performing DNS resolving on the FQDN for the MEC itself by the MSE 530 regardless of the DNS query of the client application 510.
  • MEC Host Prioritization may include, for example, setting an IP priority when a plurality of IP addresses are received in a DNS query response.
  • the priority may be predetermined for each URI or for each IP, and if a plurality of IP addresses are received, the IP priority is dynamically determined according to the result of the performance test for each received IP. You can also determine the ranking.
  • a host selection procedure eg, MEC Host Selection
  • the MSE 530 may provide the client application 510 with information obtained through the above procedures in a DNS response. According to an embodiment, the MSE 530 may forward a DNS response corresponding to the DNS query to the client application 510 that provided the DNS query after the MEC host selection (eg, DNS resolving).
  • MEC host selection eg, DNS resolving
  • 26 is a flowchart illustrating an operating method for a discovery procedure in an electronic device 101 according to various embodiments of the present disclosure.
  • the operations illustrated in FIG. 26 may be, for example, the electronic device 101 or a component included in the electronic device 101 (eg, the processor 120 of FIG. 1 or the MEC service of FIG. 4). Module 410).
  • the electronic device 101 looks at an application lookup for obtaining information (eg, an app list) about MEC applications that can be provided by the MEC system 405 based on a discovery policy. -up) operation can be performed.
  • the electronic device 101 may request an app list from the MMP server 430 and obtain (or receive) an app list from the MMP server 430.
  • the MSE 530 of the electronic device 101 receives the MEC discovery policy from the MSA 520 through the MSE API, and communicates with the MMP server 430 to serve the MEC application based on the MEC discovery policy. App list of can be obtained.
  • the electronic device 101 may detect a specified condition related to generating a context.
  • the specified condition may indicate a trigger for creating a context.
  • the trigger for creating a context may be, for example, the client application 510 is executed, the context creation is requested by the client application 510, or the client application 510 generates a DNS query It may include doing.
  • the electronic device 101 may perform an application context creation operation for identifying an MEC host (eg, an edge server or an MEC server) based on a specified condition.
  • the electronic device 101 may obtain, from the MMP server 430, information related to the MEC application associated with the client application 510 and to be accessed based on the app list.
  • the information related to the MEC application may include, for example, at least one of a URI for the MEC App Name, dedicated DNN information, or a MEC Application Package URI (eg, no MEC Application). It may include one.
  • Tables 3 and 4 below show a context create request message (eg, ⁇ Table 3>) and a context create response message exchanged in a context creation operation. message) (for example, ⁇ Table 4>).
  • ETSI MEC Compatible contextId String 0 ... 1 Uniquely identifies the application context in the MEC system. Assigned by the MEC system and shall be present other than in a create request. The length of the value shall not exceed 32 characters.
  • Y associateUeAppId String One Uniquely identifies the device application. The length of the value shall not exceed 32 characters.
  • Y appInfo Structure (inlined) One - Y > appDId String 0 ...
  • Y appDescription String 0 ... 1 Human readable description of the MEC application (see note 2).
  • Y queriedURI URI 0 ... 1 It may be FQDN included in the DNS query of a client Application.
  • N appPackage-Source URI 0 ... 1 URI of the application package.Included in the request if the application is not one in the ApplicationList.
  • appPackageSource enables on-boarding of the application package into the MEC system.
  • the application package shall comply with the definitions in clause 6.2.1.2 of ETSI GS MEC 010-2 [1] .This should be the MEC application package source.
  • Y deviceLocation String 0 ...
  • the context creation request message may include, for example, contextId, associatedUeAppId, app information, callbackReferenceURI, appPackageSource, or deviceLocation. It may include at least one.
  • contextId may indicate an ID for identifying an MEC application.
  • associatedUeAppId may indicate an ID for identifying the electronic device 101 (eg, a user terminal).
  • app information may include, for example, appName, appVersion (eg, appSoftVersion, appDVersion), appProvider, and appDescription.
  • “callbackReferenceURI” may indicate a callback address of the electronic device 101 for receiving a notification from the MMP server 430.
  • “appPackageSource” may indicate a download address of a MEC app package for supporting the MEC system 405 to download and install the corresponding application when there is no related MEC application on the MEC system 405.
  • “deviceLocation” may indicate location information of the electronic device 101 (for example, to instantiate a MEC application in the MEC host 447 near a corresponding location).
  • “deviceLocation” is for providing the location of the electronic device 101 at the time of context creation, and in the MEC system 405, the MEC system 405 is provided to the proximity MEC host 447 based on the location of the electronic device 101. Context creation of MEC applications can be performed.
  • the context creation request message may include “queriedURI”.
  • the “queriedURI” may include a URI (FQDN) queried by a DNS from the client application 510.
  • a corresponding MEC app URI (referenceURI) is added to the context creation response message. May be included.
  • the referenceURI may include an FQDN or an IP address for connecting to the MEC application.
  • ETSI MEC Compatible contextId String 0 ... 1 Uniquely identifies the application context in the MEC system. Assigned by the MEC system and shall be present other than in a create request. The length of the value shall not exceed 32 characters.
  • Y associateUeAppId String One Uniquely identifies the device application. The length of the value shall not exceed 32 characters.
  • Y appInfo Structure (inlined) One - Y > appDId String 0 ...
  • Y appDescription String 0 ... 1 Human readable description of the MEC application (see note 2).
  • Y referenceURI URI 0 ... 1 Address of the user application.It shall only be included in the response.
  • clientAppName String 0 ... N Client app name that is allowed to connect to the MEC application. If the MEC application is open to all the client application, this field can be omitted.
  • N uriTTL uint32 0 ... 1 Time-to-live of the reference URI N > uriLOC String 0 ... 1 Location (range) where the reference URI is available
  • N carpRule Structure 0 ... 1 Client App Routing Policy Rules
  • N DNN String 0 ...
  • the context generation response message may include, for example, App information, clientAppName, refereceURI, uriTTL, uriLOC, or CARP rule. It may include at least one of.
  • “app information” may include, for example, appName, appProvider, appVersion (eg, appSoftVersion, appDVersion), and appDescription.
  • “app information” and “clientAppName” may indicate a list of client apps allowed to access the MEC application.
  • “refereceURI” may indicate a MEC application access address.
  • uriTTL may indicate the MEC application connection address availability time.
  • “uriLOC” may indicate MEC application accessible area information.
  • the “CARP rule” may indicate path information such as a DNN for accessing a corresponding application.
  • the electronic device 101 may perform an MEC host selection operation for selecting an MEC host.
  • the electronic device 101 may select an optimal MEC host through the DNS server 2320 and the MEC host selection operation based on the obtained information related to the MEC application.
  • the optimal MEC host is based on at least one of the MEC host location and the user's current location, user movement (or movement) speed, or MEC host performance (eg, round trip time, throughput). Can be selected.
  • the electronic device 101 is located closest to the electronic device 101, has an optimal performance through a prior performance measurement (or test) (for example, ping probing or bandwidth estimation), or a client application (
  • the MEC host may be selected to include an optimal MEC application that is matched (or requested) with 510.
  • the electronic device 101 may perform data transmission with the selected MEC host. For example, the electronic device 101 may perform data transmission on the client application 510 and the MEC application and the application layer installed in the selected MEC host.
  • FIG. 27 is a diagram illustrating an example of an operation of obtaining an app list in a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 27 illustrates an example of an operation related to generating and obtaining an app list (eg, MEC Application Look-up) in a MEC discovery procedure according to an embodiment.
  • an app list eg, MEC Application Look-up
  • the MSA 520 of the electronic device 101 may transfer a MEC discovery policy to the MSE 530.
  • the MEC service module 410 may acquire the MEC discovery policy using the MSA 520 and perform a discovery procedure based on the received MEC discovery policy using the MSE 530.
  • the MEC discovery policy may include a client application name (eg clientAppNames), location (locationInfo), device type (eg deviceType), service type (eg serviceType), context type (eg contextType), URI request. It may be provided including at least one of a flag (eg URI Request) or a dynamic DNN (eg dynamicDnn).
  • the discovery policy may include at least one of the information as described in the description with reference to ⁇ Table 1>.
  • the MSE 530 performs an acquisition procedure (eg, MEC Application Look-up) to obtain an app list (eg, AppList) based on information received from the MSA 520 (eg, MEC discovery policy). Can be done.
  • the obtaining of the app list may be initiated according to the MEC discovery policy setting between the MSA 520 and the MSE 530.
  • the app list acquisition procedure may be activated when the MEA discovery policy API is called by the MSA 520, and the MMP server 430 requests and receives a MEC app list and / or URI corresponding to the MEC discovery policy. can do.
  • the app list obtaining procedure may include operation 2710, operation 2720, and operation 2730.
  • the MSE 530 may transmit a request message (eg, HTTP Get AppList Request Parameters) requesting an app list to the MMP server 430.
  • the MSE 530 may include (or write) a MEC discovery policy in a request message (eg, HTTP Get AppList Request Parameters) and provide the MEC discovery policy to the MMP server 430.
  • the MSE 530 may include the app list request parameter as illustrated in Table 1 and provide it to the MMP server 430.
  • the request message may include at least one of information (or parameters) as described in the description with reference to ⁇ Table 1>.
  • field information that can be supported in the request parameter may be defined in MMP Info in the Authorization Response in the authentication (AA) step.
  • a parameter (or information) related to an app list request (eg, AppList Request Parameters) may be included in a parameter field of a request message (eg, HTTP GET).
  • the app list request parameter may include an application name (eg, clientAppNames), an access cell ID, and a tracking area (TA) received from the MSA 520 (eg, setMecDiscoveryPolicy (clientAppNames, discoveryPolicy) in operation 2701).
  • Area Location information related to the location of the electronic device 101 including at least one of an ID, area information (eg, city, ward, town, building), or preferred location information specified by a user.
  • Device Type eg, Smartphone, Tablet, Wearable, IoT, Car, Drone
  • Service Type Identify Service Type
  • Context Type can identify whether context information is needed (e.g. user or application context information Whether required), or MEC
  • the URI of the application can be activated (available) flag (Flag) requesting to include the URI in the response: can include at least one (e.g., URI Request Flag).
  • the context type is information for identifying a service application type of the electronic device 101.
  • the context type may include an application (eg, a specific launcher or a designated application) installed in the electronic device 101, and an execution application. It may include at least one of a name, a domain.
  • the electronic device 101 may transmit application information (eg, a specific launcher or a designated application) installed in the electronic device 101 to the MMP server 430 in a procedure for requesting an app list.
  • application information eg, a specific launcher or a designated application
  • the electronic device 101 may request an app list from the MMP server 430. You can also pass the installed application information.
  • the MMP server 430 may transmit a response message (eg, HTTP 200 OK AppList response Data) including an app list (eg, MEC AppList) in response to the request message received from the MSE 530. 530).
  • a response message eg, HTTP 200 OK AppList response Data
  • an app list eg, MEC AppList
  • the MMP server 430 may search for the MEC application based on the received client application name, and provide the MSE 530 with an app list including the found MEC application in the response message.
  • data (or information) related to an app list response may be included in a message body of a response message (eg, HTTP 200 OK).
  • the response message may include at least one of the information as described in the description with reference to ⁇ Table 2>.
  • the MMP server 430 may provide a serviceable MEC App List based on at least one of all available MEC App Lists or Request Parameters.
  • the client application may include an accessible MEC App Name for each Client App, and the MEC App Name may be used (or required) in an Application Context Create operation.
  • the MMP server 430 may provide a notification in the app list when the operator's Location API is available.
  • the MMP server 430 in the request message, if the URI Request Flag is true, and the MEC App is running on an available MEC host near the electronic device 101 (eg, the user terminal), the corresponding MEC App URI can be included in app list.
  • the MMP server 430 includes the URI of the MEC App in the app list when the MEC App is running in the MEC host even when there is no URI Request Flag in the request message. It can also be provided.
  • the MMP server 430 when the MMP server 430 receives the app list request from the electronic device 101, in the request message, if the MEC App can be directly driven according to the context type, the MMP server 430 runs the MEC App and then displays the URI. Can be included in the list.
  • the MMP server 430 may further provide the valid time / valid place information of the URI in the app list.
  • the information about the valid time of the URI may be determined by the electronic device 101 or may be variably determined according to the MEC App driving state in the MMP server 430.
  • the MMP server 430 may provide a corresponding rule when there is a dedicated DNN rule for each application.
  • the URI included in the app list may be distinguished by being hyperlinked and / or highlighted, and the electronic device 101 may display a hyperlink and / or a highlight in the app list. Based on this, it can be displayed separately. According to another embodiment, the electronic device 101 may display the same in the app list without distinguishing between the MEC App including the URI and the MEC App without the URI. According to an embodiment of the present disclosure, the electronic device 101 may provide a service location and / or time information for each application in the app list.
  • the MMP server 430 may include DNN information for each application (or per app) in the app list when the DNN may be set on an application basis.
  • the DNN server may be a DNN included in the DNN list received at the authentication (AA) stop.
  • the electronic device 101 transmits an MEC host (eg, an app list) and a corresponding application (s) of the app list. It may acquire (or receive) information (eg, URI) about an edge server or an MEC server.
  • information eg, URI
  • the electronic device 101 when the electronic device 101 does not receive information (eg, a URI) about the MEC host, for example, the electronic device 101 further performs an Application Context Create procedure for the corresponding app, thereby for the corresponding application.
  • Information (eg URI) of the MEC host can be obtained from an external server.
  • the electronic device 101 when the electronic device 101 receives information (eg, a URI) about the MEC host, for example, the electronic device 101 does not perform an application context creation procedure for the corresponding application, but instead directly performs the corresponding MEC host ( (Eg using a URI).
  • information eg, a URI
  • the electronic device 101 in the procedure of requesting an app list from the MMP server 430 and receiving a response thereto, the electronic device 101 is assigned to the designated networking path for the app list and corresponding application (s) of the app list.
  • Information about a DNN when the electronic device 101 receives information (eg, a DNN) about a designated networking path, the electronic device 101 may perform a procedure for setting a network and a designated networking path.
  • the electronic device 101 may set a DNN path so that only the applications that receive the DNN information communicate with a dedicated (or dedicated) DNN.
  • the electronic device 101 may set a designated DNN path for applications receiving the DNN information in a procedure (eg, Application Context Create) for requesting creation of a context from the MEC host.
  • a procedure eg, Application Context Create
  • the MSE 230 may perform a policy update.
  • the MSE 530 may additionally (or optionally) include a policy update operation in an operation of obtaining an app list (operation 2703).
  • the MSE 530 receives a URSP rule (e.g., a DNN) when a dedicated PDU session is required (or when a new dedicated DNN rule is set), and is application-specific or URI according to the URSP rule. You can set up and use a separate PDU session.
  • a URSP rule e.g., a DNN
  • a URSP rule may be the result of an authentication procedure (e.g., received by the MSA 520 and passed to the MSE 530), or the MSE 530 is an application lookup (e.g., an App lookup) result, Alternatively, it may be received as a result of context creation, and when a new DNN rule is set in the URSP rule, PDU session setup may be performed.
  • the PDU session establishment eg, the creation of the PDU session of FIG. 17 and the release of the PDU session of FIG. 18
  • the modem 1700 may generate / release the SMF of the 5G network (or the core network) by requesting the SMF.
  • FIG. 28 is a diagram illustrating an example in which an app list is provided according to various embodiments.
  • FIG. 28 may illustrate a of a location-based service area.
  • the MMP server 430 may be a first server (Server 1) 2810 (or a first MEC host adjacent to a user) (eg, the MEC host 447 of FIG. 4). It may be assumed that first information (for example, A (+ URI), B, and C) about available applications is obtained from the A-S. According to one embodiment, the MMP server 430 may be configured to provide for possible applications from a second server (Server 2) 2820 (or a second MEC host adjacent to a user) (eg, MEC host 447 of FIG. 4). It may be assumed that 2 information (eg, A (+ URI), C (+ URI), D) is obtained.
  • a second server Server 2 information
  • the MMP server 430 collects information (eg, first information and second information) about each application obtained from the first server 2810 and the second server 2820. For example, information about A (+ URI), B, C (+ URI), and D may be generated (or obtained). According to an embodiment, the MMP server 430 generates an app list including A (+ URI), B, C (+ URI), and D generated from the first server 2810 and the second server 2820. The generated app list may be provided to the user 2830 (eg, the electronic device 101).
  • information eg, first information and second information
  • information about A (+ URI), B, C (+ URI), and D may be generated (or obtained).
  • the MMP server 430 generates an app list including A (+ URI), B, C (+ URI), and D generated from the first server 2810 and the second server 2820.
  • the generated app list may be provided to the user 2830 (eg, the electronic device 101).
  • 29 is a diagram illustrating a life cycle 2900 of an application according to various embodiments.
  • an application installed in the electronic device 101 may change a state by a user input or a command of a processor (for example, the processor 120 of FIG. 1).
  • a life cycle 2900 of an application may include, for example, a state in which an application is launched (launch) 2905, a running state 2910, It may mean a series of cycles that are changed to a paused state 2915, a shut down state 2920, or a killed state 2925.
  • the application installed in the electronic device 101 may be in a start state according to a user input or a preset condition.
  • the application may be in an execution state (or foreground state) in which a screen related to the application is displayed to the user, or the application may be executed by the processor 120 (eg, an application processor (AP)) of the electronic device 101 (
  • the screen associated with the application may be in a paused state (or a background state) that is being executed but not visible to the user.
  • the application may be shut down by user input or may be killed due to insufficient memory.
  • the MEC system 405 since the MEC system 405 performs data transmission based on the MEC according to the state of the application, if the life cycle is not synchronized, the MEC system 405 may waste resources.
  • the MSE 230 may notify the MMP server 430 whether the applications 310-1, 310-2,...
  • MEC applications e.g. 460-1, 460-2, ...) only operate when applications (e.g. 310-1, 310-2, ...) are in use.
  • the MSE 530 informs the MMP server 430 whether to use the applications 310-1, 310-2,..., As described above, so that the MEC host 447 (or the edge server ( 305) can be efficiently managed.
  • the resource allocation of the MEC application may be released to the unused application to reduce the resource consumption of the MEC host 447.
  • an MEC service module 410 eg, MSE 530
  • an application eg, a client application (eg, 310-1, 310-2, ...) and an MEC host of the electronic device 101 may be used.
  • Monitor the life cycle of the MEC application e.g. 460-1, 460-2, ...) of 447 in real time, and monitor the monitored life cycle of the MEC system 505 (e.g. MMP server 430 (or LCM proxy). Server)) to reduce unnecessary resource consumption.
  • the MEC application included in the MEC system 405 may be a camera module (eg, FIG. Since the image data acquired by the camera module 180 of FIG. 1 is analyzed and the analysis result is transmitted only at the request of the electronic device 101, life cycle synchronization between the electronic device 101 and the MEC application may not be required.
  • the MEC application analyzes an image acquired by the camera module 180 in real time and provides a service related to the analyzed image to the electronic device 101. Life cycle synchronization between the electronic device 101 and the MEC application may be required.
  • the MEC service module 410 eg, the MSE 530
  • the MEC service module 410 may request at least one of context create, context delete, suspend, or resume of the MEC application.
  • FIG. 30 is a diagram illustrating an example of a context creation procedure in a discovery procedure according to various embodiments.
  • FIG. 30 may show an example of an operation related to application context creation (eg, application context creation) in a MEC discovery procedure according to an embodiment.
  • the application context creation procedure for example, when the client application 510 is executed, the MSA 520 with the application start information along with information (eg, package name or UID) related to the client application. May be performed from passing the MSE to the MSE 530 via the MSE API.
  • the application context creation may include launching an application on an app list (first case), requesting a context creation (eg, calling a context create API) through an MSE API, or (Second case) or when the application matches the application name and / or URI (eg, FQDN) included in the previously received app list when the DNS query is transmitted (third case).
  • the application context generation may include, for example, location information delivered through a MEC discovery policy (eg, setDiscoveryPolicy (discoveryPolicy)) or available location per application included in an app list delivered through an application lookup response.
  • the uriLOC may be performed when the location of the current user (or the electronic device 101) matches (eg, the fourth case).
  • the application context generation may be performed when at least one of the conditions according to the first case, the second case, the third case, or the fourth case is satisfied.
  • 30 illustrates an example of an operation of generating an application context according to the first case.
  • operation 3001 when a specific client application 510 is launched, the client application 510 provides the MSA 520 with information (eg, App Launched) indicating the execution of the application. can do.
  • information eg, App Launched
  • operation 3001 may not be performed.
  • the MSA 520 eg, the framework level
  • the MSA 520 may detect execution of the client application 510 by itself without an operation of notifying execution by the client application 510. Can be.
  • a notification message (eg, notifying) of a state of the client application 510 is received.
  • notifyClientAppState may be provided to the MSE 530.
  • a notification message (eg, notifyClientAppState) includes, for example, the state of the client application (eg START) and the name of the client application (eg clientAppName) (and / or UID) (eg, notifyClientAppState). (START, clientAppName)).
  • the MSE 530 may receive a notification message (eg, notifyClientAppState) from the MSA 520 and perform an application context creation procedure based on the information of the received notification message.
  • a notification message eg, notifyClientAppState
  • the application context creation procedure may include operation 3010, operation 3020, and operation 3030.
  • the MSE 530 may transmit a request message (eg, HTTP POST AppContext Data) requesting the creation of an application context to the MMP server 430.
  • a request message eg, HTTP POST AppContext Data
  • the MSE 530 may transmit a request message requesting the URI to the MMP server 430.
  • the MSE 530 may include a MEC App Name in a request message and transmit the same to the MMP server 430.
  • the MSE 530 when there is no MEC application in the MMP server 430, the MSE 530 includes only a URI for downloading the MEC application (for example, an application package download URI) in the request message. It may transmit to the MMP server 430.
  • a URI for downloading the MEC application (for example, an application package download URI) in the request message. It may transmit to the MMP server 430.
  • the MMP server 430 provides a response message (eg, HTTP OK 200 Response AppContext Data) including the URI of the MEC application to the MSE 530 in response to a request message received from the MSE 530.
  • the response message may include a URI (FQDN) of the corresponding application (eg, MEC application).
  • the response message may include a URI of the MEC application and information regarding a valid time and / or a valid location of the URI.
  • the MSE 530 may perform application context re-execution or handover triggering when the valid timeout or the valid location is changed.
  • the response message may include DNN information.
  • the MSE 530 may perform a policy update.
  • the MSE 530 may additionally (or optionally) include a policy update operation in the application context creation procedure (operation 3005).
  • the MSE 530 receives a URSP rule (e.g., a DNN) when a dedicated PDU session is required (or when a new dedicated DNN rule is set), and is application-specific or URI according to the URSP rule. You can set up a separate PDU session.
  • a URSP rule e.g., a DNN
  • a URSP rule may be the result of an authentication procedure (e.g., received by the MSA 520 and passed to the MSE 530), or the MSE 530 is an application lookup (e.g., an App lookup) result, Alternatively, it may be received as a result of context creation, and when a new DNN rule is set in the URSP rule, PDU session setup may be performed.
  • the PDU session establishment eg, the creation of the PDU session of FIG. 17 and the release of the PDU session of FIG. 18
  • the modem 1700 may generate / release the SMF of the 5G network (or the core network) by requesting the SMF.
  • the application context creation procedure may be performed by, for example, an MEC application to which the client application 510 is already running, and an app list acquisition procedure (eg, MEC Application Look-up). If a URI is received from, it can be omitted.
  • an MEC application to which the client application 510 is already running
  • an app list acquisition procedure eg, MEC Application Look-up
  • 31 is a diagram illustrating an example of a context creation operation in a discovery procedure according to various embodiments.
  • FIG. 31 illustrates an example of an operation related to application context creation (eg, application context creation) in a MEC discovery procedure according to an embodiment.
  • the application context creation operation may be performed, for example, by the client application 510 forwarding the context creation request to the MSE 530 via the MSE API.
  • the application context creation may include launching an application on an app list (first case), requesting a context creation (eg, calling a context create API) through an MSE API, or (Second case) or when the application matches the application name and / or URI (eg, FQDN) included in the previously received app list when the DNS query is transmitted (third case).
  • the application context generation may include, for example, location information delivered through a MEC discovery policy (eg, setDiscoveryPolicy (discoveryPolicy)) or available location per application included in an app list delivered through an application lookup response.
  • a MEC discovery policy eg, setDiscoveryPolicy (discoveryPolicy)
  • available location per application included in an app list delivered through an application lookup response e.g, the uriLOC
  • the uriLOC may be performed when the location of the current user (or the electronic device 101) matches (eg, the fourth case).
  • the application context generation may be performed when at least one of the conditions according to the first case, the second case, the third case, or the fourth case is satisfied. 31 illustrates an example of an operation of generating an application context according to the second case.
  • the client application 510 may transmit a message (eg, contextCreate) for creating a context to the MSE 530.
  • a message eg, contextCreate
  • the client application 510 sends a context creation request to the MSE 530 through the MSE API together with information related to the client application (for example, an application name (appName) or UID). I can deliver it.
  • the MSE 530 may receive a message for creating a context from the client application 510 and perform an application context creation operation based on information (eg, an application name) of the received message.
  • the operation of generating an application context may include operation 3110, operation 3120, and operation 3130.
  • the operation of generating an application context may correspond to those described in the descriptions of operations 3010, 3020, and 3030 according to the operation of creating an application context of operation 3005 in FIG. 30.
  • 32 is a diagram illustrating an example of a context creation operation in a discovery procedure according to various embodiments.
  • FIG. 32 may illustrate an operation example related to application context creation (eg, application context creation) in a MEC discovery procedure according to an embodiment.
  • the application context creation operation may be performed, for example, by the client application 510 forwarding a DNS query to the MSE 530.
  • the application context creation may include launching an application on an app list (first case), requesting a context creation (eg, calling a context create API) through an MSE API, or (Second case) or when the application matches the application name and / or URI (FQDN) included in the previously received app list when the DNS query is transmitted (third case).
  • the application context generation may include, for example, location information delivered through a MEC discovery policy (eg, setDiscoveryPolicy (discoveryPolicy)) or available location per application included in an app list delivered through an application lookup response.
  • a MEC discovery policy eg, setDiscoveryPolicy (discoveryPolicy)
  • available location per application included in an app list delivered through an application lookup response e.g, the uriLOC
  • the uriLOC may be performed when the location of the current user (or the electronic device 101) matches (eg, the fourth case).
  • the application context generation may be performed when at least one of the conditions according to the first case, the second case, the third case, or the fourth case is satisfied. 32 illustrates an example of an operation of generating an application context according to the third case.
  • the client application 510 may transmit a message (eg, DNS query) for a DNS query to the MSE 530.
  • a message eg, DNS query
  • the MSE 530 may receive a DNS query from the client application 510, and perform an application context generation operation when the DNS query matches an application or URI included in the previously received app list.
  • the operation of generating an application context may include operation 3210, operation 3220, and operation 3230.
  • the operation of generating an application context may correspond to those described in the descriptions of operations 3010, 3020, and 3030 according to the operation of creating an application context of operation 3005 in FIG. 30.
  • the application context creation operation may be delivered through, for example, location information or an application lookup response delivered through a MEC discovery policy (eg, setDiscoveryPolicy (discoveryPolicy)). This may also be performed when an available location (eg, uriLOC) for each application included in the app list matches the location of the current user (or the electronic device 101).
  • a MEC discovery policy eg, setDiscoveryPolicy (discoveryPolicy)
  • FIG 33 is a diagram illustrating an example of a MEC host selection procedure in a discovery procedure according to various embodiments.
  • FIG. 33 may illustrate a MEC host selection operation 3301 for the MSE 530 to select a DNS server 2320 and an MEC host.
  • the MEC host selection operation (operation 3301) may include a DNS (pre) resolving operation (eg operation 3310), a MEC Host Prioritization operation (eg operation 3320), and a DNS caching operation (eg operation). 3330).
  • the MSE 530 may perform DNS resolving or pre-resolving.
  • DNS resolving may, for example, resolve DNS to the FQDN for the MEC itself by the MSE 530 itself, regardless of the DNS query of the client application 510.
  • DNS resolving (operation 3310) may include operation 3311 and operation 3313.
  • the MSE 530 may perform a DNS resolving operation by the DHL 535. According to an embodiment, the MSE 530 may send a DNS query to the DNS server 2320 as a URI (FQDN) for the MEC application.
  • a DNS DNS resolving operation by the DHL 535.
  • the MSE 530 may send a DNS query to the DNS server 2320 as a URI (FQDN) for the MEC application.
  • the DNS server 2320 may receive a DNS query from the MSE 530 and transmit a DNS response to the MSE 530 in response to the DNS query.
  • the DNS response may include at least one address information (eg, URI or IP address) related to the MEC host.
  • the MSE 530 may perform a MEC Host Prioritization operation.
  • the MEC Host Prioritization may include, for example, setting an IP priority when a plurality of IP addresses are received in a DNS query response.
  • the MSE 530 may set a priority for the MEC host.
  • the MSE 530 may obtain (or receive) a candidate IP list for a plurality of MEC hosts from the MMP server 430, and additional information (eg, receive) of the candidate IP list may be obtained.
  • MEC host location user MEC host candidate IP and remote server e.g., as shown in FIG. 3 from the user's current location, user speed, or MEC host performance (e.g., at least one of RTT (round trip time, throughput))
  • the remote server 306 may select an access IP selection or priority among IP addresses.
  • one of the MEC host IP or the IP of the remote server may be selected.
  • the remote server IP may be selected without selecting the MEC host IP.
  • the MSE 530 eg, MEL 531 selects an optimal MEC host through prior performance measurements (or tests) (eg, ping probing or bandwidth estimation) for a plurality of candidate MEC hosts. Can be.
  • the DNS server 2320 may record location information of the MEC host together with the IP address of the MEC host in a DNS response message.
  • the MSE 530 when the MSE 530 includes the location information of the MEC host for the location record type (eg, LOC record type) among DNS types in the DNS response message received after the DNS query during DNS resolution, the neighboring MEC host may be selected using the location information.
  • the MSE 530 may perform location information (eg, latitude, longitude, serving cell ID, city information, or ID) of the MEC host from the DNS server 2320 in a DNS query operation of obtaining an IP address of the MEC host. ) Can be obtained.
  • location information of the MEC host may be included in the DNS type field.
  • the MSE 530 may perform DNS caching with the DNS cache 2310.
  • the MSE 530 may include address information (eg, a URI associated with a MEC host) included in the DNS response.
  • IP address corresponding to the FQDN may be stored in the Local DNS Cache (eg, DNS Cache 2) for the MEC.
  • the MSE 530 may deliver the address information stored in the local DNS cache for the MEC.
  • An operation of including a local DNS cache (eg, DNS Cache 2) for the MEC in the MSE 530 of 35 may be used.
  • An operation of operating the local DNS cache for the MEC according to an embodiment will be described in detail with reference to the accompanying drawings.
  • the electronic device 101 may perform a plurality of MECs on which the MEC application may operate in a communication procedure (eg, discovery / application context creation) with the MMP server 430 based on the MEC host selection operation.
  • Receive host information e.g. URI or IP address.
  • the electronic device 101 may select and communicate any one MEC host among the plurality of MEC hosts.
  • the electronic device 101 may select a plurality of MEC hosts capable of operating the MEC application according to priority.
  • the priority may be determined based on at least latency measurement information between the electronic device 101 and the MEC host or location information of the MEC host.
  • the DNS device maintains and / or maintains DNS caching data for MEC client apps, in addition to DNS caching data for general client apps.
  • the operation to manage is explained.
  • 34 is a diagram illustrating an example in which the electronic DNS 101 separately operates a local DNS cache for an MEC.
  • FIG. 34 illustrates an example in which a local DNS cache (eg, the second DNS cache 3430) for the MEC is separately configured from the MSE 530 of the electronic device 101.
  • the general client apps 3410 may perform DNS caching with the first DNS cache 3420, and the MEC Client Apps 510 may perform a second DNS cache. DNS caching may be performed at 3430.
  • a generic client application 3410 may use a first DNS cache 3420 and a MEC client application 510 may use a second DNS cache 3430.
  • the DNS resolving API may be used for a URI of a client application to be accessed, and the IP address may be received.
  • the MSE 530 e.g., DHL 535) (or the OS of the electronic device 101, or the DNS processing module on the framework) may request a DNS query (e.g., FQDN) of the client application's corresponding request.
  • a DNS query e.g., FQDN
  • the MSE 530 may determine which DNS cache to use for each URI (FQDN) per client application, and accordingly, separate DNS processing module (eg, FIG.
  • the DNS processing module or DHL first consults the DNS cache for the requested URI (FQDN), forwards the IP corresponding to the URI if it exists, and queries the DNS server 2320 if it is not in the cache. Can be performed.
  • FQDN requested URI
  • the general client application 3410 and the MEC client application 510 are distinguished and described in detail with reference to the following drawings (eg, FIG. 36) with respect to performing DNS caching.
  • FIG. 35 is a diagram illustrating an example of operating a local DNS cache for an MEC in an MSE 530 in an electronic device 101 according to various embodiments.
  • FIG. 35 illustrates an example of configuring a local DNS cache (eg, a second DNS cache 3430) for the MEC in the MSE 530 of the electronic device 101.
  • the generic client application 3410 may perform DNS caching with the first DNS cache 3420, and the MEC client application 510 may perform DNS caching with the second DNS cache 3430.
  • the general client application 3410 may use the first DNS cache 3420, and the MEC client application 510 may use the second DNS cache 3430.
  • the DNS resolving API may be used for a URI of a client application to be accessed, and the IP address may be received.
  • the MSE 530 e.g., DHL 535) (or the OS of the electronic device 101, or the DNS processing module on the framework) may request a DNS query (e.g., FQDN) of the client application's corresponding request.
  • a DNS query e.g., FQDN
  • the MSE 530 may determine which DNS cache to use for each URI (FQDN) per client application, and accordingly, separate DNS processing module (eg, FIG.
  • the DNS processing module or DHL first consults the DNS cache for the requested URI (FQDN), forwards the IP corresponding to the URI if it exists, and queries the DNS server 2320 if it is not in the cache. Can be performed.
  • FQDN requested URI
  • the general client application 3410 and the MEC client application 510 are distinguished and described in detail with reference to the following drawings (eg, FIG. 36) with respect to performing DNS caching.
  • 36 is a diagram illustrating an operation of using an IP address for a domain name according to various embodiments.
  • the first state 3601 is disabled by the MEC service module 410 (eg, the MSE 530).
  • the second state 3602 may indicate a state in which the MEC service module 410 is enabled.
  • the electronic device 101 may include a first DNS cache 3610 and a second DNS cache 3620 configured to store a domain name and an IP address for the domain name. Can be.
  • the first DNS cache 3610 may store at least one of an application name, a domain name, or an IP address for the domain name of a general application
  • the second DNS cache 3620 may store the MEC application 460.
  • the MEC service module 410 may obtain a domain name for the application from a proxy server (for example, the MMP server 430 (or LCM proxy server) of FIG. 4 or a separate proxy server).
  • the domain name may include, for example, at least one of a fully qualified domain name (FQDN) or a URI.
  • the MEC service module 410 may obtain a domain name in a discovery procedure.
  • the MEC service module 410 may obtain an IP address for the domain name based on the domain name.
  • the MEC service module 410 may store the IP address in the second DNS cache 3620 if the obtained IP address is an IP address for a domain name that can access an MEC application supporting the MEC service.
  • the MEC service module 410 when an application (eg, client application 510) attempts to access a domain name (eg, http: www.xxx.com), the MEC service module 410 is deactivated (eg, 1 state (3601), the application 510 is remote (or centralized) connected via the Internet 3630 using the IP address of the domain name (e.g., 111.222.333) stored in the first DNS cache 3610. )) To the server 3640.
  • the MEC service module 410 when the MEC service module 410 is in an inactive state, the MEC service module 410 converts a domain name into an IP address by referring to an IP address (eg, 111.222.333) stored in the first DNS cache 3610. can do.
  • the MEC service module 410 may request an IP address from a separate server (eg, a DNS server).
  • the MEC service module 410 when the MEC service module 410 is in an activated state (eg, the second state 3602), the MEC service module 410 stores a domain name that the application 510 attempts to access in the second DNS cache 3620. ) And convert the IP address corresponding to the domain name (e.g., 10.22.33), and induce the application 510 to access the MEC application 460 included in the MEC system 405 through the converted IP address. can do. If the IP address corresponding to the domain name to be accessed by the application 510 is not in the second DNS cache 3620, the MEC service module 410 may request an IP address from a separate server (eg, a DNS server).
  • a separate server eg, a DNS server
  • FIG. 37 illustrates a signal flow 3700 for sharing an IP address in accordance with various embodiments.
  • the DNS server 2320 may be a separate entity from the MEC system 405 or may be included in the MEC system 405.
  • the MEC service module 410 (eg, MSE 530) is configured to execute an application (eg, client application 510) in the MEC system 405 (eg, the MMP server 430 (or LCM proxy server) of FIG. 4).
  • Domain name may include, for example, an FQDN.
  • MEC service module 410 may perform a DNS along with a domain name for application 510. The address of the server 2320 may be requested.
  • the MEC system 405 may transmit information including the domain name to the MEC service module 410. According to an embodiment, the MEC system 405 may transmit the address of the DNS server 2320 to the MEC service module 410 along with the domain name.
  • operations 3705 and 3710 may be included in the MEC discovery procedure.
  • the MEC service module 410 may request a domain name along with information about applications that the MEC system 405 can provide.
  • the MEC service module 410 may request a domain name separately from information about applications that the MEC system 405 can provide in the MEC discovery procedure.
  • the MEC system 405 may transmit the domain name and the information about the applications that the MEC system 405 can provide together or separately.
  • the MEC service module 410 may perform operations 3705 and 3710 separately from the MEC discovery procedure. For example, the MEC service module 410 detects an event related to mobility of the electronic device 101 when the application 510 is installed in the electronic device 101. When it is detected that one condition is satisfied, or in accordance with a specified period, operations 3705 and 3710 may be performed.
  • the application 510 may request access to the domain name.
  • operation 3715 may be referred to as a DNS query.
  • the application 510 needs an IP address for the MEC application 460 in order to perform MEC-based data transmission with the MEC application (eg, the ME application 460 of FIG. 36). You can run a query.
  • the MEC service module 410 may operate from operation 3720 to operation based on information included in a DNS query and / or information stored in a second DNS cache (eg, the second DNS cache 3620 of FIG. 36). 3725 may or may not be performed.
  • the MEC service module 410 may have a name or domain of an application stored in the second DNS cache 3620 corresponding to at least one of the name or domain name (eg, FQDN or URI) of the application included in the DNS query. At least one of the names can be identified.
  • the MEC service module 410 sets the IP address to the application 510. Can be transferred to).
  • the MEC service module 410 may perform a DNS server 2320. ), You can request an IP address for your MEC application.
  • the message (or data packet) sent in operation 3720 may include, for example, a domain name received from the MEC system 405 in operation 3710.
  • the DNS server 2320 may send an IP address for the MEC application to the MEC service module 410.
  • the MEC service module 410 may deliver the received IP address to the application 510.
  • FIG. 37 illustrates an embodiment in which the MEC service module 410 requests an IP address in response to a DNS query operation.
  • the MEC service module 410 may perform an IP address separately from the DNS query. The address may be requested from the DNS server 2320.
  • the MEC service module 410 may request an IP address after operation 3710.
  • the MEC service module 410 may request an IP address through a context creation operation.
  • the application 510 may perform data transmission with the MEC application included in the MEC system 405 using the IP address received from the MEC service module 410.
  • the electronic device 101 may collectively manage IP addresses of a plurality of MEC applications corresponding to the plurality of applications through the MEC service module 410, the electronic device 101 may reduce resource consumption and may be stable. Can provide services.
  • 38 is a flowchart illustrating a method of using an IP address for a domain name in the electronic device 101 according to various embodiments.
  • the operations illustrated in FIG. 38 may include the electronic device 101 or a component included in the electronic device 101 (eg, the processor 120 of FIG. 1 or the MEC service module 410 of FIG. 4). It can be performed by).
  • the electronic device 101 may detect that an application (eg, the client application 510) requests to access a domain name ( Example: operation 3715 of FIG. 37).
  • the electronic device 101 may determine whether the domain name for which the application 510 requests access can support the MEC. For example, the electronic device 101 may check whether the domain name for which the application 510 requests access can support the MEC, based on the information received through the discovery procedure.
  • the electronic device 101 may access the domain name using the second DNS cache 3820. have.
  • the electronic device 101 may access the domain name using the first DNS cache 3610. Can be.
  • 39 is a flowchart illustrating a method of requesting an IP address from the electronic device 101 according to various embodiments.
  • the operations illustrated in FIG. 39 may include the electronic device 101 or a component included in the electronic device 101 (eg, the processor 120 of FIG. 1 or the MEC service module 410 of FIG. 4). It can be performed by). According to one embodiment, the operations shown in FIG. 39 may be, for example, one embodiment of operation 3865 of FIG. 38.
  • the MEC service module 410 may identify whether an IP address for the MEC application is stored in the second DNS cache 3620.
  • the MEC service module 410 may store the IP address stored in the second DNS cache 3620. It may be delivered to the application 510.
  • the MEC service module 410 may request an IP address from the DNS server 2320 in operation 3950. have.
  • the MEC service module 410 may receive an IP address from the DNS server 2320. According to an embodiment, before performing operation 3945, the MEC service module 410 may temporarily store the received IP address in the second DNS cache 3620. According to one embodiment, in operation 3955, if the MEC service module 410 includes information indicating the validity period along with the IP address, the MEC service module 410 stores the IP address in the second DNS cache during the validity period indicated by the information. (3620).
  • the MEC service module 410 may transfer the IP address stored in the second DNS cache 3620 to the application 510.
  • 40 is a flowchart illustrating a method of performing MEC-based data transmission using an IP address in the electronic device 101 according to various embodiments.
  • the operations illustrated in FIG. 38 may include the electronic device 101 or a component included in the electronic device 101 (eg, the processor 120 of FIG. 1 or the MEC service module 410 of FIG. 4). It can be performed by).
  • the electronic device 101 includes a first address associated with the MEC service module 410 (eg, the MSE 530) and includes at least a first data packet requesting a domain name.
  • Send to one external server eg, some component of MEC system 405 (or an edge server or MEC server)
  • the first address may include an IP address of the electronic device 101 and an IP port identifier associated with the MEC service module 410.
  • the domain name may be a domain name associated with an MEC application (eg, the MEC application 460 of FIG. 36) included in an external server.
  • the electronic device 101 may transmit a first data packet in response to the application 510 requesting access to the MEC application. For example, when the application 510 is installed in the electronic device 101 or when a user input for requesting execution of the application 510 is received, the application 510 may request access to the MEC application. According to another embodiment, the electronic device 101 may transmit a first data packet in the MEC discovery procedure. According to another embodiment of the present disclosure, the electronic device 101 may detect a mobility of the electronic device 101 or a condition (eg, the first condition of FIG. 20) that the application 510 may perform data transmission based on the MEC. If satisfied, the first data packet can be sent. According to another embodiment, the electronic device 101 may transmit the first data packet at a specified cycle.
  • a condition eg, the first condition of FIG. 20
  • the electronic device 101 may receive information including a domain name from at least one external server.
  • the domain name may be, for example, a domain name associated with MEC applications.
  • the electronic device 101 includes a first address and a domain name associated with the MEC applications, and transmits a second data packet requesting an IP address for the domain name to at least one external server (eg, a DNS server ( 2320).
  • a DNS server 2320
  • the electronic device 101 transmits a second data packet in the MEC discovery procedure, detects mobility of the electronic device 101, satisfies a first condition, or transmits the second data packet at a specified period. Can transmit
  • the electronic device 101 may receive information including an IP address for a domain name from at least one external server.
  • the electronic device 101 may transmit a third data packet including the user data and the second address based on the received IP address to at least one external server (eg, some components of the MEC system 405). Can be sent to.
  • the second address may include an IP address of the electronic device 101 and an IP port identifier associated with the application 510.
  • the IP port identifier associated with the application 510 may be different from the IP port identifier associated with the MEC service module 410.
  • the electronic device 101 may skip operations 4075 and 4080 and perform operation 4085. have.
  • FIG. 41 is a diagram illustrating an example of a DNS resolving operation in a discovery procedure according to various embodiments.
  • FIG. 41 is a diagram illustrating an example of a DNS resolving operation in a discovery procedure according to various embodiments.
  • FIG. 41 may represent a DNS resolving operation for a DNS query of the client application 510.
  • the DNS resolving operation may include an operation when the DNS server 2320 is in an inactive state (eg, operation 4110) and an operation when the DNS server 2320 is in an active state (eg, operation 4130). ) May be included.
  • the DNS resolving operation of operation 4110 represents an example of an operation in which the local DNS cache for the MEC (eg, the second DNS cache 3430) is deactivated in the DNS cache 2310. Can be.
  • the client application 510 may forward a DNS query for the URI to the DNS cache 2310 (operation 4111), and the DNS cache 2310 may respond to the DNS query of the client application 510. (Eg, DNS Cache Response) may be transmitted to the client application 510 (operation 4113).
  • the DNS cache 2310 may store at least one of an application name, a domain name, or an IP address for the domain name of the MEC application.
  • the IP address of the MEC application of the URI is present (eg, a DNS cache miss).
  • the application 510 may forward a DNS query to the DNS server 2320 (operation 4115) and obtain an IP address based on the response 4117 corresponding to the DNS query from the DNS server 2320.
  • the DNS resolving operation of operation 4130 may represent an example of an operation in which a local DNS cache for the MEC (eg, the second DNS cache 3430) is activated in the DNS cache 2310.
  • the client application 510 may forward (operation 4131, operation 4133) the DNS query for the URI to the DNS cache 2310 via the MSE 530.
  • the DNS cache 2310 may forward a DNS response to the DNS query to the MSE 530 (operation 4135).
  • the DNS cache 2310 may be used to perform a DNS query on the URI of the client application 510.
  • the MSE 530 forwards the DNS query to the DNS server 2320 (operation 4137), and the DNS server 2320 receives the DNS from the DNS server 2320. Receive a response corresponding to the query (operation 4139), and forward the received response to the client application 510 (operation 4141). can do.
  • a DNS resolving may connect to a remote server (eg, the remote server 306 of FIG. 3) or a Client App-driven MEC application through DNS resolving.
  • the DNS proxy may hook a DNS query of the client application to perform DNS resolving according to the MEC app list.
  • MSE (530) in the can support Pre-DNS resolving or DNS proxy function in the 3 rd party application (party application). For example, if a client application 510 for a MEC makes a DNS query for a specific service connection while a data connection is made through an existing basic PDU session, the DNS proxy intercepts the DNS query and uses the DNS server as the domain name for the MEC. It may query (2320), or look up in the DNS cache (2310) to return the corresponding MEC domain IP address.
  • 3 rd party applications can provide services without the MEC (or steering) without any software modifications, and additional filtering traffic (traffic filtering) for operator action.
  • FIG. 42 is a diagram illustrating an example of a service closing procedure in a discovery procedure according to various embodiments.
  • FIG. 42 may illustrate an operation example of a MEC Service Close (eg, MEC Application Context Delete) in a MEC discovery procedure according to an embodiment.
  • the application context deletion operation may be performed, for example, when the client application 510 terminates, the MSA 520 forwarding the app termination event to the MSE 530 via the MSE API. Can be.
  • the application context deletion may be performed when the use of the client application is terminated (first case) or when the client application directly requests a contextDelete (second case) through the MSE API.
  • FIG. 42 an operation example of deleting an application context according to a first case may be illustrated.
  • the client application 510 may transmit information (eg, App Stop) indicating the end of use of the application to the MSA 520. ) Can be provided.
  • information eg, App Stop
  • the MSA 520 when the MSA 520 receives information indicating the termination of the client application 510, the MSA 520 sends a notification message (eg, notifyClientAppState) to the MSE 530 to notify the state of the client application 510. ) Can be provided.
  • the notification message (eg, notifyClientAppState) includes, for example, the state of the client application (eg STOP) and the name of the client application (eg clientAppName) (and / or UID) (eg notifyClientAppState). (STOP, clientAppName)).
  • the MSE 530 may receive a notification message (eg, notifyClientAppState) from the MSA 520 and perform an application context deletion operation based on the information of the received notification message.
  • a notification message eg, notifyClientAppState
  • the operation of deleting an application context may include operation 4210, operation 4220, and operation 4230.
  • the MSE 530 may transmit a request message (eg, HTTP DELETE AppContext Data) requesting the application context deletion to the MMP server 430.
  • a request message eg, HTTP DELETE AppContext Data
  • the MSE server 530 may repeat the context deletion request several times.
  • the information may be transmitted to the MMP server 430 or transmitted to 430 or one context deletion request, including various context information.
  • the MMP server 430 may provide a response message (eg, HTTP OK 204 No Content) to the MSE 530 in response to a request message received from the MSE 530.
  • a response message eg, HTTP OK 204 No Content
  • the MMP server 430 may terminate the MEC application requested to remove a context from the running MEC application, and include the result (eg, No content) in the response message and provide the result to the MSE 530. have.
  • the MSE 530 may perform a PDU session release.
  • the MSE 530 may perform a release of a corresponding PDU session as required (for example, when a PDU session is released) after requesting context deletion from the MMP server 430.
  • a URSP rule (or CARP rule) may be the result of an authentication procedure (e.g., received by the MSA 520 and passed to the MSE 530), or the MSE 530 is an application lookup (e.g., an App lookup) result, Alternatively, it may be received as a result of context creation, and when a new DNN rule is set in the URSP rule, PDU session setup may be performed.
  • the PDU session establishment (eg, the creation of the PDU session of FIG. 17 and the release of the PDU session of FIG. 18) may be performed by the MSE 530 by the MSE 530 as described above with reference to FIG. 17 or FIG. 18. ),
  • the modem 1700 may generate / release the SMF of the 5G network (or the core network) by requesting the SMF.
  • 43 is a diagram illustrating an example of a service closing procedure in a discovery procedure according to various embodiments.
  • FIG. 43 may illustrate an operation example of a MEC Service Close (eg, MEC Application Context Delete) in a MEC discovery procedure according to an embodiment.
  • the application context deletion operation may be performed, for example, by the client application 510 forwarding the context deletion request to the MSE 530 via the MSE API.
  • the application context deletion may be performed when the use of the client application is terminated (first case) or when the client application directly requests a contextDelete (second case) through the MSE API. 43 may show an example of performing an application context deletion according to the second case.
  • the client application 510 may transmit a message (eg, contextDelete) for deleting a context to the MSE 530.
  • a message eg, contextDelete
  • the client application 510 sends a context deletion request to the MSE 530 through the MSE API together with information related to the client application (for example, an application name (appName) or UID). I can deliver it.
  • the MSE 530 may receive a message for deleting a context from the client application 510 and perform an application context deletion operation based on information (eg, an application name) of the received message.
  • the operation of deleting an application context may include operation 4310, operation 4320, and operation 4330.
  • the operation of deleting an application context may correspond to those described in the descriptions of operations 4210, 4220, and 4230 according to the application context deletion procedure of operation 4205 described above with reference to FIG. 42.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명의 다양한 실시예들에 따르면, 엣지 컴퓨팅 서비스(예: MEC(multi-access edge computing) 서비스)를 지원하기 위한 방법 그의 전자 장치에 관하여 개시한다. 다양한 실시예들에 따른 전자 장치는, 네트워크 인터페이스, 및 프로세서를 포함하고, 상기 프로세서는, 상기 네트워크 인터페이스를 이용하여, 기지국 내에 또는 상기 기지국을 통하여 연결 가능한 적어도 하나의 외부 서버로, 상기 적어도 하나의 외부 서버가 제공 가능한 어플리케이션들에 관한 정보를 획득하고, 상기 어플리케이션들에 관한 정보에 기반하여, 지정된 조건에 대응하는 어플리케이션을 포함하는 외부 서버를 선택하고, 상기 선택된 외부 서버와 데이터 전송을 수행하도록 할 수 있다. 다양한 실시예들이 가능하다.

Description

엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
다양한 실시예들은 엣지 컴퓨팅 서비스(예: MEC(multi-access edge computing) 서비스)를 지원하기 위한 방법 그의 전자 장치에 관하여 개시한다.
최근, 엣지 서버(edge server)를 이용하여 데이터를 전송하는 엣지 컴퓨팅(edge computing) 기술이 논의되고 있다. 엣지 컴퓨팅 기술은, 예를 들어, MEC(multi-access edge computing) 또는 포그 컴퓨팅(fog computing)을 포함할 수 있다. 엣지 컴퓨팅 기술은 전자 장치와 지리적으로 가까운 위치, 예를 들어, 기지국 내부 또는 기지국 근처에 설치된 별도의 서버(이하, ‘엣지 서버’ 또는 ‘MEC 서버’라 한다)를 통해 전자 장치에게 데이터를 제공하는 기술을 의미할 수 있다. 예를 들어, 전자 장치에 설치된 적어도 하나의 어플리케이션 중 낮은 지연 시간(latency)을 요구하는 어플리케이션은 외부 데이터 네트워크(DN, data network)(예: 인터넷)에 위치한 서버를 통하지 않고, 지리적으로 가까운 위치에 설치된 엣지 서버를 통해 데이터를 송수신할 수 있다.
최근에는 엣지 컴퓨팅 기술을 이용한 서비스(이하, ‘MEC 기반 서비스’ 또는 ‘MEC 서비스’라 한다)에 관하여 논의되고 있으며, MEC 기반 서비스를 지원하도록 전자 장치에 관한 연구 및 개발이 진행되고 있다. 예를 들면, 이동 통신 전자 장치의 어플리케이션은 엣지 서버(또는 엣지 서버의 어플리케이션)와 어플리케이션 레이어(application layer) 상에서 엣지 컴퓨팅 기반 데이터를 송수신할 수 있다.
MEC 기반 서비스에서, 예를 들면, 전자 장치(또는 사용자), 네트워크, 오퍼레이터(operator), 또는 어플리케이션 프로바이더(provider) 간에 서비스를 실행하기 위해 안전한 환경을 제공해야 한다. 예를 들면, MEC 서비스를 위해, 엣지 서버(또는 MEC 어플리케이션(들))는 인증(authentication)되고 접근 권한(authorization)이 부여된(또는 허가된) 전자 장치(또는 클라이언트(client) 어플리케이션)에 대해 서비스(또는 접근(access))를 제공해야 한다. 예를 들면, 전자 장치의 어플리케이션은 엣지 서버의 어플리케이션과 통신할 수 있고, 엣지 서버에서는 전자 장치의 어플리케이션에 대한 인증을 수행하고, 인증 결과에 따라 권한을 부여할 수 있다. 예를 들면, MEC 기반 서비스에서는, 전자 장치와 엣지 서버 간에 허가된 어플리케이션이 서로 통신할 수 있다. 예를 들어, 전자 장치와 엣지 서버는 상호 간에 인증이 완료되면, 디스커버리(discovery)(예: MEC 디스커버리) 절차(또는 MEC 서비스 발견 절차)를 수행할 수 있다.
한편, 전자 장치에 복수의 어플리케이션들이 설치된 경우, 각각의 어플리케이션들은 엣지 컴퓨팅 기반 데이터 전송을 수행하기 위하여 개별적으로 엣지 서버와 어플리케이션 레이어(application layer) 상에서 통신할 수 있다. 예를 들면, 종래에서는 전자 장치에서 어플리케이션들이 개별적으로 MEC 서비스 사용을 위한 인증, 권한 부여 및 디스커버리 절차를 수행할 수 있다.
다양한 실시예들에서는, 전자 장치에 대해 보다 최적의 MEC 호스트에 기반하여 MEC 어플리케이션을 실행하여 서비스를 제공할 수 있는 방법 및 장치에 관하여 개시한다.
다양한 실시예들에서는, 서비스 디스커버리 동작을 개별 어플리케이션이 아니라, 전자 장치(예: MEC 서비스 모듈)에 의해 디스커버리를 수행하기 위한 방법 및 장치에 관하여 개시한다.
다양한 실시예들에서는, MEC 디스커버리를 개별 어플리케이션이 담당하지 않고, 전자 장치(예: MEC 서비스 모듈)가 수행함으로써, 보다 신속하고 효율적으로 디스커버리를 수행할 수 있고, 최적 품질을 제공받을 수 있는 MEC 호스트를 선택할 수 있는 방법 및 장치에 관하여 개시한다.
다양한 실시예들에서는, 전자 장치에 설치된 MEC 서비스 모듈을 통해 어플리케이션들의 상태 및 전자 장치의 상태를 통합적으로 관리함으로써 안정적인 엣지 컴퓨팅 서비스를 제공할 수 있는 방법 및 장치에 관하여 개시한다.
본 발명의 다양한 실시예들에 따른 전자 장치는, 네트워크 인터페이스, 및 프로세서를 포함하고, 상기 프로세서는, 상기 네트워크 인터페이스를 이용하여, 기지국 내에 또는 상기 기지국을 통하여 연결 가능한 적어도 하나의 외부 서버로, 상기 적어도 하나의 외부 서버가 제공 가능한 어플리케이션들에 관한 정보를 획득하고, 상기 어플리케이션들에 관한 정보에 기반하여, 지정된 조건에 대응하는 어플리케이션을 포함하는 외부 서버를 선택하고, 상기 선택된 외부 서버와 데이터 전송을 수행할 수 있다.
본 발명의 다양한 실시예들에 따른 전자 장치는, 네트워크 인터페이스, 프로세서를 포함하고, 상기 프로세서는, 디스커버리 정책에 기반하여, 지정된 외부 서버로부터 서비스 가능한 어플리케이션의 앱 리스트를 획득하고, 상기 앱 리스트에 기반하여 상기 전자 장치의 클라이언트 어플리케이션과 연관되고 접속하고자 하는 어플리케이션에 관련된 정보를 상기 지정된 외부 서버로부터 획득하고, 상기 획득된 정보에 기반하여, 데이터 전송을 위한 호스트를 결정하고, 상기 호스트와 데이터 전송을 수행할 수 있다.
본 발명의 다양한 실시예들에 따른 전자 장치는, 네트워크 인터페이스, 프로세서를 포함하고, 상기 프로세서는, 디스커버리 정책에 기반하여, 지정된 외부 서버로부터 서비스 가능한 어플리케이션의 앱 리스트를 획득하고, 클라이언트 어플리케이션에 의한 컨텍스트 생성과 관련된 이벤트에 기반하여, 상기 클라이언트 어플리케이션과 연관되고 접속하고자 하는 어플리케이션에 관련된 정보를 상기 지정된 외부 서버로부터 획득하고, 상기 획득된 정보에 기반하여, 데이터 전송을 위한 호스트를 선택하고, 상기 호스트와 데이터 전송을 수행할 수 있다.
상기와 같은 과제를 해결하기 위하여 본 발명의 다양한 실시예들에서는, 상기 방법을 프로세서에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록 매체를 포함할 수 있다.
다양한 실시예들에 따른 전자 장치 및 그의 동작 방법에 따르면, 전자 장치에 대해 보다 최적의 MEC 호스트에 기반하여 MEC 어플리케이션을 실행하여 서비스를 제공할 수 있다. 다양한 실시예들에 따르면, 서비스 디스커버리 동작을 개별 어플리케이션이 아니라, 전자 장치(예: 서비스 인에이블러)에 의해 디스커버리를 수행할 수 있다. 다양한 실시예들에 따르면, MEC 디스커버리를 개별 어플리케이션이 담당하지 않고, 전자 장치(예: 서비스 인에이블러)가 수행함으로써, 보다 신속하고 효율적으로 디스커버리를 수행할 수 있고, 최적 품질을 제공받을 수 있는 MEC 호스트를 선택할 수 있다. 다양한 실시예들에 따르면, 전자 장치에 설치된 MEC 서비스 모듈을 통해 어플리케이션들의 상태 및 전자 장치의 상태를 통합적으로 관리함으로써 안정적인 엣지 컴퓨팅 서비스를 제공할 수 있다.
이 외에, 본 문서를 통해 직접적 또는 간접적으로 파악되는 다양한 효과들이 제공될 수 있다.
도 1은 다양한 실시예들에 따른 네트워크 환경 내의 전자 장치의 블록도이다.
도 2는 다양한 실시예들에 따른 레거시 네트워크 통신 및 5G 네트워크 통신을 지원하기 위한 전자 장치의 블록도이다.
도 3은 다양한 실시예들에 따른 네트워크 환경에서 MEC 기술을 설명하기 위해 개략 도시하는 도면이다.
도 4는 다양한 실시예들에 따른 네트워크 환경에서 MEC 기반 데이터 전송을 수행하는 전자 장치 및 MEC 시스템을 도시하는 도면이다.
도 5는 다양한 실시예들에 따른 네트워크 환경에서 MEC 기반 서비스를 지원하기 위한 전자 장치 및 외부 서버를 도시하는 도면이다.
도 6은 다양한 실시예들에 따른 MEC 서비스를 지원하기 위한 인증 및 디스커버리 절차를 설명하기 위해 도시하는 도면이다.
도 7은 다양한 실시예들에 따른 전자 장치의 동작 방법을 도시하는 흐름도이다.
도 8은 다양한 실시예들에 따른 전자 장치에서 인증 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 9는 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 10은 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 11은 다양한 실시예들에 따른 전자 장치에서 인증 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 12는 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 13은 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 14는 다양한 실시예들에 따른 전자 장치에서 인증 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 15A는 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 15B는 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 16은 다양한 실시예들에 따른 전자 장치의 동작 방법을 도시하는 흐름도이다.
도 17은 다양한 실시예들에 따른 전자 장치에서 정책 업데이트 동작 예를 도시하는 도면이다.
도 18은 다양한 실시예들에 따른 전자 장치에서 PDU 세션 설정 동작 예를 도시하는 도면이다.
도 19는 다양한 실시 예들에 따른 전자 장치에서 MEC 기반 데이터 전송 가능 여부를 확인하는 방법을 도시하는 흐름도이다.
도 20은 다양한 실시 예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 21은 다양한 실시 예들에 따른 전자 장치에서 디스커버리 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 22는 다양한 실시예들에 따른 전자 장치에서 디스커버리 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 23은 다양한 실시예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 24는 다양한 실시예들에 따른 전자 장치에서 디스커버리 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 25는 다양한 실시예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 26은 다양한 실시예들에 따른 전자 장치에서 디스커버리 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 27은 다양한 실시예들에 따른 디스커버리 절차에서 앱 리스트를 획득하는 동작 예를 도시하는 도면이다.
도 28은 다양한 실시예들에 따른 앱 리스트가 제공되는 예를 설명하기 위한 도면이다.
도 29는 다양한 실시예들에 따른 어플리케이션의 라이프 사이클을 도시하는 도면이다.
도 30은 다양한 실시예들에 따른 디스커버리 절차에서 컨텍스트 생성 동작의 예를 도시하는 도면이다.
도 31은 다양한 실시예들에 따른 디스커버리 절차에서 컨텍스트 생성 동작의 예를 도시하는 도면이다.
도 32는 다양한 실시예들에 따른 디스커버리 절차에서 컨텍스트 생성 동작의 예를 도시하는 도면이다.
도 33은 다양한 실시예들에 따른 디스커버리 절차에서 MEC 호스트 선택 동작의 예를 도시하는 도면이다.
도 34는 다양한 실시예들에 따른 전자 장치에서 MEC 용 로컬 DNS 캐시를 별도로 운용하는 예를 도시하는 도면이다.
도 35는 다양한 실시예들에 따른 전자 장치에서 MSE 내에 MEC 용 로컬 DNS 캐시를 운용하는 예를 도시하는 도면이다.
도 36은 다양한 실시예들에 따라 도메인 이름에 대한 IP 주소를 이용하는 동작을 도시하는 도면이다.
도 37은 다양한 실시예들에 따라 IP 주소를 공유하기 위한 신호 흐름도를 도시한다.
도 38은 다양한 실시예들에 따른 전자 장치에서 도메인 이름에 대한 IP 주소를 이용하는 방법을 도시하는 흐름도이다.
도 39는 다양한 실시예들에 따른 전자 장치에서 IP 주소를 요청하는 방법을 도시하는 흐름도이다.
도 40은 다양한 실시예들에 따른 전자 장치에서 IP 주소를 이용하여 MEC 기반 데이터 전송을 수행하는 방법을 도시하는 흐름도이다.
도 41은 다양한 실시예들에 따른 디스커버리 절차에서 DNS 리졸빙 동작의 예를 도시하는 도면이다.
도 42는 다양한 실시예들에 따른 디스커버리 절차에서 서비스 클로즈 동작의 예를 도시하는 도면이다.
도 43은 다양한 실시예들에 따른 디스커버리 절차에서 서비스 클로즈 동작의 예를 도시하는 도면이다.
도 1은 다양한 실시예들에 따른 네트워크 환경(100) 내의 전자 장치(101)의 블록도이다.
도 1을 참조하면, 네트워크 환경(100)에서 전자 장치(101)는 제1 네트워크(198)(예: 근거리 무선 통신 네트워크)를 통하여 전자 장치(102)와 통신하거나, 또는 제2 네트워크(199)(예: 원거리 무선 통신 네트워크)를 통하여 전자 장치(104) 또는 서버(108)와 통신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 서버(108)를 통하여 전자 장치(104)와 통신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 프로세서(120), 메모리(130), 입력 장치(150), 음향 출력 장치(155), 표시 장치(160), 오디오 모듈(170), 센서 모듈(176), 인터페이스(177), 햅틱 모듈(179), 카메라 모듈(180), 전력 관리 모듈(188), 배터리(189), 통신 모듈(190), 가입자 식별 모듈(196), 또는 안테나 모듈(197)을 포함할 수 있다. 어떤 실시예에서는, 전자 장치(101)에는, 이 구성 요소들 중 적어도 하나(예: 표시 장치(160) 또는 카메라 모듈(180))가 생략되거나, 하나 이상의 다른 구성 요소가 추가될 수 있다. 어떤 실시예에서는, 이 구성 요소들 중 일부들은 하나의 통합된 회로로 구현될 수 있다. 예를 들면, 센서 모듈(176)(예: 지문 센서, 홍채 센서, 또는 조도 센서)은 표시 장치(160)(예: 디스플레이)에 임베디드(embedded)된 채 구현될 수 있다.
프로세서(120)는, 예를 들면, 소프트웨어(예: 프로그램(140))를 실행하여 프로세서(120)에 연결된 전자 장치(101)의 적어도 하나의 다른 구성 요소(예: 하드웨어 또는 소프트웨어 구성 요소)를 제어할 수 있고, 다양한 데이터 처리 또는 연산을 수행할 수 있다. 일 실시예에 따르면, 데이터 처리 또는 연산의 적어도 일부로서, 프로세서(120)는 다른 구성 요소(예: 센서 모듈(176) 또는 통신 모듈(190))로부터 수신된 명령 또는 데이터를 휘발성 메모리(volatile memory)(132)에 로드(load)하고, 휘발성 메모리(132)에 저장된 명령 또는 데이터를 처리하고, 결과 데이터를 비휘발성 메모리(non-volatile memory)(134)에 저장할 수 있다. 일 실시예에 따르면, 프로세서(120)는 메인 프로세서(121)(예: 중앙 처리 장치(CPU, central processing unit) 또는 어플리케이션 프로세서(AP, application processor)), 및 이와는 독립적으로 또는 함께 운영 가능한 보조 프로세서(123)(예: 그래픽 처리 장치(GPU, graphic processing unit), 이미지 시그널 프로세서(ISP, image signal processor), 센서 허브 프로세서(sensor hub processor), 또는 커뮤니케이션 프로세서(CP, communication processor))를 포함할 수 있다. 추가적으로 또는 대체적으로, 보조 프로세서(123)는 메인 프로세서(121)보다 저전력을 사용하거나, 또는 지정된 기능에 특화되도록 설정될 수 있다. 보조 프로세서(123)는 메인 프로세서(121)와 별개로, 또는 그 일부로서 구현될 수 있다.
보조 프로세서(123)는, 예를 들면, 메인 프로세서(121)가 인액티브(inactive)(예: 슬립(sleep)) 상태에 있는 동안 메인 프로세서(121)를 대신하여, 또는 메인 프로세서(121)가 액티브(active)(예: 어플리케이션 실행) 상태에 있는 동안 메인 프로세서(121)와 함께, 전자 장치(101)의 구성 요소들 중 적어도 하나의 구성 요소(예: 표시 장치(160), 센서 모듈(176), 또는 통신 모듈(190))과 관련된 기능 또는 상태들의 적어도 일부를 제어할 수 있다. 일 실시예에 따르면, 보조 프로세서(123)(예: 이미지 시그널 프로세서 또는 커뮤니케이션 프로세서)는 기능적으로 관련 있는 다른 구성 요소(예: 카메라 모듈(180) 또는 통신 모듈(190))의 일부로서 구현될 수 있다.
메모리(130)는, 전자 장치(101)의 적어도 하나의 구성 요소(예: 프로세서(120) 또는 센서모듈(176))에 의해 사용되는 다양한 데이터를 저장할 수 있다. 데이터는, 예를 들어, 소프트웨어(예: 프로그램(140)) 및, 이와 관련된 명령에 대한 입력 데이터 또는 출력 데이터를 포함할 수 있다. 메모리(130)는, 휘발성 메모리(132) 또는 비휘발성 메모리(134)를 포함할 수 있다.
프로그램(140)은 메모리(130)에 소프트웨어로서 저장될 수 있으며, 예를 들면, 운영 체제(OS, operating system)(142), 미들웨어(middleware)(144) 또는 어플리케이션(146)을 포함할 수 있다.
입력 장치(150)는, 전자 장치(101)의 구성 요소(예: 프로세서(120))에 사용될 명령 또는 데이터를 전자 장치(101)의 외부(예: 사용자)로부터 수신할 수 있다. 입력 장치(150)는, 예를 들면, 마이크, 마우스, 키보드, 또는 디지털 펜(예: 스타일러스 펜)을 포함할 수 있다.
음향 출력 장치(155)는 음향 신호를 전자 장치(101)의 외부로 출력할 수 있다. 음향 출력 장치(155)는, 예를 들면, 스피커(speaker) 또는 리시버(receiver)를 포함할 수 있다. 스피커는 멀티미디어 재생 또는 녹음 재생과 같이 일반적인 용도로 사용될 수 있고, 리시버는 착신 전화를 수신하기 위해 사용될 수 있다. 일 실시예에 따르면, 리시버는 스피커와 별개로, 또는 그 일부로서 구현될 수 있다.
표시 장치(160)는 전자 장치(101)의 외부(예: 사용자)로 정보를 시각적으로 제공할 수 있다. 표시 장치(160)는, 예를 들면, 디스플레이, 홀로그램 장치, 또는 프로젝터 및 해당 장치를 제어하기 위한 제어 회로를 포함할 수 있다. 일 실시예에 따르면, 표시 장치(160)는 터치를 감지하도록 설정된 터치 회로(touch circuitry), 또는 상기 터치에 의해 발생되는 힘의 세기를 측정하도록 설정된 센서 회로(예: 압력 센서(pressure sensor))를 포함할 수 있다.
오디오 모듈(170)은 소리를 전기 신호로 변환시키거나, 반대로 전기 신호를 소리로 변환시킬 수 있다. 일 실시예에 따르면, 오디오 모듈(170)은, 입력 장치(150)를 통해 소리를 획득하거나, 음향 출력 장치(155), 또는 전자 장치(101)와 직접 또는 무선으로 연결된 외부 전자 장치(예: 전자 장치(102))(예: 스피커 또는 헤드폰))를 통해 소리를 출력할 수 있다.
센서 모듈(176)은 전자 장치(101)의 작동 상태(예: 전력 또는 온도), 또는 외부의 환경 상태(예: 사용자 상태)를 감지하고, 감지된 상태에 대응하는 전기 신호 또는 데이터 값을 생성할 수 있다. 일 실시예에 따르면, 센서 모듈(176)은, 예를 들면, 제스처 센서(gesture sensor), 자이로 센서(gyro sensor), 기압 센서(barometer sensor), 마그네틱 센서(magnetic sensor), 가속도 센서(acceleration sensor), 그립 센서(grip sensor), 근접 센서(proximity sensor), 컬러 센서(color sensor)(예: RGB(red, green, blue) 센서), IR(infrared) 센서, 생체 센서(biometric sensor), 온도 센서(temperature sensor), 습도 센서(humidity sensor), 또는 조도 센서(illuminance sensor)를 포함할 수 있다.
인터페이스(177)는 전자 장치(101)의 외부 전자 장치(예: 전자 장치(102))와 직접 또는 무선으로 연결되기 위해 사용될 수 있는 하나 이상의 지정된 프로토콜(protocol)들을 지원할 수 있다. 일 실시예에 따르면, 인터페이스(177)는, 예를 들면, HDMI(high definition multimedia interface), USB(universal serial bus) 인터페이스, SD(secure digital) 카드 인터페이스, 또는 오디오 인터페이스를 포함할 수 있다.
연결 단자(connection terminal)(178)는, 그를 통해서 전자 장치(101)가 외부 전자 장치(예: 전자 장치(102))와 물리적으로 연결될 수 있는 커넥터를 포함할 수 있다. 일 실시예에 따르면, 연결 단자(178)는, 예를 들면, HDMI 커넥터, USB 커넥터, SD 카드 커넥터, 또는 오디오 커넥터(예: 헤드폰 커넥터)를 포함할 수 있다.
햅틱 모듈(haptic module)(179)은 전기적 신호를 사용자가 촉각 또는 운동 감각을 통해서 인지할 수 있는 기계적인 자극(예: 진동 또는 움직임) 또는 전기적인 자극으로 변환할 수 있다. 일 실시예에 따르면, 햅틱 모듈(179)은, 예를 들면, 모터(motor), 압전 소자(piezoelectric element), 또는 전기 자극 장치(electrical stimulation device)를 포함할 수 있다.
카메라 모듈(180)은 정지 영상 및 동영상을 촬영할 수 있다. 일 실시예에 따르면, 카메라 모듈(180)은 하나 이상의 렌즈들, 이미지 센서들, 이미지 시그널 프로세서들, 또는 플래시들을 포함할 수 있다.
전력 관리 모듈(188)은 전자 장치(101)에 공급되는 전력을 관리할 수 있다. 일 실시예에 따르면, 전력 관리 모듈(188)은, 예를 들면, PMIC(power management integrated circuit)의 적어도 일부로서 구현될 수 있다.
배터리(189)는 전자 장치(101)의 적어도 하나의 구성 요소에 전력을 공급할 수 있다. 일 실시예에 따르면, 배터리(189)는, 예를 들면, 재충전 불가능한 1차 전지, 재충전 가능한 2차 전지 또는 연료 전지(fuel cell)를 포함할 수 있다.
통신 모듈(190)은 전자 장치(101)와 외부 전자 장치(예: 전자 장치(102), 전자 장치(104), 또는 서버(108)) 간의 직접(예: 유선) 통신 채널 또는 무선 통신 채널의 수립, 및 수립된 통신 채널을 통한 통신 수행을 지원할 수 있다. 통신 모듈(190)은 프로세서(120)(예: 어플리케이션 프로세서)와 독립적으로 운영되고, 직접(예: 유선) 통신 또는 무선 통신을 지원하는 하나 이상의 커뮤니케이션 프로세서를 포함할 수 있다. 일 실시예에 따르면, 통신 모듈(190)은 무선 통신 모듈(192)(예: 셀룰러 통신 모듈, 근거리 무선 통신 모듈, 또는 GNSS(global navigation satellite system) 통신 모듈) 또는 유선 통신 모듈(194)(예: LAN(local area network) 통신 모듈, 또는 전력선 통신 모듈)을 포함할 수 있다. 이들 통신 모듈 중 해당하는 통신 모듈은 제1 네트워크(198)(예: 블루투스, Wi-Fi direct 또는 IrDA(infrared data association) 같은 근거리 통신 네트워크) 또는 제2 네트워크(199)(예: 셀룰러 네트워크, 인터넷, 또는 컴퓨터 네트워크(예: LAN 또는 WAN(wide area network))와 같은 원거리 통신 네트워크)를 통하여 외부 전자 장치와 통신할 수 있다. 이런 여러 종류의 통신 모듈들은 하나의 구성 요소(예: 단일 칩)로 통합되거나, 또는 서로 별도의 복수의 구성 요소들(예: 복수 칩들)로 구현될 수 있다.
무선 통신 모듈(192)은 가입자 식별 모듈(196)에 저장된 가입자 정보(예: 국제 모바일 가입자 식별자(IMSI, international mobile subscriber identity))를 이용하여 제1 네트워크(198) 또는 제2 네트워크(199)와 같은 통신 네트워크 내에서 전자 장치(101)를 확인 및 인증할 수 있다.
안테나 모듈(197)은 신호 또는 전력을 외부(예: 외부 전자 장치)로 송신하거나 외부로부터 수신할 수 있다. 일 실시예에 따르면, 안테나 모듈(197)은 서브스트레이트(예: PCB) 위에 형성된 도전체 또는 도전성 패턴으로 이루어진 방사체를 포함하는 하나의 안테나를 포함할 수 있다. 일 실시예에 따르면, 안테나 모듈(197)은 복수의 안테나들을 포함할 수 있다. 이런 경우, 제1 네트워크(198) 또는 제2 네트워크(199)와 같은 통신 네트워크에서 사용되는 통신 방식에 적합한 적어도 하나의 안테나가, 예를 들면, 통신 모듈(190)에 의하여 상기 복수의 안테나들로부터 선택될 수 있다. 신호 또는 전력은 상기 선택된 적어도 하나의 안테나를 통하여 통신 모듈(190)과 외부 전자 장치 간에 송신되거나 수신될 수 있다. 어떤 실시예에 따르면, 방사체 이외에 다른 부품(예: RFIC)가 추가로 안테나 모듈(197)의 일부로 형성될 수 있다.
상기 구성 요소들 중 적어도 일부는 주변 기기들간 통신 방식(예: 버스, GPIO(general purpose input and output), SPI(serial peripheral interface), 또는 MIPI(mobile industry processor interface))를 통해 서로 연결되고, 신호(예: 명령 또는 데이터)를 상호 간에 교환할 수 있다.
일 실시예에 따르면, 명령 또는 데이터는 제2 네트워크(199)에 연결된 서버(108)를 통해서 전자 장치(101)와 외부의 전자 장치(104) 간에 송신 또는 수신될 수 있다. 전자 장치(102, 104) 각각은 전자 장치(101)와 동일한 또는 다른 종류의 장치일 수 있다.
일 실시예에 따르면, 전자 장치(101)에서 실행되는 동작들의 전부 또는 일부는 외부 전자 장치들(102, 104 또는 108) 중 하나 이상의 외부 장치들에서 실행될 수 있다. 예를 들면, 전자 장치(101)가 어떤 기능이나 서비스를 자동으로, 또는 사용자 또는 다른 장치로부터의 요청에 반응하여 수행해야 할 경우에, 전자 장치(101)는 기능 또는 서비스를 자체적으로 실행시키는 대신에 또는 추가적으로, 하나 이상의 외부 전자 장치들(102, 104)에게 그 기능 또는 그 서비스의 적어도 일부를 수행하라고 요청할 수 있다. 상기 요청을 수신한 하나 이상의 외부 전자 장치들(102, 104)은 요청된 기능 또는 서비스의 적어도 일부, 또는 상기 요청과 관련된 추가 기능 또는 서비스를 실행하고, 그 실행의 결과를 전자 장치(101)로 전달할 수 있다. 전자 장치(101)는 상기 결과를, 그대로 또는 추가적으로 처리하여, 상기 요청에 대한 응답의 적어도 일부로서 제공할 수 있다. 이를 위하여, 예를 들면, 클라우드 컴퓨팅(cloud computing), 분산 컴퓨팅(distributed computing), 또는 클라이언트-서버 컴퓨팅(client-server computing) 기술이 이용될 수 있다.
본 문서에 개시된 다양한 실시예들에 따른 전자 장치(101)는 다양한 형태의 장치가 될 수 있다. 전자 장치(101)는, 예를 들면, 휴대용 통신 장치(예: 스마트 폰), 휴대용 멀티미디어 장치, 휴대용 의료 기기, 카메라, 웨어러블 장치(wearable device), 또는 가전 장치를 포함할 수 있다. 본 문서의 실시예에 따른 전자 장치(101)는 전술한 기기들에 한정되지 않는다.
본 문서의 다양한 실시예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경(modifications), 균등물(equivalents), 또는 대체물(alternatives)을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성 요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다.
본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", “A 또는 B 중 적어도 하나”, "A, B 또는 C", "A, B 및 C 중 적어도 하나" 및 “A, B, 또는 C 중 적어도 하나”와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제1", "제2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성 요소를 다른 해당 구성 요소와 구분하기 위해 사용될 수 있으며, 해당 구성 요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제1) 구성 요소가 다른(예: 제2) 구성 요소에 "기능적으로” 또는 “통신적으로"라는 용어와 함께 또는 이런 용어 없이, “커플드” 또는 “커넥티드”라고 언급된 경우, 그것은 상기 어떤 구성 요소가 상기 다른 구성 요소에 직접적으로(예: 유선으로), 무선으로, 또는 제3 구성 요소를 통하여 연결될 수 있다는 것을 의미한다.
본 문서에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어(firmware)로 구현된 유닛(unit)을 포함할 수 있으며, 예를 들면, 로직(logic), 논리 블록(logic block), 부품(component), 또는 회로(circuit)의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 상기 부품의 최소 단위 또는 그 일부가 될 수 있다. 일 실시예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.
본 문서의 다양한 실시예들은 기기(machine)(예: 전자 장치(101))에 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리(136) 또는 외장 메모리(138))에 저장된 하나 이상의 명령어들(instructions)을 포함하는 소프트웨어(예: 프로그램(140))로서 구현될 수 있다. 예를 들면, 기기(예: 전자 장치(101))의 프로세서(예: 프로세서(120))는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 상기 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 상기 하나 이상의 명령어들은 컴파일러(compiler) 생성된 코드 또는 인터프리터(interpreter)에 의해 실행될 수 있는 코드(code)를 포함할 수 있다. 기기로 읽을 수 있는 저장 매체는, 비일시적(non-transitory) 저장 매체의 형태로 제공될 수 있다. 여기서, ‘비일시적’은 저장 매체가 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장 매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.
일 실시예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: CD-ROM, compact disc read only memory)의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두 개의 사용자 장치들(예: 스마트 폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시예들에 따르면, 상기 기술한 구성 요소들의 각각의 구성 요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있다. 다양한 실시예들에 따르면, 전술한 해당 구성 요소들 중 하나 이상의 구성 요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성 요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성 요소들(예: 모듈 또는 프로그램)은 하나의 구성 요소로 통합될 수 있다. 이런 경우, 통합된 구성 요소는 상기 복수의 구성 요소들 각각의 구성 요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성 요소들 중 해당 구성 요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시예들에 따르면, 모듈, 프로그램 또는 다른 구성 요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱(heuristic)하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.
본 발명의 다양한 실시예들을 서술하기에 앞서, 본 발명의 일 실시예가 적용될 수 있는 전자 장치(101)에 대하여 설명한다.
도 2는 다양한 실시예들에 따른 레거시 네트워크 통신 및 5G 네트워크 통신을 지원하기 위한 전자 장치(101)의 블록도(200)이다.
도 2를 참조하면, 전자 장치(101)는 제1 커뮤니케이션 프로세서(212), 제2 커뮤니케이션 프로세서(214), 제1 RFIC(222), 제2 RFIC(224), 제3 RFIC(226), 제4 RFIC(228), 제1 RFFE(radio frequency front end)(232), 제2 RFFE(234), 제1 안테나 모듈(242), 제2 안테나 모듈(244), 및 안테나(248)를 포함할 수 있다. 전자 장치(101)는 프로세서(120) 및 메모리(130)를 더 포함할 수 있다.
네트워크(199)는 제1 네트워크(292)와 제2 네트워크(294)를 포함할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는 도 1에 기재된 부품들 중 적어도 하나의 부품을 더 포함할 수 있고, 네트워크(199)는 적어도 하나의 다른 네트워크를 더 포함할 수 있다. 일 실시예에 따르면, 제1 커뮤니케이션 프로세서(212), 제2 커뮤니케이션 프로세서(214), 제1 RFIC(222), 제2 RFIC(224), 제4 RFIC(228), 제1 RFFE(232), 및 제2 RFFE(234)는 무선 통신 모듈(192)의 적어도 일부를 형성할 수 있다. 다른 실시예에 따르면, 제4 RFIC(228)는 생략되거나, 제3 RFIC(226)의 일부로서 포함될 수 있다.
제1 커뮤니케이션 프로세서(212)는 제1 네트워크(292)와의 무선 통신에 사용될 대역의 통신 채널의 수립, 및 수립된 통신 채널을 통한 레거시 네트워크(legacy network) 통신을 지원할 수 있다. 다양한 실시예들에 따르면, 제1 네트워크(292)는 2세대(2G), 3G, 4G, 또는 LTE(long term evolution) 네트워크를 포함하는 레거시 네트워크일 수 있다.
제2 커뮤니케이션 프로세서(214)는 제2 네트워크(294)와의 무선 통신에 사용될 대역 중 지정된 대역(예: 약 6GHz ~ 약 60GHz)에 대응하는 통신 채널의 수립, 및 수립된 통신 채널을 통한 5G 네크워크 통신을 지원할 수 있다. 다양한 실시예들에 따르면, 제2 네트워크(294)는 3GPP에서 정의하는 5G 네트워크일 수 있다.
추가적으로, 일 실시예에 따르면, 제1 커뮤니케이션 프로세서(212) 또는 제2 커뮤니케이션 프로세서(214)는 제2 네트워크(294)와의 무선 통신에 사용될 대역 중 다른 지정된 대역(예: 약 6GHz 이하)에 대응하는 통신 채널의 수립, 및 수립된 통신 채널을 통한 5G 네크워크 통신을 지원할 수 있다. 일 실시예에 따르면, 제1 커뮤니케이션 프로세서(212)와 제2 커뮤니케이션 프로세서(214)는 단일(single) 칩 또는 단일 패키지 내에 구현될 수 있다. 다양한 실시예들에 따르면, 제1 커뮤니케이션 프로세서(212) 또는 제2 커뮤니케이션 프로세서(214)는 프로세서(120), 보조 프로세서(123), 또는 통신 모듈(190)과 단일 칩 또는 단일 패키지 내에 형성될 수 있다.
제1 RFIC(222)는, 송신 시에, 제1 커뮤니케이션 프로세서(212)에 의해 생성된 기저대역(baseband) 신호를 제1 네트워크(292)(예: 레거시 네트워크)에 사용되는 약 700MHz 내지 약 3GHz의 라디오 주파수(RF) 신호로 변환할 수 있다. 수신 시에는, RF 신호가 안테나(예: 제1 안테나 모듈(242))를 통해 제1 네트워크(292)(예: 레거시 네트워크)로부터 획득되고, RFFE(예: 제1 RFFE(232))를 통해 전처리(preprocess)될 수 있다. 제1 RFIC(222)는 전처리된 RF 신호를 제1 커뮤니케이션 프로세서(212)에 의해 처리될 수 있도록 기저대역 신호로 변환할 수 있다.
제2 RFIC(224)는, 송신 시에, 제1 커뮤니케이션 프로세서(212) 또는 제2 커뮤니케이션 프로세서(214)에 의해 생성된 기저대역 신호를 제2 네트워크(294)(예: 5G 네트워크)에 사용되는 Sub6 대역(예: 약 6GHz 이하)의 RF 신호(이하, 5G Sub6 RF 신호)로 변환할 수 있다. 수신 시에는, 5G Sub6 RF 신호가 안테나(예: 제2 안테나 모듈(244))를 통해 제2 네트워크(294)(예: 5G 네트워크)로부터 획득되고, RFFE(예: 제2 RFFE(234))를 통해 전처리될 수 있다. 제2 RFIC(224)는 전처리된 5G Sub6 RF 신호를 제1 커뮤니케이션 프로세서(212) 또는 제2 커뮤니케이션 프로세서(214) 중 대응하는 커뮤니케이션 프로세서에 의해 처리될 수 있도록 기저대역 신호로 변환할 수 있다.
제3 RFIC(226)는 제2 커뮤니케이션 프로세서(214)에 의해 생성된 기저대역 신호를 제2 네트워크(294)(예: 5G 네트워크)에서 사용될 5G Above6 대역(예: 약 6GHz ~ 약 60GHz)의 RF 신호(이하, 5G Above6 RF 신호)로 변환할 수 있다. 수신 시에는, 5G Above6 RF 신호가 안테나(예: 안테나(248))를 통해 제2 네트워크(294)(예: 5G 네트워크)로부터 획득되고 제3 RFFE(236)를 통해 전처리될 수 있다. 제3 RFIC(226)는 전처리된 5G Above6 RF 신호를 제2 커뮤니케이션 프로세서(214)에 의해 처리될 수 있도록 기저대역 신호로 변환할 수 있다. 일 실시예에 따르면, 제3 RFFE(236)는 제3 RFIC(226)의 일부로서 형성될 수 있다.
전자 장치(101)는, 일 실시예에 따르면, 제3 RFIC(226)와 별개로 또는 적어도 그 일부로서, 제4 RFIC(228)를 포함할 수 있다. 이런 경우, 제4 RFIC(228)는 제2 커뮤니케이션 프로세서(214)에 의해 생성된 기저대역 신호를 중간(intermediate) 주파수 대역(예: 약 9GHz ~ 약 11GHz)의 RF 신호(이하, IF 신호)로 변환한 뒤, 상기 IF 신호를 제3 RFIC(226)로 전달할 수 있다. 제3 RFIC(226)는 IF 신호를 5G Above6 RF 신호로 변환할 수 있다. 수신 시에, 5G Above6 RF 신호가 안테나(예: 안테나(248))를 통해 제2 네트워크(294)(예: 5G 네트워크)로부터 수신되고 제3 RFIC(226)에 의해 IF 신호로 변환될 수 있다. 제4 RFIC(228)는 IF 신호를 제2 커뮤니케이션 프로세서(214)가 처리할 수 있도록 기저대역 신호로 변환할 수 있다.
일 실시예에 따르면, 제1 RFIC(222)와 제2 RFIC(224)는 단일 칩 또는 단일 패키지의 적어도 일부로 구현될 수 있다. 일 실시예에 따르면, 제1 RFFE(232)와 제2 RFFE(234)는 단일 칩 또는 단일 패키지의 적어도 일부로 구현될 수 있다. 일 실시예에 따르면, 제1 안테나 모듈(242) 또는 제2 안테나 모듈(244) 중 적어도 하나의 안테나 모듈은 생략되거나 다른 안테나 모듈과 결합되어 대응하는 복수의 대역들의 RF 신호들을 처리할 수 있다.
일 실시예에 따르면, 제3 RFIC(226)와 안테나(248)는 동일한 서브스트레이트에 배치되어 제3 안테나 모듈(246)을 형성할 수 있다. 예를 들어, 무선 통신 모듈(192) 또는 프로세서(120)가 제1 서브스트레이트(예: main PCB)에 배치될 수 있다. 이런 경우, 제1 서브스트레이트와 별도의 제2 서브스트레이트(substrate)(예: sub PCB)의 일부 영역(예: 하면)에 제3 RFIC(226)가, 다른 일부 영역(예: 상면)에 안테나(248)가 배치되어, 제3 안테나 모듈(246)이 형성될 수 있다. 제3 RFIC(226)와 안테나(248)를 동일한 서브스트레이트에 배치함으로써 그 사이의 전송 선로의 길이를 줄이는 것이 가능하다. 이는, 예를 들면, 5G 네트워크 통신에 사용되는 고주파 대역(예: 약 6GHz ~ 약 60GHz)의 신호가 전송 선로에 의해 손실(예: 감쇄)되는 것을 줄일 수 있다. 이로 인해, 전자 장치(101)는 제2 네트워크(294)(예: 5G 네트워크)와의 통신의 품질 또는 속도를 향상시킬 수 있다.
일 실시예에 따르면, 안테나(248)는 빔 포밍(beamforming)에 사용될 수 있는 복수개의 안테나 엘리먼트들(antenna elements)을 포함하는 안테나 어레이(antenna array)로 형성될 수 있다. 이런 경우, 제3 RFIC(226)는, 예를 들면, 제3 RFFE(236)의 일부로서, 복수개의 안테나 엘리먼트들에 대응하는 복수개의 위상 변환기(phase shifter)(238)들을 포함할 수 있다. 송신 시에, 복수개의 위상 변환기(238)들 각각은 대응하는 안테나 엘리먼트를 통해 전자 장치(101)의 외부(예: 5G 네트워크의 베이스 스테이션)로 송신될 5G Above6 RF 신호의 위상을 변환할 수 있다. 수신 시에, 복수개의 위상 변환기(238)들 각각은 대응하는 안테나 엘리먼트를 통해 상기 외부로부터 수신된 5G Above6 RF 신호의 위상을 동일한 또는 실질적으로 동일한 위상으로 변환할 수 있다. 이것은 전자 장치(101)와 상기 외부 간의 빔 포밍을 통한 송신 또는 수신을 가능하게 한다.
제2 네트워크(294)(예: 5G 네트워크)는 제1 네트워크(292)(예: 레거시 네트워크)와 독립적으로 운영되거나(예: Stand-Alone(SA)), 연결되어 운영될 수 있다(예: Non-Stand Alone(NSA)). 예를 들면, 5G 네트워크에는 액세스 네트워크(예: 5G radio access network(RAN) 또는 next generation RAN(NG RAN))만 있고, 코어 네트워크(예: next generation core(NGC))는 없을 수 있다. 이런 경우, 전자 장치(101)는 5G 네트워크의 액세스 네트워크에 액세스한 후, 레거시 네트워크의 코어 네트워크(예: evolved packed core(EPC))의 제어 하에 외부 네트워크(예: 인터넷)에 액세스할 수 있다. 레거시 네트워크와 통신을 위한 프로토콜 정보(예: LTE 프로토콜 정보) 또는 5G 네트워크와 통신을 위한 프로토콜 정보(예: New Radio(NR) 프로토콜 정보)는 메모리(230)에 저장되어, 다른 부품(예: 프로세서(120), 제1 커뮤니케이션 프로세서(212), 또는 제2 커뮤니케이션 프로세서(214))에 의해 액세스될 수 있다.
이하에서, 도면 및 설명에서 서술되는 5G 네트워크 기술은 ITU(international telecommunication union) 또는 3GPP에 의하여 정의되는 표준 규격(예: TS(technical specification) 23.501))을 참조하며, MEC 기술은 ETSI(European telecommunication standards institute)에 의하여 정의되는 표준 규격(예: MEC 001 내지 MEC 016)을 참조할 수 있다. 이하에서는, MEC 기술에 기반하여 내용을 서술하지만, 동일 또는 유사한 원리가 오픈포그 컨소시엄(openfog consortium)에 의하여 정의되는 포그 컴퓨팅(fog computing) 기술에 적용될 수 있다.
도 3은 다양한 실시예들에 따른 네트워크 환경(300)에서 MEC 기술을 설명하기 위해 개략 도시하는 도면이다.
도 3을 참조하면, 네트워크 환경(300)(예: 도 1의 네트워크 환경(100))에 포함되는 구성요소들 각각은 물리적인 개체(entity) 단위를 의미하거나, 개별적인 기능(function)을 수행할 수 있는 소프트웨어 또는 모듈 단위를 의미할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 사용자에 의해 사용되는 장치를 의미할 수 있다. 전자 장치(101)는, 예를 들어, 단말(terminal), 사용자 단말(UE, user equipment), 이동국(mobile station), 가입자국(subscriber station), 원격 단말(remote terminal), 무선 단말(wireless terminal), 또는 사용자 장치(user device)를 의미할 수 있다.
일 실시예에 따르면, AN(access network)(302)은 전자 장치(101)와의 무선 통신을 위한 채널(channel)을 제공할 수 있다. AN(302)은 RAN(radio access network), 기지국(base station), 이노드비(eNB, eNodeB), 5G 노드(5G node), 송수신 포인트(TRP, transmission/reception point), 또는 5GNB(5th generation NodeB)를 의미할 수 있다.
일 실시예에 따르면, CN(core network)(303)은 전자 장치(101)의 가입자 정보, 전자 장치(101)의 이동성(mobility), 전자 장치(101)의 접속 권한(access authorization), 데이터 패킷의 트래픽(traffic), 또는 과금 정책 중 적어도 하나를 관리할 수 있다. CN(303)은 UPF(user plane function) 노드, AMF(access & mobility management function) 노드, SMF(session management function) 노드, UDM(unified data management) 노드, 또는 PCF(policy control function) 노드 중 적어도 하나를 포함할 수 있다.
일 실시예에 따르면, DN(data network)(예: 제1 DN(304-1), 제2 DN(304-2))은 CN(303) 및 AN(302)을 통해 전자 장치(101)에게 데이터(또는 데이터 패킷)를 송수신 함으로써 서비스(예: 인터넷 서비스, IMS(IP multimedia subsystem) 서비스)를 제공할 수 있다. 예를 들어, DN(304-1, 304-2)은 통신 사업자에 의하여 관리될 수 있다. 일 실시예에 따르면, 제1 DN(304-1)은 리모트(remote) 서버(306)와 연결되고, 제2 DN(304-2)은 엣지 서버(305)(예: MEC 서버)와 연결될 수 있다. 예를 들어, CN(303)이 AN(302)(또는 엣지 서버(305))와 인접한 위치에 배치되면, 제2 DN(304-2)은 CN(303)과 인접한 위치에 배치될 수 있다.
일 실시예에 따르면, 리모트 서버(306)는 어플리케이션과 관련된 콘텐츠를 제공할 수 있다. 예를 들어, 리모트 서버(306)는 콘텐츠 사업자에 의하여 관리될 수 있다.
일 실시예에 따르면, 복수의 어플리케이션들(예: 제1 어플리케이션(제1 App)(310-1), 제2 어플리케이션(제2 App)(310-2), ...)이 전자 장치(101)에 설치(install)(또는 저장)될 수 있다. 복수의 어플리케이션들은, 예를 들어, 전자 장치(101)에 미리 설치된 기본 어플리케이션, 통신 사업자에 의하여 제공되는 어플리케이션, 또는 3rd 파티(party) 어플리케이션 중 하나일 수 있다. 복수의 어플리케이션들은 데이터 전송 속도, 지연 시간(또는 속도)(latency), 신뢰성(reliability), 네트워크에 접속(access)된 전자 장치의 수, 전자 장치(101)의 네트워크 접속 주기, 또는 평균 데이터 사용량 중 적어도 하나에 기반하여 서로 다른 네트워크 서비스를 요구(require)할 수 있다. 서로 다른 네트워크 서비스는, 예를 들어, eMBB(enhanced mobile broadband), URLLC(ultra- reliable and low latency communication), 또는 mMTC(massive machine type communication)를 포함할 수 있다. eMBB는, 예를 들어, 스마트폰 서비스와 같이 높은 데이터 전송 속도와 낮은 지연 시간(latency)을 요구하는 네트워크 서비스를 의미할 수 있다. URLLC는, 예를 들어, 재난 구조 네트워크나 V2X(vehicle to everything)과 같이 낮은 지연 시간과 높은 신뢰성(reliability)을 요구하는 네트워크 서비스를 의미할 수 있다. mMTC는, 예를 들어, IoT(internet of things)와 같이 복수의 개체(entity)들 간 서로 연결되면서 낮은 지연 시간을 요구하지 않는 네트워크 서비스를 의미할 수 있다.
일 실시예에 따르면, 엣지 서버(305)(예: MEC 서버)는 전자 장치(101)가 연결된 기지국(예: AN(302))의 내부 또는 기지국과 지리적으로 가까운 위치에 배치되고, 리모트 서버(306)가 제공하는 콘텐츠와 적어도 일부가 동일한 콘텐츠를 제공할 수 있다. 도 3에서는 도시되지 않았으나, 엣지 서버(305)는 CN(303) 내부에 배치되거나 별도의 사용자 컴퓨터에 배치될 수 있다. 예를 들어, 리모트 서버(306)는 전자 장치(101)의 위치와 무관하게 전자 장치(101)에게 콘텐츠를 제공하는 반면에, 엣지 서버(305)는 엣지 서버(305)와 인접한 위치에 위치한 전자 장치(101)에게 콘텐츠를 제공하는 지역성을 가질 수 있다. 일 실시예에 따르면, 전자 장치(101)의 복수의 어플리케이션들(310-1, 310-2)은 리모트 서버(306)와 데이터 전송을 수행하거나, 또는 엣지 서버(305)와 엣지 컴퓨팅(예: MEC)에 기반한 데이터 전송을 수행할 수 있다.
일 실시예에 따르면, 전자 장치(101)의 복수의 어플리케이션들(310-1, 310-2)은 요구되는 서비스 타입(예: 네트워크 서비스 타입, 어플리케이션 서비스 타입 및/또는 요구 사항)에 기반하여 리모트 서버(306)와 데이터 전송을 수행하거나, 또는 엣지 서버(305)와 엣지 컴퓨팅에 기반한 데이터 전송을 수행할 수 있다. 예를 들어, 제1 어플리케이션(제1 App)(310-1)이 낮은 지연 시간을 요구하지 않으면, 제1 어플리케이션(310-1)은 리모트 서버(306)와 데이터 전송을 수행할 수 있다. 다른 예를 들어, 제2 어플리케이션(310-2)이 낮은 지연 시간을 요구하면, 제2 어플리케이션(제2 App)(310-2)은 엣지 서버(305)와 데이터 전송을 수행할 수 있다.
다른 실시예에 따르면, 복수의 어플리케이션들(310-1, 320-2)은 별도의 요구(requirement)를 고려하지 않고 전자 장치(101)(또는 어플리케이션)가 엣지 컴퓨팅 서비스에 가입되어 있는지에 기반하여 데이터 전송을 수행할 수 있다. 다른 실시예에 따르면, 어플리케이션이 통신 사업자에 의하여 제공되는 어플리케이션이면, 어플리케이션은 별도의 요구 또는 엣지 컴퓨팅 서비스 가입 여부를 고려하지 않고 데이터 전송을 수행할 수 있다.
도 4는 다양한 실시예들에 따른 네트워크 환경(400)에서 MEC 기반 데이터 전송을 수행하는 전자 장치(101) 및 MEC 시스템(405)을 도시하는 도면이다.
일 실시들에 따르면, 도 4에 도시된 MEC 호스트(host)(447)는 도 3을 참조한 설명 부분에서 설명한 바와 같은 엣지 서버(305)에 대응할 수 있으며, 도 4에는 도시되지 않았지만, 전자 장치(101)는 MEC 호스트(447) 또는 MMP(MEC Management Proxy) 서버(430)(예: 라이프 사이클 관리(LCM, life cycle management) 프록시(proxy) 서버) 사이에 배치되는 AN(302)를 통해 무선 통신을 수행할 수 있다.
도 4에 도시한 바와 같이, 도 4는, 예를 들면, 엣지 컴퓨팅 서비스(예: MEC 서비스)를 위해 전자 장치(101) 내 서비스 에이전트(service agent)(412)(예: MSA, multi-access service agent)와 서비스 인에이블러(service enabler)(414)(예: MSE, multi-access service enabler)를 포함하는 MEC 서비스 모듈(또는 MEC 서비스 레이어)(410)과 연동하는 네트워크 엔티티들을 나타낼 수 있다.
도 4를 참조하면, 네트워크 환경(400)(예: 도 3의 네트워크 환경(300))에서, MEC 사용자 평면(user plane)은 전자 장치(101)의 사용자에게 서비스를 제공하기 위하여 어플리케이션들(또는 클라이언트 어플리케이션(client application))(예: 제1 App(310-1), 제2 App(310-2), ...) 및 MEC 호스트(447)(예: 엣지 서버(305)(또는 MEC 서버))에 설치된 MEC 어플리케이션들(MEC Apps)(또는 엣지 어플리케이션 또는 ME(multi-access edge) 어플리케이션)(예: 제1 MEC App(460-1), 제2 MEC App(460-2), ...) 간 사용자 데이터 패킷을 전송하기 위한 경로(path)(예: 데이터 경로(data path))를 의미할 수 있다. 일 실시예에 따르면, MEC 제어 평면(control plane)은 사용자 평면 상에서 송수신 되는 사용자 데이터 패킷을 위한 엣지 컴퓨팅 시스템(예: MEC 시스템(405))의 제어 정보를 전송하기 위한 경로(예: 제어 경로(control path))를 의미할 수 있다.
다양한 실시예들에 따르면, 도 4의 예시에서 서비스 에이전트(예: MSA)(412) 및 서비스 인에이블러(예: MSE)(414)와 MMP 서버(430) 간에 연동하는 제어 경로(예: MEC 제어 평면)에서, 인증(authentication), 권한(authorization) 부여, 및 디스커버리(discovery) 절차에 관하여 개시한다. 일 실시예에 따르면, 디스커버리 절차 이후 전자 장치(101)의 어플리케이션들(예: 제1 App(310-1), 제2 App(310-2))과 MEC 호스트(447)의 MEC 어플리케이션들(예: 제1 MEC App(460-1), 제2 ME App(460-2)) 간에 데이터 경로(예: MEC 사용자 평면)를 통해 MEC 데이터 서비스가 제공될 수 있다. 도 4에서 도시되지는 않았으나, 전자 장치(101)는 DNS(domain name system) 쿼리/응답(query/response) 데이터 경로를 통해 DNS 서버와 데이터 통신을 수행할 수 있다.
일 실시예에 따르면, MEC 시스템(405)은 통신 사업자의 네트워크에 배치되고, MEC에 기반한 데이터 전송에 이용될 수 있다. MEC 시스템(405)은 MMP 서버(430), OSS(operation support system)(435), 오케스트레이터(orchestrator)(440), MEP(ME platform) 매니저(445), 및 MEC 호스트(447)를 포함할 수 있다. 일 실시예에 따르면, MEC 호스트(447)는 복수 개일 수 있다.
일 실시예에 따르면, MMP 서버(430)는 사용자 단말(UE, user equipment)(예: 전자 장치(101))에 엣지 컴퓨팅 시스템(예: MEC 시스템(405))에 대한 사용자 어플리케이션 인터페이스(참조: ETSI MEC 016 표준 참고)를 제공할 수 있다. 예를 들어, 전자 장치(101)는 MMP 서버(430)에게 MEC 시스템(405)이 제공 가능한 어플리케이션(들)에 관한 정보(예: 가용 어플리케이션 목록)를 요청할 수 있고, MEC 시스템(405)에 특정 어플리케이션의 실행 요청(예: context creation) 및 중지 요청(예: context termination)을 전달할 수 있다. 다른 예를 들어, MMP 서버(430)는 MEC 시스템(405)에 설치된 어플리케이션들(예: 460-1, 460-2, ...)의 라이프 사이클(life cycle)(예:)에 대한 관리를 수행할 수 있다. 예를 들어, MMP 서버(430)는 전자 장치(101)의 요청을 수신하고, 수신된 요청을 MEC 시스템(405)(예: OSS(435) 및 오케스트레이터(440))으로 전달하여, MEC 시스템(405)에 설치된 어플리케이션들(예: 460-1, 460-2, ...)의 라이프 사이클에 대한 관리를 수행할 수 있다.
일 실시예에 따르면, OSS(435)는 어플리케이션의 인스턴스화(instantiation) 또는 어플리케이션의 종료(termination)를 승인(grant)할 수 있다. 어플리케이션의 인스턴스는 어플리케이션을 실행하기 위한 명령어들(또는 인스트럭션들(instructions))의 집합일 수 있으며, 인스턴스화는 MEC 호스트(447)의 프로세서가 인스턴스를 통해 MEC 어플리케이션을 실행하는 동작을 의미할 수 있다.
일 실시예에 따르면, 오케스트레이터(440)는 이용 가능한 자원(resource), 이용 가능한 MEC 서비스, 어플리케이션의 규칙(rule) 및 요구사항(requirement), 운영자(operator)의 정책, 또는 토폴로지(topology) 중 적어도 하나에 기반하여 MEC에 기반한 데이터 전송의 전반적인 기능을 관리 및 유지할 수 있다. 예를 들어, 오케스트레이터(440)는 전자 장치(101)의 어플리케이션에 적합한 MEC 호스트(예: 도 4의 MEC 호스트(447))를 선택하거나, 어플리케이션의 인스턴스화의 트리거링(triggering) 또는 종료를 수행할 수 있다.
일 실시예에 따르면, MEP 매니저(445)는 어플리케이션의 규칙, 요구사항, 서비스 승인, 또는 트래픽 규칙 중 적어도 하나를 관리할 수 있다.
일 실시예에 따르면, MEC 호스트(447)는 전자 장치(101)에 설치된 적어도 하나의 어플리케이션들(예: 310-1, 310-2, ...)에 대응하는 적어도 하나의 MEC 어플리케이션들(예: 460-1, 460-2)을 포함할 수 있다. 일 실시예에 따르면, MEC 호스트(447)는 ME 플랫폼(platform)(450)을 포함할 수 있다. ME 플랫폼(450)은 MEP 매니저(445)로부터 트래픽 규칙을 수신하고, MEC 사용자 평면 상에서 트래픽 규칙을 조절할 수 있다.
일 실시예에 따르면, MEC 호스트(447)는 전자 장치(101)의 MEC 서비스 모듈(또는 MEC 서비스 레이어)(410)과 데이터를 교환하도록 구성되는 MEL(MEC enabling layer) 서버(455)를 포함할 수 있다. MEL 서버(455)는, 예를 들어, MMP 서버(430)와 동일 또는 유사한 기능을 수행할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 MMP 서버(430) 또는 MEL 서버(455)와 이하 서술되는 제어 데이터 교환을 수행할 수 있다. 일 실시예에 따르면, MEL 서버(455)는 MEC 호스트(447)에서 동작하는 어플리케이션(또는 서비스)일 수 있다. 다른 실시예에 따르면, MEL 서버(455)는 MEC 호스트(427)의 외부에 배치될 수 있다. 이 경우, MEL 서버(455)는 OSS(435), 오케스트레이터(440), 또는 MEP 매니저(445) 중 적어도 하나와 연결될 수 있다. 일 실시예에 따르면, MEL 서버(455)는 MEC 호스트(447)의 구성 요소에 포함하지 않을 수 있다. 예를 들어, 도 4에서 MEL 서버(455)는 생략(또는 제외)될 수 있다.
일 실시예에 따르면, 제어 데이터는 MEC 시스템(405)이 제공 가능한 어플리케이션 디스커버리(discovery), 라이프 사이클 동기화(LCS, life cycle synchronization), 또는 인증(authentication) 절차(procedure) 중 적어도 하나에 대한 데이터를 포함할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 복수의 어플리케이션들(예: 310-1, 310-2, ...)을 포함하는 어플리케이션 레이어(446)(예: 도 1의 어플리케이션(146)) 및 MEC 기반 데이터 전송을 통합적으로 관리하기 위한 MEC 서비스 모듈(410)을 포함할 수 있다. 어플리케이션 레이어(446) 및 MEC 서비스 모듈(410) 각각은 소프트웨어 또는 프로그램 모듈을 의미할 수 있다. 소프트웨어 또는 프로그램 모듈은 전자 장치(101)에 포함되는 프로세서(예: 도 1의 프로세서(120))가 실행하는 명령어들로 구성될 수 있다. 전자 장치(101)는 레이어들 별로 데이터를 처리하고, 네트워크 인터페이스(network interface)(420)(또는 통신 회로)(예: 도 1 또는 도 2의 무선 통신 모듈(192))를 통해 데이터 전송을 수행할 수 있다. 일 실시예에 따르면, 네트워크 인터페이스(420)는 도 1의 보조 프로세서(123) 또는 통신 모듈(190) 중 적어도 일부일 수 있다. 도 4에서는 어플리케이션 레이어(446)와 별도의 레이어로 구성되는 MEC 서비스 모듈(또는 MEC 서비스 레이어)(410)을 도시하였지만, 다른 실시예에 따르면, MEC 서비스 모듈(410)은 적어도 일부가 어플리케이션 레이어(446)에 포함되는 어플리케이션의 형태로 구성될 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 서비스 에이전트(예: MSA)(412) 및 서비스 인에이블러(예: MSE)(414)을 포함할 수 있다. 다양한 실시예들에 따르면, MEC 서비스 모듈(410)은 다양한 실시예들에 따른 인증 및 권한 부여(예: AA(authentication/authorization)) 및 정책(policy)(예: 어플리케이션 라우팅 정책(app routing policy), 디스커버리 정책(discovery policy)(또는 모니터링 정책(monitoring policy))(예: 모니터링할 정보 리스트))을 수신하여 처리할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 서비스 에이전트(예: MSA)(412)를 이용하여 AA(authentication/authorization) 및 정책(예: 모니터링할 정보 리스트)를 수신하고, 서비스 인에이블러(예: MSE)(414)를 이용하여 수신된 정책에 기반한 라우트(route) 설정 및 MEC 디스커버리 절차를 수행할 수 있다.
다양한 실시예들에 따르면, MEC 서비스 모듈(410)은 MEC 서비스 모듈(410) 내의 엔티티(entity)(예: 서비스 에이전트(MSA)(412) 또는 서비스 인에이블러(MSE)(414)) 중 적어도 어느 하나가 MEC 디스커버리 조건에 대한 모니터링을 수행하도록 동작할 수 있으며, 해당 엔티티에 의해 모니터링된 결과를 서비스 인에이블러(MSE)(414)에 전달하도록 동작할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 서비스 에이전트(MSA)(412)를 통해 AA 및 디스커버리 관련 정책을 획득(또는 수신)하도록 할 수 있다. 일 실시예에 따라, 서비스 에이전트(412)가 모니터링을 수행하는 경우, 서비스 에이전트(412)에 의해 MEC 디스커버리 조건을 모니터링 하여, 조건을 충족할 시, 서비스 인에이블러(MSE)(414)에 MEC 디스커버리 요청을 전달하고, 서비스 인에이블러(414)를 통해 MEC 디스커버리 절차를 수행할 수 있다. 다른 실시예에 따라, 서비스 인에이블러(414)가 모니터링을 수행하는 경우, 서비스 에이전트(412)가 서비스 인에이블러(414)로 정책을 전달하고, 서비스 인에이블러(414)는 전달된 정책에 따라 MEC 디스커버리 조건을 모니터링 하여, 조건을 충족할 시 MEC 디스커버리 절차를 수행할 수 있다.
일 실시예에 따르면, 서비스 에이전트(412)는 전자 장치(101)의 컨텍스트(context) 정보를 모니터링 할 수 있다. 컨텍스트 정보는, 예를 들어, 전자 장치(101)에 설치된 어플리케이션들(예: 310-1, 310-2, ...) 중 MEC에 기반한 데이터 전송을 지원하는 어플리케이션에 관한 정보, 전자 장치(101)의 이동성과 관련된 정보, 어플리케이션의 라이프 사이클 정보, 전자 장치(101)의 상태에 관한 정보, 센서에 의하여 획득된 정보, 또는 네트워크 성능 중 적어도 하나를 의미할 수 있다. 전자 장치(101)의 이동성과 관련된 정보는, 예를 들어, 전자 장치(101)의 움직임을 나타내는 정보, 전자 장치(101)와 연결된 기지국의 변경과 관련된 정보, 또는 전자 장치(101)가 지정된 영역에 진입하는 지와 관련된 정보 중 적어도 하나를 포함할 수 있다. 지정된 지역은, 예를 들어, LADN(local area data network), TA(tracking area), 기지국의 셀(cell), 기지국 간 핸드오버(handover)가 발생하는 영역, 또는 위치 기반 서비스(예: 셀룰러, 위성, 또는 Wi-Fi(wireless fidelity)에 기반한 위치 측정 기술)에 의하여 결정된 영역 중 적어도 하나를 의미할 수 있다. 어플리케이션의 라이프 사이클 정보는, 예를 들어, 일련의 주기를 가지는 어플리케이션의 상태(예: 라이프 사이클)를 나타낼 수 있다. 전자 장치(101)의 상태에 관한 정보는, 예를 들어, 디스플레이(예: 도 1의 표시 장치(160))의 온/오프(on/off) 상태, 배터리(예: 도 1의 배터리(189)) 상태, 메모리(예: 도 1의 메모리(130)) 사용 상태, 수신 신호 세기, 타임아웃(time-out) 정보, 또는 CPU(예: 도 1의 프로세서(120)) 사용 상태 중 적어도 하나를 의미할 수 있다. 센서에 의하여 획득된 정보는, 예를 들어, 도 1에 설명된 센서 모듈(176)에 의하여 획득된 정보를 의미할 수 있다. 네트워크 성능은, 예를 들어, 전자 장치(101)가 연결된 네트워크의 주파수 대역폭(bandwidth) 또는 지연 시간(latency) 중 적어도 하나를 의미할 수 있다. 다양한 실시예들에 따른, 서비스 에이전트(412)에 관하여 후술하는 도면들을 참조하여 상세히 설명된다.
일 실시 예에 따르면, 서비스 인에이블러(414)는 모니터링된 컨텍스트 정보에 기반하여 어플리케이션들(예: 310-1, 310-2, ...)의 MEC 기반 데이터 전송을 관리(또는 처리)할 수 있다.
예를 들어, 복수의 어플리케이션들(예: 310-1, 310-2, ...)이 개별적으로 MEC 시스템(405)에 정보를 요청하지 않고, 다양한 실시예들에 따른 서비스 인에이블러(414)는 전자 장치(101)의 이동성과 관련된 이벤트가 감지되면 MMP 서버(430) 또는 MEC 호스트(447)에게 MEC 시스템(405)이 제공 가능한 어플리케이션들(예: MEC 어플리케이션들(460-1, 460-2, ...))과 관련된 정보를 요청하거나 수신함으로써 전자 장치(101)의 부하를 줄일 수 있다.
다른 예를 들어, 서비스 인에이블러(414)는 MEC 어플리케이션들(460-1, 460-2, ...) 또는 어플리케이션들(예: 310-1, 310-2, ...) 중 적어도 하나의 어플리케이션이 MEC에 기반한 데이터 전송을 수행할 수 있는 지정된 조건을 만족하는 지를 결정하고, 지정된 조건을 만족하는 적어도 하나의 어플리케이션이 MEC 기반 데이터 전송을 수행하도록 해당 어플리케이션에 알려줄 수 있다(notify). 지정된 조건을 만족하는 적어도 하나의 어플리케이션이 전자 장치(101)에 설치되어 있지 않으면, 서비스 인에이블러(414)는 어플리케이션을 설치하도록 어플리케이션 레이어(446) 및/또는 프레임워크(framework)(예: 미들웨어(144) 및/또는 운영 체제(142))에 가이드 할 수 있다. 예를 들어, 어플리케이션 레이어(446) 및/또는 프레임워크는 서비스 인에이블러(414)의 요청에 따라, 전자 장치(101)에 신규 어플리케이션을 설치하도록 할 수 있다. 다양한 실시예들에서, 전자 장치(101)는 신규 어플리케이션에 대한 정보(예: URI 또는 IP 주소, 어플리케이션 이름)를 MEC 시스템(405)(예: MEC 호스트(447))로부터 수신(또는 획득)할 수 있다.
다른 예를 들어, 서비스 인에이블러(414)는 라이프 사이클 동기화와 관련된 지정된 조건(이하, 제2 조건)이 감지되면, 라이프 사이클 동기화를 MMP 서버(430)(예: LCM 프록시 서버) 또는 엣지 서버(305)(또는 MEC 서버)에게 요청함으로써, 엣지 서버(305)의 자원 소모를 줄일 수 있다. 예를 들어, 서비스 인에이블러(414)는 어플리케이션들(310-1, 310-2, …)의 사용 여부를 MMP 서버(430)로 통지할 수 있다. 일 실시예에 따라, 어플리케이션들(예: 310-1, 310-2, …)이 사용 중일 때만 MEC 어플리케이션들(예: 460-1, 460-2, …)이 동작(예: 데이터 전송)을 수행하고, 어플리케이션들(예: 310-1, 310-2, …)이 미사용 중(예: screen off, 클라이언트 어플리케이션 백그라운드(background) 상태 변경, 사용자 이동 속도가 일정 이상 중 적어도 하나 만족)일 때에는 MEC 어플리케이션들(460-1, 460-2, …)이 동작(예: 데이터 전송)을 중지할 수 있다. 일 실시예에 따르면, 서비스 인에이블러(414)가 상기와 같이 어플리케이션들(310-1, 310-2, …)의 사용 여부를 MMP 서버(430)에 알려줌으로써, MEC 호스트(447)(또는 엣지 서버(305))의 자원을 효율적으로 관리하도록 할 수 있다. 일 실시예에 따라, 미사용 중인 어플리케이션에 대해서는 MEC 어플리케이션의 자원 할당을 해제하여 MEC 호스트(447)의 자원 소모를 줄일 수 있다.
다른 예를 들어, 복수의 어플리케이션들(예: 310-1, 310-2, ...)이 MEC에 기반한 데이터 전송을 위하여 개별적으로 인증 절차를 수행하는 방법과 달리, 서비스 인에이블러(414)는 전자 장치(101)에 대한 인증 절차를 MMP 서버(430)(또는 엣지 서버(305))와 통합적으로 수행함으로써 네트워크 부하를 줄일 수 있다.
도 5는 다양한 실시예들에 따른 네트워크 환경에서 MEC 기반 서비스를 지원하기 위한 전자 장치(101) 및 외부 서버(500)를 도시하는 도면이다.
도 5에 도시한 바와 같이, 도 5의 전자 장치(101)는 MEC AA(MEC Authentication/Authorization) 절차와 MEC 디스커버리(discovery) 절차를 위한 소프트웨어 구조(software architecture)의 일 예를 나타낼 수 있다.
일 실시예에 따라, 전자 장치(101)는 엣지 컴퓨팅 서비스(multi-access edge computing services)(이하, ‘MEC 서비스’라 한다)를 위한 어플리케이션(들)(이하, ‘클라이언트 어플리케이션(client App(application))’이라 한다)(510), 서비스 에이전트(예: MSA)(520)(이하, ‘MSA(520)’이라 한다), 서비스 인에이블러(예: MSE)(530)(이하, ‘MSE(530)’이라 한다)를 포함할 수 있다. 일 실시예에 따라, 전자 장치(101)는 데이터 전송에 관련된 PDU(protocol data unit) 세션(session)의 설정(establishment)을 위한 네트워크 인터페이스(540)(예: 도 1 또는 도 2의 무선 통신 모듈(192))를 포함할 수 있고, 도시되지는 않았으나, 네트워크 인터페이스(540)의 구동을 제어하는 네트워크 드라이버(network driver)(예: 소프트웨어 드라이버)를 포함할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(510), MSA(520), 및 MSE(530)는 전자 장치(101)에 소프트웨어로 탑재되거나 물리적인 구성을 갖도록 구성될 수 있다. 일 실시예에 따르면, MSA(520)와 MSE(530)는 프로세서(예: 도 1의 프로세서(120))의 일부로서 구동될 수 있다. 일 실시예에 따르면, MSA(520)와 MSE(530)는 프로세서(120)와 독립적으로 운용되는 별도의 하드웨어 구성일 수 있다. 다른 실시예에 따르면, MSA(520)와 MSE(540)는 소프트웨어(예: 도 1의 프로그램(140))일 수 있다. 예를 들어, 소프트웨어 형태의 MSA(520)와 MSE(540)는 메모리(예: 도 1 또는 도 2의 메모리(130))에 명령어(또는 인스트럭션(instruction))들의 형태로 저장되고 프로세서(120)에 의해 MSA(520)와 MSE(530)의 동작들이 실행될 수 있다.
일 실시예에 따르면, 클라이언트 어플리케이션(510)은 사용자에 의해 전자 장치(101)에 설치되는 3rd 파티(party) 어플리케이션을 포함할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(510)은 MEC 또는 포그 컴퓨팅)와 같은 MEC 서비스를 사용하는 어플리케이션일 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(510)은 무과금(예: FOC, free of charge) 서비스와 같은 차별화된 서비스를 사용하는 어플리케이션을 포함할 수 있다.
일 실시예에 따라, MEC를 위한 클라이언트 어플리케이션(510)은, MEC 호스트(예: 도 4의 MEC 호스트(447))에서 구동되는 MEC 어플리케이션(예: 도 4의 제1 MEC App(460-1), 제2 MEC App(460-2))에 접속하는 전자 장치(101)의 어플리케이션을 의미할 수 있다. 일 실시예에 따라, MEC 어플리케이션은 사용자에 인접한 MEC 호스트(447)에 설치 및 실행되어 클라이언트 어플리케이션(510)과 통신하는 어플리케이션을 의미할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(510)은 별도의 인증 클라이언트 역할을 하는 MSA(520)(예: 서비스 에이전트)를 통해 인증(authentication)을 받을 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(510)은, 네트워크 인터페이스(540)를 통해, 특정 PDU 세션(예: MEC 전용 PDU 세션(dedicated PDU session))에 기반하여 네트워크에 접속하거나, 또는 MSE(530)(예: 서비스 인에이블러)의 DNS 프록시(proxy) 기능을 통해 기존 PDU 세션(예: default PDU session)으로 MEC 어플리케이션에 접속할 수 있다.
일 실시예에 따라, 무과금 서비스를 위한 클라이언트 어플리케이션(510)은, 데이터 무과금 정책을 적용하는 전자 장치(101)의 어플리케이션을 의미할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(510)은 무과금 인증 담당 MSA(520)를 통해 인증이 되면 CARP(client application routing policy) 또는 URSP(UE route selection policy)를 통해 해당 고유 식별자(UID, unique identifier)에 대한 라우팅 규칙(routing rule)이 등록되고, 해당 UID에서 발생하는 트래픽(traffic)은 무과금 전용 PDU 세션을 통하여 송수신 될 수 있다. 일 실시예에 따라, URSP는 3GPP 표준에 정의된 전자 장치(101)(예: 사용자 단말) 경로 선택(또는 설정) 정책을 나타내며, NAS(non-access stratum) 메시지에 포함되어 AMF로부터 전자 장치(101)의 모뎀(modem)(또는 커뮤니케이션 프로세서(CP, communication processor))을 통해 수신될 수 있다. 일 실시예에 따라, CARP는 다양한 실시예들에서 정의되는 전자 장치(101) 경로 선택(또는 설정) 정책으로서, 예를 들어, 3GPP의 URSP가 가용하지 않는 환경에서 전자 장치(101)의 어플리케이션 레이어(application layer)(예: MSA(520) 또는 MSE(530))를 통해 수신될 수 있다.
일 실시예에 따르면, MSA(520)(예: 서비스 에이전트)는 외부 서버(500)의 AA(Authentication/Authorization) 서버(580)(예: 인증 서버)와 MEC 서비스에 관련된 인증 절차(예: 인증 및 권한 부여(AA, Authentication/Authorization) 절차)를 처리할 수 있다. 예를 들어, MSA(520)는 AA의 결과로 수신한 URSP 규칙 및/또는 MEC 접속 토큰을 MSE(530)로 전달하는 역할을 포함할 수 있다. 일 실시예에 따르면, MSA(520)는 어플리케이션 이벤트(예: 실행(launch), 종료)를 감지하거나, 특정 이벤트를 어플리케이션으로 전달하는 역할을 포함할 수 있다. 다양한 실시예들에 따르면, 전자 장치(101)의 MSA(520)는 AA 클라이언트(525)를 포함할 수 있다. 일 실시예에 따르면, AA 클라이언트(525)는 전자 장치(101)를 생산하는 생산자(또는 제조사) 또는 오퍼레이터(operator)(예: 서비스 사업자)에 의해 제공될 수 있다. 일 실시예에 따르면, MSA(520)는, AA 클라이언트(525)에 기반하여, 전자 장치(101)의 가입자 식별 정보에 기반하여 AA(Authentication/Authorization)를 수행할 수 있다. 가입자 식별 정보는, 예를 들어, SIM(subscriber identity module), USIM(universal SIM), IMEI(international mobile equipment identity), 또는 GPSI(generic public subscription identifier)를 포함할 수 있다. 예를 들어, MSA(520)는 가입자 식별 정보에 기반하여 AA 서버(580)와 통신을 통해 MSE(530)에 의한 서비스(예: MSE 서비스)를 사용하기 위한 인증(Authentication) 및 권한(Authorization) 부여 기능을 제공하는 어플리케이션(또는 소프트웨어)일 수 있다. 일 실시예에 따라, MSE 서비스는, 예를 들어, MSE(530)를 통하여 서비스를 받는 MEC, FOC, MMS, 또는 URLLC(ultra-reliable and low latency communications)와 같은 서비스를 통칭할 수 있다.
일 실시예에 따르면, MSA(520)는 AA 서버(580)와 통신을 통해 MSE 서비스 인증 및 권한 부여를 받으면, 권한 부여된 서비스 타입에 대해 MSE API(application programming interface)를 사용하여 MSE(530)를 활성화/비활성화(enable/disable)(예: MSE 서비스를 활성화/비활성화) 할 수 있으며, 서비스 타입 별 사용 가능한 클라이언트 어플리케이션(510)의 UID 및 규칙(rule)(예: ApnSettings)을 등록하고, 라우팅(routing) 설정을 요청할 수 있다. 일 실시예에 따라, MSE API는 MSE 서비스 타입 별 활성화/비활성화 및 UID 별 라우팅 규칙 설정(routing rule setting)을 위해 전자 장치(101)에서 상위 어플리케이션 레이어로 제공하는 API를 포함할 수 있다. 일 실시예에 따르면, MSE API는 MEC 디스커버리 절차를 위한 정책 또는 컨텍스트(context) 모니터링 정책과 같은 적어도 하나의 정책을 설정하기 위한 API를 포함할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(510)은 MSA(520)와 인증 및 권한 부여 절차를 통해 해당 서비스(예: MEC, FOC)에 접근할 수 있다.
일 실시예에 따라, MSA(520)가 오퍼레이터(예: 서비스 사업자)에 의해 구현되는 경우, 예를 들어, 오퍼레이터가 MSE 서비스를 사용하는 MSA(예: operator MSA)를 직접 개발할 경우, MSA(520)는 AA 서버(580)를 통해 MSE 서비스 사용을 위한 인증 및 권한 부여 절차를 직접 수행할 수 있다. 일 실시예에 따라, MSA(520)는 인증 및 권한 부여 절차에서 AA 서버(580)로부터 어플리케이션 별 라우팅 규칙(routing rule)(예: 전용 PDU 세션 사용시 DNN(data network name(=APN in LTE)) 정보)을 수신할 수 있다. 일 실시예에 따라, MSA(520)가 MSE API 사용을 위해서는 MSA(520)와 전자 장치(101) 간 인증 및 권한 부여 절차를 수행할 수 있다. 예를 들어, 사전에 MSA(520)를 전자 장치(101)에 탑재 시, MSA app APK의 서명(signing)을 통해 플랫폼 키(platform key)로 인증할 수 있다. 일 실시예에 따라, 전자 장치(101)가 인증 모듈을 포함(또는 지원)할 시, MSA(520)의 설치 후 전자 장치(101) 내 인증 모듈과 별도의 인증 절차를 거쳐 MSE API에 대한 사용 권한을 획득하도록 할 수도 있다. 일 실시예에 따라, MSE 서비스 인증 절차가 완료되면, MSA(520)는 수신된 정책을 기반으로 MSE API를 호출하여 PDU 세션의 생성/종료와 라우팅 규칙 설정을 수행할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 MEC 용 어플리케이션의 데이터 경로(data path) 설정 시, MSE(530)의 다양한 엔티티(예: MEC 활성화 레이어(MEL, MEC enabling layer)(531), URSP 핸들링 레이어(UHL, URSP handling layer)(533), 또는 DNS(domain name system) 핸들링 레이어(DHL, DNS handling layer)(535)) 중 적어도 하나의 엔티티를 경유하도록 데이터 경로(예: 경로 ⓐ, 경로 ⓑ, 또는 경로 ⓒ)를 설정할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 용 어플리케이션의 데이터 경로 설정 시, 기본 PDU 세션(default PDU session)을 사용(예: 경로 ⓐ)하거나, 또는 별도의 전용 PDU 세션(dedicated PDU session)을 사용(예: 경로 ⓑ 또는 경로 ⓒ)하는 것에 기반하여 데이터 경로를 다르게 설정할 수 있다. 일 실시예에 따라, 별도의 전용 PDU 세션을 사용하는 경우, MSE(530)의 MEL(531)을 통해 MEC 디스커버리 절차를 수행하는지 여부에 따라 경로 ⓑ 또는 경로 ⓒ의 데이터 경로가 결정될 수 있다.
일 실시예에 따르면, MSA(520)는 MSE(530)의 MEL(531)을 경유하지 않고, MSE(530)의 UHL(533)에 직접 요청하여 전용 PDU 세션(dedicated PDU session)을 구성(예: 서비스의 경로를 경로 ⓒ로 설정)할 수 있다. 예를 들어, 전자 장치(101)에서 스폰서드(sponsored) 어플리케이션 실행 시, 미리 특정한 서버 또는 네트워크와 약속된 경우에, MSA(520)는 UHL(533)에 요청하여 해당하는 서비스를 전용 PDU 세션을 통하여 제공할 수 있다. 일 실시예에 따르면, MSA(520)는 UHL(533)로 서비스를 식별하기 위한 별도의 정보를 더 생성하거나. 또는 외부 서버로부터 수신하여 제공할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 MSA(520)의 하위 레이어에, MSE(530)(예: 서비스 인에이블러)를 포함할 수 있다.
일 실시예에 따르면, MSE(530)는 클라이언트 어플리케이션(510)이 MSA(520)를 통해 MEC 서비스(또는 MSE 서비스) 사용이 가능하도록, MSA(520)에 MSE API를 제공할 수 있으며, 이에 따라 어플리케이션 별 사용 PDU 세션에 대한 라우팅 테이블(routing table)이 설정될 수 있다. 일 실시예에 따르면, MSE(530)는 어플리케이션 ID 별 또는 URI 별 사용할 PDU 세션 경로에 대한 라우팅 테이블을 설정하여, 메모리(예: 도 1 또는 도 2의 메모리(130))에 저장할 수 있다. 일 실시예에 따르면, MSE(530)는 어플리케이션 ID 및 URI 중 적어도 하나에 대해 PDU 세션 경로의 설정 대상으로 설정할 수 있다. URI는 도메인 이름(domain name) 또는 IP 주소 형태를 포함할 수 있다. 일 예로, 어플리케이션 ID 별 PDU 세션 경로 설정은, 예를 들어, “AppID 1: PDU session 1, AppID 2: PDU session1, AppID 3: PDU session 2”와 같이 설정할 수 있다. 일 예로, URI 별 PDU 세션 경로 설정은, 예를 들어, “URI 1: PDU session 1, URI 2: PDU session2”와 같이 설정할 수 있다. 일 예로로, 어플리케이션 ID 별 URI 별 PDU 세션 경로 설정은, 예를 들어, “AppID 1 & URI 1: PDU session 3, AppID 2 & URI 1: PDUsession 1”과 같이 설정할 수 있다.
일 실시예에 따라, MEC 서비스는 MEC 어플리케이션(또는 ME(mobile edge) 어플리케이션)을 사용하기 위해 필요한 절차, MEC 어플리케이션을 통하여 제공받는 서비스, 및 MEC 어플리케이션에 제공하는 정보 관련 서비스를 통칭할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 서비스를 위해서, MEC 서비스 디스커버리(service discovery), 위치 확인(location verification), 라우트 선택(route selection), 성능 확인(performance verification), 또는 이동성 지원(mobility support)의 추가적인 기능을 지원할 수 있다.
다양한 실시예들에 따르면, MSE(530)는 적어도 하나의 MEC 호스트(예: 도 4의 MEC 호스트(447))(또는 MEC 어플리케이션)와 연결된 상태에서, 특정한 서비스를 제공하기 위해 전용 PDU 세션으로 구성하도록 하거나, 또는 기본 PDU 세션으로 구성하도록 할 수 있다. 일 실시예에 따르면, 전용 PDU 세션 또는 기본 PDU 세션의 구성에 필요한 정보는, 예를 들어, 전자 장치(101)의 모뎀(또는 CP, communication processor)에서, AMF/PCF 서버(590)로부터 NAS(non-access stratum) 정보(information)를 통해 수신할 수 있다.
일 실시예에 따르면, MSE(530)는 MEL(531), UHL(533), 및 DHL(535)를 포함할 수 있다.
일 실시예에 따라, MEL(531)은 MSE 서비스 중 MEC 서비스 사용을 위해 필요한 작업을 수행할 수 있다. 예를 들면, MEL(531)은 MEC 서비스 등록(MEC service registration), MEC 서비스 디스커버리(MEC service discovery), 라우트 선택(route selection)(예: DNN handling), 성능 사전 측정(performance pre-measurement), 위치 서비스(location services), 및/또는 이동성 핸들링(mobility handling)의 동작을 처리할 수 있다.
일 실시예에 따라, MEC 서비스 등록은, 전자 장치(101)의 USIM 또는 어카운트(Account)(예: 로그-인(log-in)) 정보에 기반하여 MMP 서버(430)(또는 LCM 프록시 서버) 또는 MEC 솔루션 제공 서버(solution provider server)로부터 MEC 서비스 가입 여부를 인증 받고, MEC 서비스 권한 레벨(level)에 맞는 토큰(token)(예: Cookie)을 수신하여 메모리(예: 도 1 또는 도 2의 메모리(130))에 저장할 수 있다. 이후의 MEC 서비스는 토큰이 유효한 시간 동안 해당 토큰을 사용하여 서비스 요청을 수행할 수 있다.
일 실시예에 따라, MEC 서비스 디스커버리는, 전자 장치(101)가 MEC 서비스가 가능한 영역에 들어왔을 때(예: 특정 셀(cell) ID 접속 또는 LADN 영역 진입), MEL(531)이 이를 감지하여, 해당 지역에서 사용 가능한 앱 리스트(예: MEC App (name) list) 또는 도메인 이름(domain name)(예: MEC 어플리케이션 별 도메인 이름) 중 적어도 하나를 수신하고, 사용자 설정에 따라 다양한 기능을 수행할 수 있다. 예를 들어, MEL(531)은, 사용자 설정에 따라 가용 MEC 어플리케이션 알림, DNS 프록싱(proxying), 및/또는 MEC 어플리케이션 활성화를 제공할 수 있다. 일 실시예에 따라, MEL(531)은 가용 MEC 어플리케이션에 대해 알림을 제공할 수 있다. 예를 들어, 현재 사용 가능한 MEC 어플리케이션을 알림 창 또는 어플리케이션 아이콘(예: 앱 아이콘)에 표시할 수 있다. 일 실시예에 따라, 전자 장치(101) 상에 해당 MEC 어플리케이션에 대응되는 클라이언트 어플리케이션의 설치를 알림할 수도 있다.
일 실시예에 따라, MEL(531)은 DNS 프록싱(proxying)을 제공할 수 있다. 예를 들어, 클라이언트 어플리케이션이 MEC 어플리케이션에 접속하기 위하여 해당 도메인 이름(domain name)에 대한 DNS 쿼리(query) 발생 시, 해당 어플리케이션 이름(application name) 또는 DNS 쿼리 중 적어도 하나가 MEC 앱 리스트에 매칭(matching)이 될 경우, MEL(531)은 해당 DNS 쿼리를 MEC 용 DNS 서버에 전송하여, 해당 MEC 어플리케이션에 대한 접속 IP 주소를 받아오고, 이를 클라이언트 어플리케이션(510)에 리턴(return)할 수 있다. 일 실시예에 따라, 해당 IP 주소는, 예를 들어, 유효 기간 동안 전자 장치(101) 내 MEC 용 DNS 캐시에 저장할 수 있다. MEC 앱 리스트 상의 도메인 이름에 대한 MEC DNS 리졸빙(resolving)은 클라이언트 어플리케이션의 DNS 쿼리와 별도로 MEL(531)이 자체적으로 수행하여 MEC 용 DNS 캐시에 저장할 수 있다.
일 실시예에 따라, MEL(531)은 MEC 어플리케이션 활성화를 제공할 수 있다. 예를 들어, 전자 장치(101)에 설치된 MEC 클라이언트 어플리케이션이 사용 중이거나 또는 사용이 예상될 경우, 이와 연동하는 MEC 어플리케이션 활성화(예: 인스턴스 생성(instantiation))을 요청할 수 있다. 일 실시예에 따르면, 해당 MEC 어플리케이션이 전자 장치(101)의 접속 지역 MEC 호스트에 설치되어 있지 않을 경우, 설치를 요청(예: 패키지(package) URI 포함)할 수 있다.
일 실시예에 따라, 라우트 선택(예: DNN handling)은, 기본 PDU 세션을 사용하지 않고, MEC 서비스 또는 MEC 어플리케이션을 위한 전용 PDU 세션의 사용을 원할 경우, 클라이언트 어플리케이션의 UID에 대한 라우팅 규칙(routing rule)을 설정할 수 있다. 일 실시예에 따르면, MSE(530)가 MEC 서비스 또는 MEC 어플리케이션을 위한 전용 DNN 정보를 미리 정의된 프로필(predefined profile) 또는 AA 서버(580)로부터 수신하고, UHL API(미도시)를 사용하여 MEC 전용 PDU 세션의 생성을 요청할 수 있다.
일 실시예에 따라, 성능 사전 측정은, 예를 들어, MEL(531)이 복수의 후보(candidate) MEC 호스트들에 대해 사전 성능 테스트하는 것을 포함할 수 있다. 예를 들어, MEL(531)은 사전 성능(예: ping probing, bandwidth estimation) 테스트를 통해 최적 MEC 호스트를 선택할 수 있다.
일 실시예에 따라, 위치 서비스는, 예를 들어, 전자 장치(101)가 위치된 지역에 기반하여 서비스를 제공하는 것을 포함할 수 있다. 일 실시예에 따르면, MEL(531)은 전자 장치(101)의 해당 위치에서의 서비스 가용성(service availability)(또는 location accuracy)에 관한 정보를 제공할 수 있다. 일 예로, 서비스 가용성에 관한 정보는, 예를 들면, 서비스 가능 지역(location confirmed), 해당 서비스 없음(location not found), 또는 서비스 불가 지역(location spoofed)과 같은 정보를 포함할 수 있다.
일 실시예에 따라, 이동성 핸들링은, 예를 들어, 핸드오버가 발생하는 영역에서의 서비스 연속성(service continuity)을 위한 핸들링을 제공할 수 있다. 예를 들어, MEL(531)은 MEC 호스트에서 다른 MEC 호스트로 핸드오버 또는 MEC 호스트에서 리모트 호스트(remote host)로 핸드오버를 처리할 수 있다.
일 실시예에 따르면, MEL(531)은 MMP 서버(예: 도 4의 MMP 서버(430))와의 통신을 통해 MEC 호스트(예: 도 4의 MEC 호스트(447))의 MEC 어플리케이션의 디스커버리(discovery)을 위한 제어 및 서비스의 종류를 식별할 수 있다. 예를 들어, MEL(531)은 미리 정의된 MSE API 호출에 의해 서비스를 식별할 수 있다. 다른 예를 들어, MEL(531)은 사업자 서버(예: AA 서버(580)) 또는 MMP 서버(430)로부터 수신한 정책에 따라 서비스를 식별할 수 있다.
일 실시예에 따르면, MEL(531)은 서비스의 식별 결과, 예를 들어, 기본 PDU 세션을 사용하는 서비스인 경우 DHL(535)를 경유하는 서비스의 경로(예: 경로 ⓐ)를 설정하고, 이에 따라 MEL(531) 및 DHL(535)에 의해 MEC 서비스를 제공할 수 있다. 일 실시예에 따르면, MEC 용 어플리케이션을 위한 데이터 경로 ⓐ의 경우, MEL(531)이 기본 PDU 세션을 통하여 서비스가 제공되도록 구성할 수 있다. 다른 실시예에 따르면, MEL(531)은 서비스의 식별 결과, 예를 들어, 전용 PDU 세션을 사용하는 서비스인 경우 MEL(531), UHL(533), 및 DHL(535)를 경유하는 서비스의 경로(예: 경로 ⓑ)를 설정하고, 해당 서비스를 MEL(531), UHL(533), 및 DHL(535)에 의해 제공할 수 있다. 일 실시예에 따르면, MEC 용 어플리케이션을 위한 데이터 경로 ⓑ의 경우 MEL(531)이 UHL(533)에 요청하여 전용 PDU 세션을 통하여 서비스가 제공되도록 구성할 수 있다. 일 실시예에 따르면, 전술한 다양한 서비스를 식별하기 위하여 MSA(520)가 MEL(531)로 별도의 정보를 더 제공하거나 MEL(531)이 MMP 서버(430)로부터 관련 정보를 수신(또는 획득)하도록 할 수 있다.
일 실시예에 따라, UHL(533)은 API 호출에 따라 서비스 타입 별 전용 PDU 세션을 요청하고, 해당 어플리케이션에 대해 설정된 전용 PDU 세션으로 바인딩(binding) 할 수 있다.
일 실시예에 따라, DHL(535)은 3rd 파티 어플리케이션에 DNS 사전 리졸빙(pre-resolving) 또는 DNS 프록시 기능을 지원할 수 있다. 예를 들어, 기존 기본 PDU 세션을 통해 데이터 연결이 된 상태에서 MEC 용 클라이언트 어플리케이션이 특정 서비스 접속을 위한 DNS 쿼리를 발생하면, DNS 프록시가 DNS 쿼리를 가로채서, MEC 용 도메인 이름으로 DNS 서버에 쿼리를 전달하거나, 또는 DNS 캐시에서 룩업(lookup)하여 해당 MEC 도메인 IP 주소를 반환할 수 있다. 이를 통해, 3rd 파티 어플리케이션이 별도의 소프트웨어 수정 없이, 그리고 오퍼레이터의 별도 트래픽 필터링(traffic filtering)(또는 steering) 작업 없이 MEC 서비스를 제공할 수 있다.
일 실시예에 따라, AA 서버(580)는 MSE 서비스 사용을 위한 인증 및 권한 부여를 제공할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 AA 서버(580)를 통해 인증 및 가입자 정보에 따라 서비스 타입 별 권한을 부여 받을 수 있다. 일 실시예에 따르면, MSA(520)는 MSE 서비스 사용 가능 클라이언트 어플리케이션을 인증할 수도 있다. 일 실시예에 따르면, AA 서버(580)와 전자 장치(101)의 MSA(520) 간의 인증 절차는 별도 PDU 세션을 통하지 않고, 예를 들어, LTE 또는 Wi-Fi와 같은 통신을 통해 현재 인터넷(internet)에 연결된 기본 PDU 세션을 사용할 수 있다.
일 실시예에 따라, MMP 서버(430)는 전자 장치(101)의 인증 또는 MEC 제어를 위해 전자 장치(101)와 통신하는 프록시 서버를 의미할 수 있다. 일 실시예에 따르면, MMP 서버(430)는, 예를 들어, HTTP(hypertext transfer protocol)에 기반하여 요청/응답(request/response) 메시지 교환을 수행할 수 있다. 일 실시예에 따라, 전자 장치(101)가 AA 서버(580) 또는 MEC 솔루션 제공 서버와 직접 통신 가능할 경우, LCM 프록시는 필요하지 않을 수 있다. 예를 들어, LCM 프록시가 제공하는 서버 API를 사용하는 경우, MSA(520)의 인증 요청 메시지는 AA 서버(580)로 포워딩(forwarding) 되어 인증을 수행하고, MEC 제어 메시지는 MEC 솔루션 제공 서버로 전달될 수 있다. 다양한 실시예들에서, MSA(520)와 MMP 서버(430) 또는 인타이틀먼트 서버(entitlement server) 간 연동 API는 생략할 수 있으며, AA 절차(예: 인증 및 권한 부여 절차)에서 필요한 정보는 미리 수신될 수 있다.
일 실시예에 따라, AMF(access and mobility function)/PCF(policy control function) 서버(590)는, 예를 들어, 5G NR(new radio) 표준에서 MEC 지원 시, PCF에 MMP 정보 및 URPS 규칙(rule)이 등록되고, NAS 시그널링(signaling)을 통해 AMF로부터 해당 정보를 수신할 수 있다.
이상에서와 같이, 다양한 실시예들에 따르면, MSA(520)는 AA 서버(580)와 통신하여 인증을 수행하고 원하는 정보(예: 인증 및 권한 부여)를 요청할 수 있고, 요청한 정보를 AA 서버(580)로부터 수신하여 획득할 수 있다. 다양한 실시예들에 따르면, MSE(530)는 MMP 서버(530)와 통신하여 원하는 정보를 요청할 수 있고, 요청한 정보를 MMP 서버(530)로부터 수신하여 획득할 수 있다. 예를 들어, MSE(530)는 MMP 서버(430)와 통신하여 MEC 앱 리스트를 획득하거나, 또는 MEC 서비스 디스커버리 절차를 수행하고, 특정한 적어도 하나의 MEC 호스트(또는 MEC 어플리케이션)과 연결을 설정할 수 있다.
다양한 실시예들에 따르면, 도 4 및 도 5를 참조한 설명 부분에서 설명한 바와 같이 MSA(520)와 MSE(530)를 포함하는 전자 장치(101)에 기반하여, MEC 용 어플리케이션의 데이터 경로 설정 시, 다음과 같이 다양한 서비스 시나리오를 제공할 수 있다.
1. 제1 데이터 경로(예: 경로 ⓐ)의 시나리오(예: MSE on Single PDU Session)
일 실시예에 따른 제1 데이터 경로(예: 경로 ⓐ)의 시나리오는, 클라이언트 어플리케이션이 기존 인터넷 데이터(internet data)를 위해 사용 중인 기본 PDU 세션(또는 PDN(public data network) 연결)을 사용하여 MEC 어플리케이션에 연결하는 시나리오를 나타낼 수 있다. 일 실시예에 따르면, MEL(531)에서 MEC 디스커버리 절차를 수행하여, 전자 장치(101)에 가까운 MEC 호스트에 MEC 어플리케이션 구동 및 연결을 요청하고, 해당 MEC 어플리케이션의 URI를 수신할 수 있다. 클라이언트 어플리케이션(510)이 해당 MEC 어플리케이션 접속 요청 시, 해당 URI에 대한 DNS 리졸빙(resolving)을 통해 획득한 MEC 어플리케이션 IP 주소로 접속을 수행할 수 있다. 일 실시예에 따라, 제1 데이터 경로의 시나리오(예: MSE on Single PDU Session)에서는 MEC 서비스를 위한 별도의 PDU 세션을 사용하지 않으므로, 동작 상에 URSP 규칙을 제어하는 UHL(533)은 개입하지 않을 수 있다.
2. 제2 데이터 경로(예: 경로 ⓑ)의 시나리오 B(예: MSE on Multiple PDU Sessions with MEL)
일 실시예에 따른 제2 데이터 경로(예: 경로 ⓑ)의 시나리오는, 클라이언트 어플리케이션이 기존 인터넷 용 기본 PDU 세션(또는 PDN 연결) 외에, 별도의 MEC 전용 PDU 세션을 생성하여 MEC 어플리케이션에 연결하는 시나리오를 나타낼 수 있다. 일 실시예에 따라, MEC 전용 PDU 세션 생성은 사업자(예: MNO(mobile network operator) 또는 MMP 서버(430)) 정책에 따르며, MSA(520) 또는 인증된 클라이언트 어플리케이션(510)이 MSE API를 사용하여 UHL(533)을 통해 생성할 수 있다. 일 실시예에 따라, MEC 전용 PDU 세션은 기본 PDU 세션 외에 하나 이상의 PDU 세션을 항상 열어둘 수도 있고, 특정 시점에 필요에 따라 MEL(531)의 요청에 의해 동적으로 생성하거나 해제할 수 있다. 일 실시예에 따르면, 사전에 정의된 규칙(rule)(예: CARP 또는 URSP 규칙) 또는 외부 서버(예: MMP 서버(430), AA 서버(580), 또는 AMF/PCF 서버(590))로부터 수신한 라우팅 규칙(routing rule)에 따라 해당 클라이언트 어플리케이션(또는 UID) 또는 접속 URI에 대한 트래픽(traffic)을 MEC 전용 PDU 세션으로 라우팅(routing) 되도록 MSE(530)의 UHL(533)에서 지원할 수 있다.
3. 제3 데이터 경로(예: 경로 ⓒ)의 시나리오(예: MSE on Multiple PDU Sessions without MEL)
일 실시예에 따른 제3 데이터 경로의 시나리오는, MEL(531)의 기능 없이, 특정 서비스에 대해 전용 PDU 세션만 생성하여 사용하는 시나리오를 나타낼 수 있다. 일 실시예에 따르면, MSA(520) 또는 인증된 클라이언트 어플리케이션(510)에 MSE API를 사용하여 별도의 전용 PDU 세션을 생성하고, 해당 PDU 세션을 사용하는 어플리케이션(예: UID) 규칙을 등록하고, 해당 어플리케이션의 트래픽을 해당 PDU Session으로 라우팅 되도록 할 수 있다. 일 실시예에 따르면, 제3 데이터 경로의 시나리오(예: MSE on Multiple PDU Sessions without MEL)와 같은 방식의 경우, MEC 뿐만 아니라 전용 PDU 세션이 필요한 다양한 타입의 서비스(예: FOC, MMS, 또는 URLLC)에서 활용될 수도 있다.
본 발명의 다양한 실시예들에 따른 전자 장치(101)는, 네트워크 인터페이스(420), 및 프로세서(120)를 포함하고, 상기 프로세서(120)는, 상기 네트워크 인터페이스를 이용하여, 기지국 내에 또는 상기 기지국을 통하여 연결 가능한 적어도 하나의 외부 서버로, 상기 적어도 하나의 외부 서버가 제공 가능한 어플리케이션들에 관한 정보를 획득하고, 상기 어플리케이션들에 관한 정보에 기반하여, 지정된 조건에 대응하는 어플리케이션을 포함하는 외부 서버를 선택하고, 상기 선택된 외부 서버와 데이터 전송을 수행할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 어플리케이션들에 관한 정보를 요청하는 요청 메시지를 상기 적어도 하나의 외부 서버로 전송하고, 상기 적어도 하나의 외부 서버로부터 상기 어플리케이션들에 관한 정보를 포함하는 응답 메시지를 수신하고, 상기 응답 메시지로부터 상기 어플리케이션들에 관한 정보를 획득할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 요청 메시지에 상기 어플리케이션들에 관한 정보의 조건을 지정하여 상기 적어도 하나의 외부 서버로 전송할 수 있다.
다양한 실시예들에 따르면, 상기 요청 메시지는, clientappName, locationInfo, deviceType, serviceType, contextType, 또는 URI Request 중 적어도 하나를 포함할 수 있다.
다양한 실시예들에 따르면, 상기 응답 메시지는, referenceURI, clientAppName, clientAppPackageURL, uriTTL, uriLOC, carpRule, DNN, S-NSSAI, accessType, sessionType, mptcp, 또는 fqdnList 중 적어도 하나를 포함할 수 있다.
본 발명의 다양한 실시예들에 따른 전자 장치(101)는, 네트워크 인터페이스(420), 및 프로세서(120)를 포함하고, 상기 프로세서(120)는, 디스커버리 정책에 기반하여, 지정된 외부 서버로부터 서비스 가능한 어플리케이션의 앱 리스트를 획득하고, 상기 앱 리스트에 기반하여 상기 전자 장치의 클라이언트 어플리케이션과 연관되고 접속하고자 하는 어플리케이션에 관련된 정보를 상기 지정된 외부 서버로부터 획득하고, 상기 획득된 정보에 기반하여, 데이터 전송을 위한 호스트를 결정하고, 상기 호스트와 데이터 전송을 수행할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 외부 서버와 통신하여 인증 및 권한 부여와 관련된 동작을 수행하는 서비스 에이전트(service agent), 상기 외부 서버와 통신하여 앱 리스트를 획득하고, 디스커버리(discovery)와 관련된 동작을 수행하는 서비스 인에이블러(service enabler)를 포함할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 서비스 에이전트와 상기 서비스 인에이블러 사이의 API를 통해 상기 서비스 인에이블러를 활성화 하고, 상기 서비스 인에이블러를 통해 상기 외부 서버와 디스커버리 절차를 수행할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 서비스 에이전트에서 상기 서비스 인에이블러로 상기 디스커버리 정책을 설정하는 것을 포함하고, 상기 디스커버리 정책은 클라이언트 어플리케이션 이름(clientAppName) 및 디스커버리 정책(discoveryPolicy)을 포함하고, 상기 디스커버리 정책(discoveryPolicy)은 동적 DNN(dynamicDnn)의 사용 여부, 위치 정보(locationInfo), 디바이스 타입(deviceType), 서비스 타입(serviceType), 또는 컨텍스트 타입(contextType) 중 적어도 하나를 포함할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 서비스 에이전트로부터 상기 디스커버리 정책 수신에 기반하여 상기 서비스 인에이블러를 활성화 하고, 상시 서비스 인에이블러를 통해 상기 디스커버리 정책에 따라 지정된 조건을 만족하는 앱 리스트를 프록시 서버로 요청하도록 할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 앱 리스트에 상기 클라이언트 어플리케이션과 연관되는 어플리케이션이 없는 경우, 상기 서비스 인에이블러를 통해 프록시 서버로 상기 어플리케이션의 URI를 요청하고, 상기 앱 리스트에 상기 클라이언트 어플리케이션과 연관되는 어플리케이션이 있는 경우, 상기 어플리케이션의 어플리케이션 이름을 포함하여 상기 프록시 서버로 전송할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 프록시 서버에 상기 어플리케이션이 없을 경우 상기 프록시 서버로부터 상기 어플리케이션의 다운로드 또는 설치를 위한 어플리케이션 패키지(package) URI을 획득할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 서비스 인에이블러를 통해 상기 어플리케이션에 대한 URI로 DNS 쿼리(query)를 수행하고, 상기 DNS 쿼리에 대응하는 DNS 응답으로 획득된 IP 주소를 로컬 DNS 캐시(cache)에 저장하도록 할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 외부 서버로부터 복수의 호스트에 대한 후보 IP 리스트(candidate IP list)가 수신되는 경우, 추가 정보에 기반하여 상기 호스트를 선택하도록 설정되고, 상기 추가 정보는, 호스트 위치, 사용자 현재 위치, 사용자 속도, 또는 호스트 성능(performance)에 관한 정보를 포함할 수 있다.
본 발명의 다양한 실시예들에 따른 전자 장치(101)는, 네트워크 인터페이스(420), 및 프로세서(120)를 포함하고, 상기 프로세서(120)는, 디스커버리 정책에 기반하여, 지정된 외부 서버로부터 서비스 가능한 어플리케이션의 앱 리스트를 획득하고, 클라이언트 어플리케이션에 의한 컨텍스트 생성과 관련된 이벤트에 기반하여, 상기 클라이언트 어플리케이션과 연관되고 접속하고자 하는 어플리케이션에 관련된 정보를 상기 지정된 외부 서버로부터 획득하고, 상기 획득된 정보에 기반하여, 데이터 전송을 위한 호스트를 선택하고, 상기 호스트와 데이터 전송을 수행할 수 있다.
다양한 실시예들에 따르면, 상기 컨텍스트 생성과 관련된 이벤트는, 상기 클라이언트 어플리케이션의 실행, 상기 클라이언트 어플리케이션에 의한 컨텍스트 생성 요청, 또는 상기 클라이언트 어플리케이션에 의한 DNS 쿼리 발생 중 적어도 하나를 포함할 수 있다.
다양한 실시예들에 따르면, 상기 디스커버리 정책은, 상기 디스커버리 정책은 클라이언트 어플리케이션 이름(clientAppName) 및 디스커버리 정책(discoveryPolicy)을 포함하고, 상기 디스커버리 정책(discoveryPolicy)은 동적 DNN(dynamicDnn)의 사용 여부, 위치 정보(locationInfo), 디바이스 타입(deviceType), 서비스 타입(serviceType), 또는 컨텍스트 타입(contextType) 중 적어도 하나를 포함할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 디스커버리 정책에 따라 지정된 조건을 만족하는 앱 리스트를 프록시 서버로 요청하도록 할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 앱 리스트에 상기 클라이언트 어플리케이션과 연관되는 어플리케이션이 없는 경우, 상기 프록시 서버로 상기 어플리케이션의 URI를 요청하고, 상기 앱 리스트에 상기 클라이언트 어플리케이션과 연관되는 어플리케이션이 있는 경우, 상기 어플리케이션의 어플리케이션 이름을 포함하여 상기 프록시 서버로 전송하고, 상기 프록시 서버에 상기 어플리케이션이 없을 경우 상기 프록시 서버로부터 상기 어플리케이션의 다운로드 또는 설치를 위한 어플리케이션 패키지(package) URI을 획득하도록 할 수 있다.
다양한 실시예들에 따르면, 상기 프로세서(120)는, 상기 어플리케이션에 대한 URI로 DNS 쿼리(query)를 수행하고, 상기 DNS 쿼리에 대응하는 DNS 응답으로 획득된 IP 주소를 로컬 DNS 캐시(cache)에 저장하도록 할 수 있다.
이하에서는 다양한 실시예들의 전자 장치(101)의 동작 방법에 대하여 설명한다. 예를 들어, 이하에서는 MSA(520)와 MSE(530)를 포함하는 전자 장치(101)에 기반하여 다양한 실시예들에 따른 인증 및 권한 부여(예: AA(authentication/authorization)) 및 정책(policy)(예: app routing policy, discovery policy, 또는 monitoring policy)을 수신하고, 수신된 정책에 기반한 라우트(route) 설정 및 MEC 디스커버리 절차를 수행하는 다양한 동작들에 대하여 설명한다.
이하에서 설명하는 전자 장치(101)에서 수행하는 동작들은, 전자 장치(101)의 적어도 하나의 프로세서(예: 프로세싱 회로를 포함하는 적어도 하나의 프로세서로서, 예를 들면, 도 1의 프로세서서(120))(이하, ‘프로세서(120)’라 한다)에 의해 실행될 수 있다. 일 실시예에 따라, 전자 장치(101)에서 수행하는 동작들은, 메모리(예: 도 1의 메모리(130))(이하, ‘메모리(130)’라 한다)에 저장되고, 실행 시에, 프로세서(120)가 동작하도록 하는 인스트럭션들(instructions)에 의해 실행될 수 있다.
도 6은 다양한 실시예들에 따른 MEC 서비스를 지원하기 위한 인증 및 디스커버리 절차를 설명하기 위해 도시하는 도면이다.
다양한 실시예들에 따라, 도 6에서는 MEC 서비스를 위한 어플리케이션들의 인증(예: authentication & authorization) 및 디스커버리(discovery) 절차를 수행하기 위한 신호 흐름도의 예를 도시한다. 일 실시예에 따라, 도 6에서는 전자 장치(101)가 MEC 시스템(405)과 신호(또는 데이터)를 교환하는 예를 도시하였지만, 전자 장치(101)는 AN(302)을 통해 MEC 시스템(405)에 포함되는 구성 요소(예: 도 5의 AA 서버(580), MMP 서버(430), 및/또는 AMF/PCF 서버(590))와 신호를 교환할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 도 4 및 도 5를 참조한 설명 부분에서 설명한 바와 같은 클라이언트 어플리케이션(510), MSA(520)(또는 서비스 에이전트), 및 MSE(530)(또는 서비스 인에이블러)를 포함할 수 있다. 일 실시예에 따르면, MEC 시스템(405)은 도 4 및 도 5를 참조한 설명 부분에서 설명한 바와 같은 MEC 시스템(405)에 대응할 수 있으며, AA 서버(580), MMP 서버(430), 및/또는 AMF/PCF 서버(590)를 포함할 수 있다.
도 6을 참조하면, 동작 610에서, 전자 장치(101)의 MSA(520)는 MEC 시스템(405)과 인증(예: MEC 인증) 절차를 수행할 수 있다. 일 실시예에 따라, 인증 절차는 AA 절차로, 예를 들면, 인증(authentication) 및/또는 권한(authorization) 부여 절차를 포함할 수 있다. 일 실시예에 따르면, 인증(authentication) 절차는 MEC 서비스가 이용 가능한지를 확인하기 위한(또는 사용자를 판별하기 위한) 일련의 동작을 포함할 수 있고, 권한(authorization) 부여 절차는 MEC 서비스 레벨(예: QoS 또는 자원량)을 확인하기 위한 일련의 동작을 포함할 수 있다. 다양한 실시예들에 따르면, MSA(520)는 MMP 서버(430) 또는 AA 서버(580)와 최초 접속을 하여 사용자(또는 가입자) 인증(authentication)을 수행하고, MMP 서버(430) 또는 AA 서버(580)로부터 MMP 정보(MMP Info(information))와 권한(authorization) 부여에 필요한 정보, 트래픽 경로, 또는 PDU 세션 설정을 위한 CARP 또는 URSP 규칙(rule)과 같은 제어 데이터를 수신할 수 있다. 일 실시예에 따르면, MSA(520)는 제어 데이터를 수신하는 것에 기반하여, 해당 MMP 서버(430)에 접속하여 인증 절차를 수행할 수 있다. 일 실시예에 따르면, MSA(520)는 인증 절차를 수행하는 결과에 따라, MEC 시스템(405)(예: MMP 서버(430))로부터 MEC 시스템(405)에 접속(access)하기 위한 인증 정보(예: 접속 토큰(MAT, MEC access token))를 획득(또는 수신)할 수 있다. 접속 토큰(MAT)은 어플리케이션이 MEC 시스템(405)으로부터 서비스를 제공받기 위하여 요구되는 키(key)를 포함할 수 있다. 다양한 실시예들에 따른, 인증 절차에 관한 설명은 후술하는 도면들을 참조하여 상세히 설명된다.
다양한 실시예들에 따르면, 인증과 권한 부여는, 예를 들어, 전자 장치(101) 및/또는 사용자에 대한 인증을 포함할 수 있다. 예를 들어, 전자 장치(101)는 MSA(520)를 통해 전자 장치(101)(예: 사용자 단말) 또는 가입자에 대한 인증을 수행하고, 인증이 완료되면 해당 전자 장치(101)의 클라이언트 어플리케이션(510)은 MEC 서비스를 위한 접속이 허용될 수 있다. 이러한 경우, 클라이언트 어플리케이션(510)은 내부적으로 MSA(520)로부터 인증(authentication) 받은(또는 인증된) 어플리케이션일 수 있고, 클라이언트 어플리케이션(510)에게 별도의 접속 토큰(예: MAT)을 제공하는 동작이 생략될 수 있다.
일 실시예에 따라, 도 6에서는 도시하지 않았으나, 전자 장치(101)(예: MSA(520)는 전자 장치(101)에 설치된 복수의 어플리케이션들 중 MEC에 기반한 데이터 전송을 수행할 수 있는 클라이언트 어플리케이션(510)에 대한 인증 절차를 수행할 수 있다. 일 실시예에 따르면, 인증 절차는 OAuth 표준에 기반하여 수행할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는 MEC 시스템(405)과 협약된 화이트 리스트 또는 별도의 외부 서버(또는 제3 서버)(미도시)에서 수신한 화이트 리스트와 전자 장치(101)에 설치된 클라이언트 어플리케이션(510)의 정보(예: 어플리케이션 패키지 이름)를 비교하는 방식을 통해 인증 절차를 수행할 수도 있다. 일 실시예에 따라, 전자 장치(101)는 인증 절차가 완료되면, 인증된 클라이언트 어플리케이션(510)에게 접속 토큰을 제공할 수 있다. 일 실시예에 따라, 접속 토큰은 인증을 통해 해당 접속 토큰을 사용하는 접속 요청에 대해 허용하기 위해 사용되는 토큰일 수 있다. 예를 들어, 해당 토큰을 사용하지 않는 미인증 요청은 서비스 제공을 제한할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션에 대한 인증 절차는 생략할 수도 있고, 동작 610 보다 먼저 수행할 수도 있다.
동작 620에서, 전자 장치(101)의 MSE(530)는 MEC 시스템(405)과 디스커버리(예: MEC service discovery) 절차를 수행할 수 있다. 다양한 실시예들에 따르면, MSE(530)는 수신된 인증 정보(예: MAT)를 사용하여, 전자 장치(101)에 가장 가까이 위치하거나, 또는 최적의 MEC 어플리케이션에 접속하기 위한 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, 디스커버리 절차는 MEC 시스템(405)에서 제공 가능한 어플리케이션(들)(예: 도 4의 MEC 어플리케이션(들)( 460-1, 460-2))을 확인(또는 발견(discovery))하는 일련의 절차를 포함할 수 있다. 다양한 실시예들에 따른, 디스커버리 절차에 관한 설명은 후술하는 도면들을 참조하여 상세히 설명된다. 일 실시예에 따르면, 전자 장치(101)는 다양한 실시예들에 따른 인증 절차(예: 동작 610)를 수행하고, 상기 인증 절차에 이어서, 후술하는 바와 같은 다양한 실시예들에 따른 디스커버리 절차를 수행할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는, 예를 들면, ETSI(European telecommunication standards institute)의 MEC 규격에 정의되어 있는 동작(예: application lookup, context create/delete)을 위한 메시지 교환 방식을 참조하여 수행할 수도 있다.
동작 630에서, 전자 장치(101)는 디스커버리 절차 이후 MEC 시스템(405)과 데이터 전송을 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 클라이언트 어플리케이션(510)은 접속하고자 하는 MEC 호스트(예: 엣지 서버 또는 MEC 서버)의 URI로부터 DNS 리졸빙(resolving)을 수행하여, 전자 장치(101)에 가장 가까운 MEC 호스트의 IP 주소를 획득(또는 수신)하여 최적 MEC 어플리케이션에 접속할 수 있다. 다양한 실시예들에 따르면, 클라이언트 어플리케이션(510)은 제공된 접속 토큰에 기반하여 MEC 시스템(405)과 추가적인 인증 절차를 수행하지 않고, 데이터 전송을 수행할 수 있다. 도 6에서는 하나의 클라이언트 어플리케이션(510)이 데이터 전송을 수행하는 실시예를 도시하였지만, 복수의 어플리케이션들이 데이터 전송을 수행하는 경우, 복수의 어플리케이션들은 개별적으로 MEC 시스템(405)과 인증 절차를 수행할 필요 없이, MSA(520)를 통해 획득된 접속 토큰(MAT)을 통해 데이터 전송을 수행할 수 있으므로 네트워크 부하가 감소할 수 있다.
MEC 인증 절차
도 7은 다양한 실시예들에 따른 전자 장치(101)의 동작 방법을 도시하는 흐름도이다.
다양한 실시예들에서, 도 7에 도시된 동작들은, 예를 들어, 전자 장치(101) 또는 전자 장치(101)에 포함된 구성 요소(예: 도 1의 프로세서(120), 도 4의 MEC 서비스 모듈(410))에 의하여 수행될 수 있다.
도 7을 참조하면, 동작 701에서, 전자 장치(101)는 전자 장치(101)의 이동성과 관련된 이벤트를 감지할 수 있다. 예를 들어, 전자 장치(101)는 컨텍스트 정보(예: 어플리케이션에 관한 정보, 이동성과 관련된 정보, 어플리케이션의 라이프 사이클 정보, 전자 장치(101)의 상태에 관한 정보, 센서 정보, 또는 네트워크 성능 정보)를 모니터링 할 수 있고, 모니터링 하는 결과에 기반하여 이동성과 관련된 정보(예: 전자 장치(101)의 움직임을 나타내는 정보, 전자 장치(101)와 연결된 기지국의 변경과 관련된 정보, 또는 전자 장치(101)가 지정된 영역에 진입하는 지와 관련된 정보)를 획득(또는 확인)하는 것에 기반하여 이동성과 관련된 이벤트를 식별할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 동작 701을 수행할 수도 있고, 생략할 수도 있다.
동작 703에서, 전자 장치(101)는 MEC 서비스 모듈(410)(예: MSA(520))을 이용하여 MEC 시스템(405)과 인증 절차를 수행할 수 있다. 예를 들어, 전자 장치(101)는 전자 장치(101)가 지정된 지역에 진입함을 감지한 것에 응답하여 인증 절차를 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 후술하는 다양한 실시예들에 따른 인증 절차에 따라서 인증 절차를 수행할 수 있고, MEC 시스템(405)(예: AA 서버(580), MMP 서버(430))로부터 접근 토큰(예: MAT)을 획득할 수 있다.
동작 705에서, 전자 장치(101)는 MEC 서비스 모듈(410)과 MEC 시스템(405) 간 수행된 인증 절차에 기반하여 적어도 하나의 어플리케이션에 대한 데이터 전송을 수행할 수 있다.
이하, 다양한 실시예들에 따른 MEC 인증 절차에 대하여 살펴보기로 한다. 다양한 실시예들에 따르면, 서비스 제공 형태(또는 모델)에 기반하여 다양한 인증 시나리오(scenario)(예: 시나리오 A, 시나리오 B, 시나리오 C)를 제공할 수 있다.
다양한 실시예들에서는 3가지의 인증 시나리오를 개시하지만, 이는 다양한 실시예들의 기술 내용을 쉽게 설명하고 본 개시의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 개시의 범위를 한정하고자 하는 것은 아니다. 따라서 다양한 실시예들의 범위는 여기에 개시된 실시예들 이외에도 본 개시의 기술적 사상을 바탕으로 도출되는 모든 변경 또는 변형된 형태가 본 개시의 범위에 포함되는 것으로 해석되어야 한다.
도 8은 다양한 실시예들에 따른 전자 장치(101)에서 인증 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 8을 참조하면, 동작 801에서, 전자 장치(101)의 프로세서(120)(또는 도 5의 MSA(520))는 인증 서버(예: 도 5의 AA 서버(580))에 제1 인증(예: authentication)을 위한 제1 요청 메시지를 전송할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 지정된 적어도 하나의 인증 방식에 기반하여 인증 요청(authentication request)을 위한 메시지를 AA 서버(580)로 전송할 수 있다. 일 실시예에 따르면, MSA(520)는 AA 서버(580)와 GPSI(generic public subscription identifier) 기반 Application-layer AKA 방식, ID/password 기반 Login 방식, 또는 GBA 방식을 이용하여 인증을 요청할 수 있다.
동작 803에서, 프로세서(120)는 인증 서버로부터 인증 결과에 따른 제1 인증 정보를 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 AA 서버(580)와 인증을 수행할 수 있고, 인증 결과에 따른 인증 정보를 AA 서버(580)로부터 획득(또는 수신)할 수 있다. 인증 정보는, 예를 들어, MMP 관련 정보(이하, ‘MMP Info’라 한다) 및 권한 부여 코드(Authorization code)(이하, ‘Auth Code’라 한다)를 포함할 수 있다. 일 실시예에 따라, 인증 정보는 상기의 정보 외에, 추가적으로(또는 선택적으로) 필요한 정보, 예를 들어, 인증을 위한 식별 토큰(예: ID_token) 또는 MEC 데이터 서비스를 위한 CARP 또는 URSP 규칙(rules) 중 적어도 하나를 더 포함할 수 있다. 일 실시예에 따라, MMP Info는, 예를 들어, MMP 서버(430) 접속에 관련된 정보(예: MMP 접속 주소)를 포함할 수 있다. 예를 들어, MMP Info는 접속할 새로운 MMP 서버(430)의 주소 정보(예: URI(uniform resource identifier) 또는 IP 주소)와 해당 주소 정보의 유효 시간 및/또는 장소에 관련된 정보를 포함할 수 있다. 일 실시예에 따라, Auth Code는, 예를 들어, MMP 서버(430)로부터 접속 토큰(예: MAT)을 요청하는 데 필요한 코드(예: OAuth2.0 기반)를 포함할 수 있다. 일 실시예에 따라, CARP 또는 URSP 규칙은, 예를 들어, DNN 구성(configuration) 관련 정보, DNN 별 사용 가능한 어플리케이션(또는 어플리케이션 그룹)에 관련된 정보, 또는 이후 설정 가능한 DNN 리스트(list) 또는 설정 가능한 DNN 최대 개수에 관련된 정보를 포함할 수 있다.
동작 805에서, 프로세서(120)는 클라이언트 어플리케이션을 위한 PDU 세션(예: MEC 용 전용 PDU 세션)을 설정(setup)(예: 정책 업데이트)할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 CARP 규칙 또는 URSP 규칙(예: DNN)에 따라 MSE(530)를 통해 PDU 세션을 설정할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 인증 절차가 완료되면, MSE(530)와 정책 업데이트(policy update)를 수행(예: PDU 세션 설정)할 수 있다. 일 실시예에 따르면, MSA(520)는 기본 PDU 세션을 변경하거나, 새로운 전용 PDU 세션을 추가로 설정할 수 있다. 일 실시예에 따르면, 동작 807의 정책 업데이트를 위한 PDU 세션 설정 동작은, 예를 들어, MSA(520)가 AA 서버(580)로부터 CARP 또는 URSP 규칙이 제공되는 경우 수행할 수 있다. 일 실시예에 따라, MSA(520)는 CARP 또는 URSP 규칙(예: DNN)에 따라 초기 PDU 세션 설정을 수행할 수 있다. 일 실시예에 따르면, MSA(520)는 MMP 서버(430)로부터 수신 정보에 URSP 규칙이 있는 경우, MSE API를 이용하여 URSP 규칙을 업데이트 할 수 있다.
동작 807에서, 프로세서(120)는 제1 인증 정보에 기반하여, MMP 서버(430)로 제2 인증(예: authorization, 권한 부여)을 위한 제2 요청 메시지를 전송할 수 있다. 일 실시예에 따라, 제2 인증(예: authorization)은 서비스 사용에 대한 권한 요청 및 권한 요청에 따른 권한 부여(예: 접속 토큰(access token) 발행)를 획득하기 위한 절차를 포함할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 인증 완료 후(또는 MSE(530)와 정책 업데이트 수행 또는 생략한 이후), 권한 부여(authorization) 요청(authorization request)을 위한 메시지를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따르면, MSA(520)는 AA 서버(580)로부터 획득된 인증 정보(예: Auth Code 또는 추가적으로 식별 토큰(ID_token) 포함)에 기반하여, MMP 서버(430)에 인증을 요청할 수 있다.
동작 809에서, 프로세서(120)는 MMP 서버(430)로부터 인증 결과에 따른 제2 인증 정보를 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 MMP 서버(430)를 통해 AA 서버(580)와 권한 부여 절차를 수행할 수 있고, 인증 결과에 따른 인증 정보를 MMP 서버(430)로부터 획득(또는 수신)할 수 있다. 인증 정보는, 예를 들어, 접속 토큰(예: MAT)과 MMP Info를 포함할 수 있다.
동작 811에서, 프로세서(120)는 제2 인증 정보에 기반하여 해당 MMP 서버(430)에 접속하여 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 MMP 서버(430)로부터, 인증 결과에 따른 인증 정보(예: MAT)를 수신하는 경우, 수신된 인증 정보를 전자 장치(101)의 MSE(530)에 전달하고, MSE(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 인증 정보와 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(430)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE API를 통해 MSE(530)로 전달할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 인증 정보(예: MAT) 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP Info 및 MAT를 사용하여 해당 MMP 서버(430)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, 프로세서(120)는 제2 인증 정보에 새로운 MMP 서버(430)에 관련된 MMP Info가 포함되어 있지 않은 경우, 제1 인증 정보에 포함된 MMP Info에 기반하여 MEC 디스커버리 절차를 수행할 수도 있다.
다양한 실시예들에 따르면, 도 8에 도시된 인증 절차는, 예를 들어, 클라이언트 어플리케이션(510)이 기본 PDU 세션(또는 PDN)을 사용하여 MEC 어플리케이션에 연결하는 시나리오를 포함할 수 있다. 예를 들어, MSE(530)(예: MEL(531))에서 MEC 디스커버리 절차를 수행하여, 전자 장치(101)에 가까운 MEC 호스트에 MEC 어플리케이션 구동 및 연결을 요청하고, 해당 MEC 어플리케이션의 URI를 수신할 수 있다. 이후, 클라이언트 어플리케이션(510)이 해당 MEC 어플리케이션 접속 요청 시, 해당 URI에 대한 DNS 리졸빙을 통해 획득한 MEC 어플리케이션 IP 주소로 접속할 수 있다.
다양한 실시예들에 따르면, 도 8에 도시된 인증 절차는, 예를 들어, 클라이언트 어플리케이션이 기본 PDU 세션(또는 PDN) 외에, 별도의 MEC 전용 PDU 세션을 생성하여 MEC 어플리케이션에 연결하는 시나리오를 포함할 수 있다. 예를 들어, MEC 전용 PDU 세션 생성은 사업자(예: MNO 또는 MMP 서버(430)) 정책에 따르며, MSA(520) 또는 인증된 클라이언트 어플리케이션이 MSE API를 사용하여 UHL(533)을 통해 생성 할 수 있다. 일 실시예에 따라, MEC 전용 PDU 세션은 기본 PDU 세션 외에, 하나 이상의 PDU 세션을 항상 열어둘 수도 있고, 특정 시점에 필요에 따라 MEL(531)의 요청에 의해 동적으로 생성하거나 해제할 수 있다. 일 실시예에 따르면, 사전에 정의된 규칙(rule)(예: CARP 또는 URSP 규칙) 또는 외부 서버(예: MMP 서버(430), AA 서버(580), 또는 AMF/PCF 서버(590))로부터 수신한 라우팅 규칙에 따라 해당 클라이언트 어플리케이션(또는 UID) 또는 접속 URI에 대한 트래픽을 MEC 전용 PDU 세션으로 라우팅 되도록 MSE(530)의 UHL(533)에서 지원할 수 있다.
다양한 실시예들에 따르면, 도 8에 도시된 인증 절차는, 예를 들어, 특정 서비스에 대해 전용 PDU 세션만 생성하여 사용하는 시나리오를 포함할 수 있다. 일 실시예에 따르면, MSA(520) 또는 인증된 클라이언트 어플리케이션(510)에 MSE API를 사용하여 별도의 전용 PDU 세션을 생성하고, 해당 PDU 세션을 사용하는 어플리케이션(예: UID) 규칙을 등록하고, 해당 어플리케이션의 트래픽을 해당 PDU 세션으로 라우팅 되도록 할 수 있다.
도 9는 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 9에 도시한 바와 같이, 전자 장치(101)는 MSA(또는 서비스 에이전트)(520)(예: AA 클라이언트(525) 포함)와 MSE(또는 서비스 인에이블러)(530)(예: MEL(531), UHL(533) 포함)를 포함할 수 있다.
도 9을 참조하면, 동작 901에서, 전자 장치(101)의 MSA(520)는 지정된 적어도 하나의 인증 방식(예: 제1 인증)에 기반하여 인증(예: 제1 인증) 요청(authentication request)을 위한 메시지(예: 제1 요청 메시지)를 AA 서버(580)에 전송할 수 있다. 일 실시예에 따르면, MSA(520)는 AA 서버(580)와 GPSI(generic public subscription identifier) 기반 Application-layer AKA 방식, ID/password 기반 Login 방식, 또는 GBA 방식을 이용하여 인증을 요청할 수 있다.
동작 903에서, MSA(520)는 AA 서버(580)와 인증을 수행할 수 있다. 일 실시예에 따라, MSA(520)는 AA 서버(580)와 GPSI 기반 사용자 인증(user authentication)을 수행할 수 있다.
동작 905에서, AA 서버(580)는 전자 장치(101)로부터 인증 요청을 수신하는 경우, 전자 장치(101)와 인증을 수행하고, 인증을 완료(예: 인증 절차 완료)하는 경우, 인증 결과에 따른 인증 정보(예: 제1 인증 정보)를 전자 장치(101)(예: MSA(520))에 제공(또는 전송)할 수 있다. 일 실시예에 따르면, 인증 정보는, 예를 들어, MMP 관련 정보(이하, ‘MMP Info’라 한다) 및 권한 부여 코드(Authorization code)(이하, ‘Auth Code’라 한다)를 포함할 수 있다. 일 실시예에 따라, MMP 서버(430)는 상기의 정보 외에, 추가적으로(또는 선택적으로) 필요한 정보, 예를 들어, 인증을 위한 ID_token 또는 MEC 데이터 서비스를 위한 CARP 또는 URSP 규칙(rules) 중 적어도 하나를 인증 정보에 더 포함하여 제공할 수 있다.
일 실시예에 따라, MMP Info는, 예를 들어, MMP 서버(430) 접속에 관련된 정보(예: MMP 접속 주소)를 포함할 수 있다. 예를 들어, MMP Info는 접속할 새로운 MMP 서버(430)의 주소 정보(예: URI(uniform resource identifier) 또는 IP 주소)와 해당 주소 정보의 유효 시간 및/또는 장소에 관련된 정보를 포함할 수 있다. 일 실시예에 따라, Auth Code는, 예를 들어, MMP 서버(430)로부터 접속 토큰(예: MAT, MEC access token))을 요청하는 데 필요한 코드(예: OAuth2.0 기반)를 포함할 수 있다. 일 실시예에 따라, CARP 또는 URSP 규칙은, 예를 들어, PDU 세션 설정(PDU session setup)을 위한 관련 정보(예: DNN), DNN 별 사용 가능한 어플리케이션(또는 어플리케이션 그룹)에 관련된 정보, 또는 이후 설정 가능한 DNN 리스트(list) 또는 설정 가능한 DNN 최대 개수에 관련된 정보를 포함할 수 있다.
동작 907에서, MSA(520)는 AA 서버(580)와 인증 절차가 완료되면, MSE(530)와 정책 업데이트(policy update)를 수행(예: PDU 세션 설정(PDU session setup))할 수 있다. 일 실시예에 따라, MSA(520)는 CARP 규칙 또는 URSP 규칙(예: DNN)에 따라 PDU 세션 설정을 수행할 수 있다. 예를 들어, MSA(520)는 CARP 규칙 또는 URSP 규칙에 따라 PDU 세션 설정 수행 여부에 대한 정책을 식별할 수 있고, CARP 규칙 또는 URSP 규칙에 따라 MSE API를 통해 PDU 세션 설정 요청을 MSE(530)로 전달할 수 있다. MSE(530)는 MSA(520)의 PDU 세션 설정 요청에 대응하여, PDU 세션 설정을 수행할 수 있다. 일 실시예에 따르면, MSA(520)는 기본 PDU 세션을 변경하거나, 새로운 전용 PDU 세션을 추가로 형성(establishment)할 수 있다.
일 실시예에 따르면, 동작 907의 MSA(520)와 MSE(530)의 정책 업데이트 동작은, 예를 들어, MSA(520)가 AA 서버(580)로부터 CARP 또는 URSP 규칙(rule)이 제공되는 경우 수행할 수 있다. 일 실시예에 따르면, MSA(520)는 AA 서버(580)로부터 CARP 또는 URSP 규칙이 제공되지 않는 경우 MSE(530)와 정책 업데이트를 수행하지 않을 수도 있다. 다른 실시예에 따르면, MSA(520)는 AA 서버(580)로부터 CARP 또는 URSP 규칙이 제공되더라도 MSA(520)의 자체적인 판단 또는 MSE(530)와의 정보 교환을 통해 정책 업데이트를 수행하지 않을 수도 있다.
동작 909에서, MSA(520)는 인증 완료 후(또는 MSE(530)와 정책 업데이트 수행 또는 생략한 이후), 권한 부여(authorization)(예: 제2 인증) 요청(authorization request)을 위한 메시지(예: 제2 요청 메시지)를 MMP 서버(430)에 전송할 수 있다. 일 실시예에 따르면, MSA(520)는 AA 서버(580)로부터 획득된 인증 정보(예: Auth Code 또는 추가적으로 ID_token 포함)에 기반하여, MMP 서버(430)에 인증을 요청할 수 있다.
동작 911에서, MSA(520)는 MMP 서버(430)를 통해 AA 서버(580)와 인증(예: 권한 부여 절차)을 수행할 수 있다. 일 실시예에 따라, MSA(520)는 AA 서버(580)와 Auth Code에 기반하여 서비스 사용에 대한 권한 부여(service authorization)을 수행할 수 있다.
동작 913에서, MMP 서버(430)는 MSA(520)의 인증 요청(예: 제2 요청 메시지)에 대응하여, 인증 결과에 따른 인증 정보(예: 제2 인증 정보)를 전자 장치(101)(예: MSA(520))에 제공(또는 전송)할 수 있다. 일 실시예에 따르면, 인증 정보는, 예를 들어, 접속 토큰(예: MAT, MEC access Token)과 MMP Info를 포함할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 MSA(520)의 인증 수행 중 또는 수행 이후에 접속 토큰을 포함하는 응답을 MSA(520)에 전송할 수 있다.
동작 915에서, MSA(520)는 MSE(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 AA 서버(580)와 인증 수행 중 또는 수행 후에, MMP 서버(430)로부터, 인증 결과에 따른 인증 정보(예: 접속 토큰(MAT))를 수신하는 경우, 수신된 인증 정보(예: 접속 토큰(MAT))를 MSE(530)에 전달하여 MSE(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 인증 정보(예: 접속 토큰(MAT))와 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(430)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE(530)에 전달할 수 있다. 일 실시예에 따르면, MSA(520)는 수신된 접속 토큰(MAT) 및/또는 그 외의 다른 부가 정보에 기반하여 MSE(530)를 활성화(enable MEC)할 수 있다. 일 실시예에 따르면, MSA(520)가 MMP 서버(430)와 인증(예: 권한 부여)을 수행하는 경우, MSA(520)는 MMP 서버(430)로부터, 인증 결과로 접속 토큰(예: MAT)을 수신할 수 있으며, 예를 들어, MSE API의 enableMecEnablingLayer(true, MMP Info, MAT)를 호출함으로써, MSE(530)에 MMP 접속 정보(MMP Info) 및 접속 토큰(MAT)을 전달할 수 있다.
동작 917에서, MSE(530)는 인증 정보(예: MAT) 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)을 수신하고, 인증 정보 및/또는 부가 정보에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP Info 및 MAT를 사용하여 해당 MMP 서버(430)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다.
도 9에서는 도시하지 않았으나, 다른 실시예에 따르면, MSE(530)가 MMP 서버(430)와 인증(예: 동작 911의 service authorization)을 수행할 수 있다. 일 실시예에 따르면, MSE(530)가 MMP 서버(580)와 인증(예: 권한 부여)을 수행하는 경우, 우선 인증을 완료한 MSA(520)가 MMP 서버(430)로부터, 인증 결과로 MMP Info와 Auth Code 및/또는 그 외의 다른 부가 정보(예: 식별 토큰(ID_token))을 수신할 수 있으며, 예를 들어, MSE(530) 활성화를 위해, MSE API의 enableMecEnablingLayer(true, MMP Info, Auth Code, [ID-Token])를 호출함으로써, MSE(530)에 전달할 수 있다. MSE(530)는 MSA(520)로부터 전달받은 정보로부터 MMP 서버(430)와 직접 권한 부여(Authorization)을 수행하고, 그 결과로 MAT를 수신(또는 획득)할 수 있다. 예를 들면, 도 9의 동작과 대비할 때, 전자 장치(101)의 내부 구성 중 권한 부여를 위한 서비스 인증 절차를 수행하는 주체가 MSA(520)인 경우와 MSE(530)인 경우로 구분될 수 있다.
도 10은 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 10에 도시한 바와 같이, 도 10은 다양한 실시예들에 따른 인증 절차(예: AA(authentication/authorization) 및 정책 업데이트(policy update)에 관한 시나리오 A)를 위한 신호 흐름의 예를 나타낼 수 있다. 예를 들어, 도 10은 다양한 실시예들에 따른 인증 절차 중 시나리오 A를 위한 MEC 서비스 인증 플로우의 예를 나타낸 것으로, 도 9에 따른 동작 901, 동작 903, 및 동작 905에 대응하는 “User Authentication(또는 Subscriber Authentication)”의 상세 실시예에 따른 동작(예: 동작 1010)과 도 9에 따른 동작 909, 동작 911, 및 동작 913에 대응하는 “MEC Service Authorization”의 상세 실시예에 따른 동작(예: 동작 1020)을 포함할 수 있다. 일 실시예에 따르면, MEC AA 및 정책 업데이트를 위한 시나리오 A는, 도 10에 도시한 바와 같이, User Authentication(예: 동작 1010) 이후에 MEC Service Authorization(예: 동작 1020)를 수행하는 시나리오 예를 나타낼 수 있다.
도 10을 참조하면, 동작 1001에서, 전자 장치(101)의 MSA(520)는 인증 요청을 위한 메시지를 인타이틀먼트(entitlement) 서버(1000)로 전송할 수 있다.
동작 1003에서, 인타이틀먼트 서버(1000)는 인증 방식(authentication method)을 결정할 수 있다. 일 실시예에 따르면, 인타이틀먼트 서버(1000)는 지정된 적어도 하나의 인증 방식에서 전자 장치(101)의 인증 요청에 대응하는 인증 방식을 결정할 수 있다. 일 실시예에 따라, 적어도 하나의 인증 방식은, 예를 들어, GPSI를 이용한 Application-layer AKA 또는 Login(예: ID/password) 방식의 인증(authentication)을 포함할 수 있다. 일 실시예에 따르면, MSA(520)가 가입자 식별 정보(또는 단말 식별 정보)(예: GPSI 또는 IMSI)를 인타이틀먼트 서버(1000)에 전달하면서 권한 코드를 요청할 수 있다. 일 실시예에 따라, MSA(520)와 인타이틀먼트 서버(1000)는, 동작 1010에서와 같이, Application-layer AKA 또는 Loging 방식으로 사용자 인증(user authentication)을 수행할 수 있다.
일 실시예에 따르면, 동작 1005에서, MSA(520)는 인타이틀먼트 서버(1000)를 통해 AA 서버(580) 간에 Application-layer AKA 방식에 기반하여 인증(authentication)(예: MEC 가입자 인증) 절차를 수행하고, AA 서버(580)로부터 인증 결과에 따른 인증 정보를 포함하는 인증 응답(authentication response)을 획득할 수 있다. 다른 실시예에 따르면, 동작 1007에서, MSA(520)는 인타이틀먼트 서버(1000)와 ID/password 기반 Login 방식에 기반하여 인증(authentication) 절차를 수행하고, 동작 1009에서, 인타이틀먼트 서버(1000)에 로그인 성공(Login Success)에 기반하여 인타이틀먼트 서버(1000)로부터 인증 결과에 따른 인증 정보를 포함하는 인증 응답을 획득할 수 있다.
동작 1011에서, MSA(520)는 인증 요청에 대응하는 인증 응답(authentication response)을 수신할 수 있다. 예를 들어, 동작 1011에서, MSA(520)는 인타이틀먼트 서버(1000) 또는 인타이틀먼트 서버(1000)를 통해 AA 서버(580)로부터 인증 결과에 따른 인증 정보(예: MMP Info, Auth Code, ID_token, CARP 규칙, 또는 URSP 규칙)를 획득할 수 있다. 예를 들어, MSA(520)는 인증 결과로 MEC 디스커버리 절차를 수행할 MMP 관련 정보(예: MMP 접속 주소)와 권한 부여(authorization)를 위한 권한 코드(예: Auth code) 및 ID_token을 수신할 수 있다. 일 실시예에 따르면, MSA(520)는, AA 서버(580)의 지원 여부에 기반하여, MEC 데이터 서비스를 위한 CARP 또는 URSP 규칙에 관련된 정보를 수신할 수도 있다.
일 실시예에 따르면, MSA(520)는, 동작 1010에서와 같은 “User Authentication” 이후, 동작 1020에서와 같이 “MEC Service Authorization”을 수행할 수 있다.
일 실시예에 따르면, 동작 1013에서, MSA(520)는 인증 완료 후, 권한 부여(authorization) 요청(authorization request)을 위한 메시지를 MMP 서버(430)로 전송할 수 있다. 예를 들어, MSA(520)는 획득된 인증 정보(예: Auth Code 또는 추가적으로 ID_token 포함)를 MMP 서버(430)로 전달하여 MMP 서버(430)에 권한 부여를 요청할 수 있다. 예를 들어, MSA(520)는 인증 완료 후, MMP 접속 주소를 이용하여 MMP 서버(430)에 접속하여 권한 부여(authorization) 절차를 수행할 수 있다.
동작 1015에서, MMP 서버(430)는 인타이틀먼트 서버(1000)에 접속 토큰(access token)을 요청할 수 있고, 동작 1017에서, 인타이틀먼트 서버(1000)로부터 접속 토큰을 획득할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 인타이틀먼트 서버(1000)와 통신 또는 인타이틀먼트 서버(1000)를 통해 AA 서버(580)와 통신하여, 전자 장치(101)가 MEC 서비스 가입자인지 여부를 확인할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 AA 서버(580)를 통해 MEC 서비스 가입자임을 확인하면, MSA(520)에 접속 토큰(예: MAT)을 발행(예: 권한 부여(authorization))할 수 있다.
동작 1019에서, MMP 서버(430)는 MMP 정보와 권한 코드를 인타이틀먼트 서버(1000)(또는 AA 서버(580))에 전달하며, 사용자 프로필(user profile) 정보 접근을 위한 접속 토큰을 요청하여 획득할 수 있다.
동작 1021에서, MMP 서버(430)는 권한 부여 요청에 대응하는 권한 부여 응답(authorization response)을 MSA(520)로 전송할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 해당 접속 토큰을 이용하여 사용자 프로필을 확인하고, 사용자 프로필에 기반하여 MEC 서비스가 가용하다는 것이 확인된 경우 MSA(520)에 MMP Info, MAT, 또는 CARP 규칙을 포함하여 Authorization response를 전달할 수 있다.
일 실시예에 따르면, 동작 1021에서, MSA(520)는 권한 부여 절차의 결과로 접속 토큰(예: MAT)을 획득할 수 있다. 일 실시예에 따라, MSA(520)가 MMP 서버(430)와 권한 부여 절차를 수행하는 경우, MSA(520)는 권한 부여 절차의 결과로 접속 토큰을 수신하며, MSE API를 통해 MSE(530)로 MMP 정보 및 접속 토큰을 전달할 수 있다. 다른 실시예에 따라, MSE(530)가 MMP 서버(430)와 권한 부여 절차를 수행하는 경우, 우선 인증을 완료한 MSA(520)가 인타이틀먼트 서버(1000)로부터 수신한 MMP 정보 및 권한 코드(Auth code)와, 선택적으로 ID_token을 MSE API를 통해 MSE(530)로 전달할 수 있다. MSE(530)는 MSA(520)로부터 전달된 정보에 기반하여 MMP 서버(430)와 직접 권한 부여 절차를 수행하고 그 결과로 접속 토큰을 수신할 수 있다.
동작 1023에서, MSA(520)는 MSE(530)를 통해, MMP Info 및 접속 토큰을 이용하여 MEC 디스커버리 절차를 수행할 수 있다.
도 11은 다양한 실시예들에 따른 전자 장치(101)에서 인증 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 11을 참조하면, 동작 1101에서, 전자 장치(101)의 프로세서(120)(또는 도 5의 MSA(520))는 MMP 서버(430)로 인증을 위한 요청 메시지를 전송할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 지정된 적어도 하나의 인증 방식에 기반하여 서비스 사용을 위한 권한 부여 요청(authorization request)을 위한 메시지(예: 권한 요청 메시지)를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따르면, MSA(520)는 MMP 서버(430)에 서비스 사용에 대한 권한 부여를 요청할 때, MNO 정보와 장치 식별자(Device ID)(예: IMSI, IMEI, GPSI, 또는 별도 할당된 고유 식별자) 중 적어도 하나 또는 모두를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따라, Device ID는 MMP 서버(430)가 전자 장치(101)를 고유하게(unique)하게 식별 가능한 식별자(예: UID)를 포함할 수 있다.
동작 1103에서, 프로세서(120)는 MMP 서버(430)로부터 인증 결과에 따른 인증 정보를 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 MMP 서버(430)와 인증(예: AA, authentication & authorization)을 수행할 수 있고, 인증 결과에 따른 인증 정보를 MMP 서버(430)로부터 획득할 수 있다. 인증 정보는, 예를 들어, MMP Info와 접속 토큰(예: MAT)을 포함할 수 있다. 일 실시예에 따라, 인증 정보는 상기의 정보 외에, 추가적으로(또는 선택적으로) 필요한 정보, 예를 들어, MEC 데이터 서비스를 위한 CARP 또는 URSP 규칙(rules) 중 적어도 하나를 더 포함할 수 있다. 일 실시예에 따라, MMP Info는, 예를 들어, MMP 서버(430) 접속에 관련된 정보(예: MMP 접속 주소)를 포함할 수 있다. 예를 들어, MMP Info는 접속할 새로운 MMP 서버(430)의 주소 정보(예: URI 또는 IP 주소)와 해당 주소 정보의 유효 시간 및/또는 장소에 관련된 정보를 포함할 수 있다. 일 실시예에 따라, 접속 토큰(예: MAT)은, 예를 들어, MEC 디스커버리 권한 확인용 접속 토큰을 포함할 수 있다. 일 실시예에 따라, CARP 또는 URSP 규칙은, 예를 들어, DNN 구성(configuration) 관련 정보, DNN 별 사용 가능한 어플리케이션(또는 어플리케이션 그룹)에 관련된 정보, 또는 이후 설정 가능한 DNN 리스트(list) 또는 설정 가능한 DNN 최대 개수에 관련된 정보를 포함할 수 있다.
동작 1105에서, 프로세서(120)는 클라이언트 어플리케이션을 위한 PDU 세션(예: MEC 용 전용 PDU 세션)을 설정(setup)할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 인증 절차가 완료되면, MSE(530)와 정책 업데이트(policy update)를 수행(예: PDU 세션 설정)할 수 있다. 일 실시예에 따라, MSA(520)는 CARP 또는 URSP 규칙(예: DNN)에 따라 초기 PDU 세션 설정을 수행할 수 있다. 일 실시예에 따르면, MSA(520)는 MMP 서버(430)로부터 수신 정보에 URSP 규칙이 있는 경우, MSE API를 이용하여 URSP 규칙을 업데이트 할 수 있다.
동작 1107에서, 프로세서(120)는 인증 정보에 기반하여 해당 MMP 서버(430)에 접속하여 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 MMP 서버(430)로부터, 인증 결과에 따른 인증 정보(예: MAT)를 수신하는 경우, 수신된 인증 정보를 전자 장치(101)의 MSE(530)에 전달하고, MSE(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 인증 정보와 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(430)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE API를 통해 MSE(530)로 전달할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 인증 정보(예: MAT) 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP Info 및 MAT를 사용하여 해당 MMP 서버(430)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다.
다양한 실시예들에 따르면, 도 11에 도시된 인증 절차는, 예를 들어, 클라이언트 어플리케이션(510)이 기본 PDU 세션(또는 PDN)을 사용하여 MEC 어플리케이션에 연결하는 시나리오를 포함할 수 있다. 예를 들어, MSE(530)(예: MEL(531))에서 MEC 디스커버리 절차를 수행하여, 전자 장치(101)에 가까운 MEC 호스트에 MEC 어플리케이션 구동 및 연결을 요청하고, 해당 MEC 어플리케이션의 URI를 수신할 수 있다. 이후, 클라이언트 어플리케이션(510)이 해당 MEC 어플리케이션 접속 요청 시, 해당 URI에 대한 DNS 리졸빙을 통해 획득한 MEC 어플리케이션 IP 주소로 접속할 수 있다.
다양한 실시예들에 따르면, 도 11에 도시된 인증 절차는, 예를 들어, 클라이언트 어플리케이션이 기본 PDU 세션(또는 PDN) 외에, 별도의 MEC 전용 PDU 세션을 생성하여 MEC 어플리케이션에 연결하는 시나리오를 포함할 수 있다. 예를 들어, MEC 전용 PDU 세션 생성은 사업자(예: MNO 또는 MMP 서버(430)) 정책에 따르며, MSA(520) 또는 인증된 클라이언트 어플리케이션이 MSE API를 사용하여 UHL(533)을 통해 생성 할 수 있다. 일 실시예에 따라, MEC 전용 PDU 세션은 기본 PDU 세션 외에, 하나 이상의 PDU 세션을 항상 열어둘 수도 있고, 특정 시점에 필요에 따라 MEL(531)의 요청에 의해 동적으로 생성하거나 해제할 수 있다. 일 실시예에 따르면, 사전에 정의된 규칙(rule)(예: CARP 또는 URSP 규칙) 또는 외부 서버(예: MMP 서버(430), AA 서버(580), 또는 AMF/PCF 서버(590))로부터 수신한 라우팅 규칙에 따라 해당 클라이언트 어플리케이션(또는 UID) 또는 접속 URI에 대한 트래픽을 MEC 전용 PDU 세션으로 라우팅 되도록 MSE(530)의 UHL(533)에서 지원할 수 있다.
다양한 실시예들에 따르면, 도 11에 도시된 인증 절차는, 예를 들어, MEL(531)의 기능 없이, 특정 서비스에 대해 전용 PDU 세션만 생성하여 사용하는 시나리오를 포함할 수 있다. 일 실시예에 따르면, MSA(520) 또는 인증된 클라이언트 어플리케이션(510)에 MSE API를 사용하여 별도의 전용 PDU 세션을 생성하고, 해당 PDU 세션을 사용하는 어플리케이션(예: UID) 규칙을 등록하고, 해당 어플리케이션의 트래픽을 해당 PDU 세션으로 라우팅 되도록 할 수 있다.
도 12는 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 12에 도시한 바와 같이, 전자 장치(101)는 MSA(또는 서비스 에이전트)(520)(예: AA 클라이언트(525) 포함)와 MSE(또는 서비스 인에이블러)(530)(예: MEL(531), UHL(533) 포함)를 포함할 수 있다.
도 12를 참조하면, 동작 1201에서, 전자 장치(101)의 MSA(520)는 지정된 적어도 하나의 인증 방식에 기반하여 서비스 사용을 위한 권한 부여 요청(authorization request)을 위한 메시지(예: 권한 요청 메시지)를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따르면, MSA(520)는 MMP 서버(430)에 서비스 사용에 대한 권한 부여를 요청할 때, MNO(mobile network operator)(예: 인타이틀먼트 서버(1000)) 정보와 Device ID(예: IMSI, IMEI, GPSI, 또는 별도 할당된 고유 식별자) 중 적어도 하나 또는 모두를 MMP 서버(430)로 제공(또는 전송)할 수 있다. 일 실시예에 따라, Device ID는 MMP 서버(430)가 전자 장치(101)를 고유하게(unique)하게 식별 가능한 식별자를 포함할 수 있다.
동작 1203에서, MSA(520)는 MMP 서버(430) 또는 MMP 서버(430)를 통해 AA 서버(580)와 인증 및 권한 부여(예: AA, authentication & authorization) 절차를 수행할 수 있다. 예를 들어, MSA(520)는 MMP 서버(430)로 권한 부여 요청(authorization request)을 전달하면, MSA(520), MMP 서버(430), 및 AA 서버(580)의 3자 간 메시지 교환(예: 후술하는 도 13 참조)을 수행할 수 있다. 일 실시예에 따라, MSA(520)는 MMP 서버(430)와 사용자 인증(user authentication)과 서비스 인증(service authorization)(또는 권한 부여)을 수행할 수 있다. 예를 들어, MSA(520)는 전자 장치(101)가 등록되어 있는 사용자인지를 식별하는 절차를 수행하고, 해당하는 서비스를 제공받을 수 있는지를 식별하는 절차를 수행할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 MNO 정보에 따라 AA 방식이 다를 수 있으므로, MNO 정보에 따라 그에 맞는 방식을 사용하여 AA를 수행할 수 있다.
동작 1205에서, MMP 서버(430)는 전자 장치(101)로부터 인증 요청을 수신하는 경우, 전자 장치(101)와 인증을 수행하고, 인증을 완료(예: 인증 절차 완료)하는 경우, 인증 결과에 따른 인증 정보를 전자 장치(101)(예: MSA(520))에 제공(또는 전송)할 수 있다. 일 실시예에 따르면, 인증 정보는, 예를 들어, MMP Info와 접속 토큰(예: MAT)을 포함할 수 있다. 일 실시예에 따라, MMP 서버(430)는 상기의 정보 외에, 추가적으로(또는 선택적으로) 필요한 정보, 예를 들어, MEC 데이터 서비스를 위한 CARP 또는 URSP 규칙(rules) 중 적어도 하나를 인증 정보에 더 포함하여 제공할 수 있다. 일 실시예에 따르면, 동작 1205에서, MSA(520)는 인증 결과에 따른 인증 정보(예: MMP Info, MAT, 및 CARP 또는 URSP 규칙) 모두를 MMP 서버(430)로부터 수신할 수 있다. 다른 실시예에 따르면, 동작 1205에서, MSA(520)는 인증 정보의 일부(예: 디스커버리를 위한 MMP Info, MAT)는 MMP 서버(430)로부터 수신하고, CARP 규칙(또는 URSP 규칙)은 후술하는 도 13의 예시와 같이 사용자 인증(user authentication) 결과로서 AA 서버(580)로부터 수신할 수도 있다.
일 실시예에 따라, MMP Info는, 예를 들어, MMP 서버(430) 접속에 관련된 정보(예: MMP 접속 주소)를 포함할 수 있다. 예를 들어, MMP Info는 접속할 새로운 MMP 서버(430)의 주소 정보(예: URI(uniform resource identifier) 또는 IP 주소)와 해당 주소 정보의 유효 시간 및/또는 장소에 관련된 정보를 포함할 수 있다. 일 실시예에 따라, 접속 토큰(예: MAT)은, 예를 들어, MEC 디스커버리 권한 확인용 접속 토큰을 포함할 수 있다. 일 실시예에 따라, CARP 또는 URSP 규칙은, 예를 들어, DNN 구성(configuration) 관련 정보, DNN 별 사용 가능한 어플리케이션(또는 어플리케이션 그룹)에 관련된 정보, 또는 이후 설정 가능한 DNN 리스트(list) 또는 설정 가능한 DNN 최대 개수에 관련된 정보를 포함할 수 있다.
동작 1207에서, MSA(520)는 인증 절차가 완료되면, MSE(530)와 정책 업데이트(policy update)를 수행(예: PDU 세션 설정(setup))할 수 있다. 일 실시예에 따라, MSA(520)는 CARP 또는 URSP 규칙(예: DNN)에 따라 초기 PDU 세션 설정을 수행할 수 있다. 예를 들어, MSA(520)는 MMP 서버(430)로부터 수신 정보에 URSP 규칙이 있는 경우, MSE API를 이용하여 URSP 규칙을 업데이트 할 수 있다.
일 실시예에 따르면, 동작 1207의 MSA(520)와 MSE(530)의 정책 업데이트 동작은, 예를 들어, MSA(520)가 AA 서버(580)로부터 CARP 또는 URSP 규칙이 제공되는 경우 수행할 수 있다. 일 실시예에 따르면, MSA(520)는 AA 서버(580)로부터 CARP 또는 URSP 규칙이 제공되지 않는 경우 MSE(530)와 정책 업데이트를 수행하지 않을 수도 있다. 다른 실시예에 따르면, MSA(520)는 AA 서버(580)로부터 CARP 또는 URSP 규칙이 제공되더라도 MSA(520)의 자체적인 판단 또는 MSE(530)와의 정보 교환을 통해 정책 업데이트를 수행하지 않을 수도 있다.
동작 1209에서, MSA(520)는 MSE(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 AA 서버(580)와 인증 수행 중 또는 수행 후에, MMP 서버(430)로부터, 인증 결과에 따른 인증 정보(예: 접속 토큰(MAT))를 수신하는 경우, 수신된 인증 정보(예: 접속 토큰(MAT))를 MSE(530)에 전달하여 MES(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 인증 정보(예: 접속 토큰(MAT))와 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(430)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE(530)에 전달할 수 있다. 일 실시예에 따르면, MSA(520)는 수신된 접속 토큰(MAT) 및/또는 그 외의 다른 부가 정보에 기반하여 MSE(530)를 활성화(enable MEC)할 수 있다. 일 실시예에 따르면, MSA(520)가 MMP 서버(430)와 인증을 수행하는 경우, MSA(520)는 MMP 서버(430)로부터, 인증 결과로 접속 토큰(예: MAT)을 수신할 수 있으며, 예를 들어, MSE API의 enableMecEnablingLayer(true, MMP Info, MAT)를 호출함으로써, MSE(530)에 MMP 접속 정보(MMP Info) 및 접속 토큰(MAT)을 전달할 수 있다.
동작 1211에서, MSE(530)는 인증 정보(예: MAT) 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)을 수신하고, 인증 정보 및/또는 부가 정보에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP Info 및 MAT를 사용하여 해당 MMP 서버(430)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다.
도 13은 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 13에 도시한 바와 같이, 도 13은 다양한 실시예들에 따른 인증 절차(예: AA 및 정책 업데이트에 관한 시나리오 B)를 위한 신호 흐름의 예를 나타낼 수 있다. 예를 들어, 도 13은 다양한 실시예들에 따른 인증 절차 중 시나리오 B를 위한 MEC 서비스 인증 플로우의 예를 나타낸 것으로, 도 12에 따른 동작 1201, 동작 1203, 및 동작 1205에 대응하는 상세 실시예를 포함할 수 있다. 일 실시예에 따르면, 도 13에 도시된 실시예에서는, “User Authentication(또는 Subscriber Authentication)” 동작(예: 동작 1320)이 “MEC Service Authorization” 동작(예: 동작 1310)의 일부로 포함될 수 있다. 일 실시예에 따르면, MEC AA 및 정책 업데이트를 위한 시나리오 B는, 도 13에 도시한 바와 같이, User Authentication(예: 동작 1320) 이전에 MEC Service Authorization(예: 동작 1310)을 수행하는 시나리오 예를 나타낼 수 있다.
도 13을 참조하면, 동작 1301에서, 전자 장치(101)의 MSA(520)는 권한 부여 요청(authorization request)을 위한 권한 요청 메시지를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따라, 권한 요청 메시지는 MNO 정보와 Device ID(예: IMSI, IMEI, GPSI, 또는 별도 할당된 고유 식별자) 중 적어도 하나 또는 모두를 포함할 수 있다.
동작 1303에서, MMP 서버(430)는 인증 방식(authentication method)을 결정할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 지정된 적어도 하나의 인증 방식에서 전자 장치(101)의 권한 부여 요청에 대응하는 인증 방식을 결정할 수 있다. 일 실시예에 따르면, 적어도 하나의 인증 방식은, 예를 들어, Application-layer AKA 또는 Login(예: ID/password) 방식을 포함할 수 있다.
동작 1305에서, MSA(520)는 인타이틀먼트 서버(1000)의 URI를 MMP 서버(430)로 전달할 수 있다.
동작 1307에서, MMP 서버(430)는 인타이틀먼트 서버(1000)로 권한 코드(authorization code)를 요청할 수 있다. 일 실시예에 따르면, MSA(520)가 가입자 식별 정보(또는 단말 식별 정보)(예: GPSI 또는 IMSI)를 MMP 서버(430)에 전달하면, MMP 서버(430)는 해당 정보를 MNO 측의 인타이틀먼트 서버(1000) 또는 AA 서버(580)에 전달하면서 권한 코드(authorization code)를 요청할 수 있다. 일 실시예에 따르면, MSA(520)가 가입자 식별 정보에 대해 AA 서버(580)와 인증이 되어 있지 않은 경우, 동작 1320에 예시한 바와 같이, Application-layer AKA 또는 Login방식으로 사용자 인증(user authentication)을 수행할 수 있다. 일 실시예에 따르면, MNO 정보에 따라 인증 방식이 상이할 수 있으며, AA 서버(580)는 MNO 정보에 대응하는 방식을 이용하여 인증을 수행할 수 있다. 예를 들면, MSA(520)는 AA 서버(580)와 지정된 적어도 하나의 인증 방식에 기반하여 인증을 수행할 수 있다.
일 실시예에 따르면, 동작 1309에서, MSA(520)는 인타이틀먼트 서버(1000)를 통해 AA 서버(580) 간에 Application-layer AKA 방식에 기반하여 인증(authentication) 절차를 수행할 수 있다. 다른 실시예에 따르면, 동작 1311에서, MSA(520)는 인타이틀먼트 서버(1000)와 ID/password 기반 Login 방식에 기반하여 인증(authentication) 절차를 수행하고, 동작 1313에서, 인타이틀먼트 서버(1000)에 로그인 성공(Login Success)하는 것으로 인증 절차를 수행할 수 있다.
동작 1315에서, MMP 서버(430)는 인타이틀먼트 서버(1000)로부터 권한 코드 요청에 대응하는 권한 코드 응답을 수신하면, 동작 1317에서, AA 서버(580)에 가입자 프로필(user profile)을 확인하기 위한 접속 토큰을 인타이틀먼트 서버(1000)에 요청하고, 인타이틀먼트 서버(1000)로부터 접속 토큰을 수신할 수 있다. 일 실시예에 따르면, AA 서버(580)는 해당 전자 장치(101)에 대한 인증이 완료된 경우, 필요에 따라, MSA(520)에 CARP 또는 URSP 규칙을 전달할 수 있고, MMP 서버(430)가 요청한 권한 코드를 MMP 서버(430)에 전달할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 MMP 정보와 권한 코드를 인타이틀먼트 서버(1000) 또는 AA 서버(580)에 전달하며, 사용자 프로필 정보 접근을 위한 접속 토큰을 요청하고 수신할 수 있다.
일 실시예에 따라, 동작 1321에서, MMP 서버(430)는 접속 토큰을 이용하여 사용자 프로필(user profile)을 획득할 수 있다. 예를 들어, MSA(520)는 AA 서버(580)를 통해 MMP 서버(430)로 전자 장치(101)의 MEC 서비스 가입자 인증 및 권한 코드를 전달할 수 있다. 일 실시예에 따르면, MMP 서버(430)와 AA 서버(580)는 권한 코드를 사용하여 발급 받은 접속 토큰에 기반하여 가입자 프로필을 확인할 수 있다.
동작 1323에서, MMP 서버(430)는 권한 부여 요청에 대응하는 권한 부여 응답(authorization response)을 MSA(520)로 전송할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 해당 접속 토큰을 이용하여 사용자 프로필을 확인하고, 사용자 프로필에 기반하여 MEC 서비스가 가용하다는 것이 확인된 경우, 권한 부여 절차의 결과로 접속 토큰(예: MAT), MMP Info(예: URI), 및/또는 라우트 정책(예: CARP 또는 URSP 규칙(예: 전용 DNN))을 포함하여 Authorization response을 MSA(520)로 전달할 수 있다.
일 실시예에 따르면, 동작 1323에서, MSA(520)는 권한 부여 절차의 결과로 접속 토큰(예: MAT)을 획득할 수 있다. 일 실시예에 따라, MSA(520)가 MMP 서버(430)와 권한 부여 절차를 수행하는 경우, MSA(520)는 권한 부여 절차의 결과로 접속 토큰을 수신하며, MSE API를 통해 MSE(530)로 MMP 정보 및 접속 토큰을 전달할 수 있다. 다른 실시예에 따라, MSE(530)가 MMP 서버(430)와 권한 부여 절차를 수행하는 경우, 우선 인증을 완료한 MSA(520)가 MMP 서버(430)로부터 수신한 MMP 정보 및 권한 코드(Auth code)와, 선택적으로 ID_token을 MSE API를 통해 MSE(530)로 전달할 수 있다. MSE(530)는 MSA(520)로부터 전달된 정보에 기반하여 MMP 서버(430)와 직접 권한 부여 절차를 수행하고 그 결과로 접속 토큰을 수신할 수 있다.
동작 1325에서, MSA(520)는 MSE(530)를 통해 MMP Info 및 접속 토큰을 이용하여 MEC 디스커버리 절차를 수행할 수 있다.
도 14는 다양한 실시예들에 따른 전자 장치(101)에서 인증 절차를 위한 동작 방법을 도시하는 흐름도이다.
동작 1401에서, 전자 장치(101)의 프로세서(120)(또는 도 5의 MSE(530))는 액세스 통신(access communication)에 기반하여 AMF/PCF 서버(590)로부터 MMP 서버(430)접속에 필요한 제1 인증 정보를 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 AMF/PCF 서버(590)(예: AMF)와 NAS 시그널링(signaling) 절차를 수행할 수 있다. 일 실시예에 따라, AMF/PCF 서버(590)는 NAS 시그널링에 기반하여 전자 장치(101)로 제1 인증 정보를 제공할 수 있다. 일 실시예에 따라, 제1 인증 정보는, MMP Info, Auth Code를 포함할 수 있고, 추가적으로 ID_token 및/또는 CARP 또는 URSP 규칙을 포함할 수 있다. 일 실시예에 따르면, MSE(530)는 전자 장치(101)의 모뎀(또는 커뮤니케이션 프로세서(CP))이 AMF로부터 수신하는 NAS 시그널링 메시지를 MSE(530)의 UHL(533)을 통해 수신할 수 있다. 예를 들어, 전자 장치(101)의 모뎀은 MSA(520)는 NAS 시그널링 메시지로부터 MMP Info 및 Auth Code, ID_token, 또는 CARP 또는 URSP 규칙 중 적어도 하나의 정보를 획득하고, 획득된 정보를 UHL(533)을 통해 MSA(520)에 전달할 수 있다.
동작 1403에서, 프로세서(120)(또는 도 5의 MSE(530)))는 클라이언트 어플리케이션을 위한 PDU 세션을 설정(setup)할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 NAS 시그널링 메시지로부터 제1 인증 정보(예: MMP Info, Auth Code 및/또는 ID_token의 적어도 하나의 정보)를 획득할 수 있고, 획득된 제1 인증 정보를 MSA(520)에 전달할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 획득된 중보 중에 CARP 또는 URSP 규칙이 포함되어 있는 경우 MSE API를 이용하여 MSE(530)와 정책 업데이트를 수행할 수 있다. 일 실시예에 따르면, MSA(520)는 NAS 시그널링 메시지를 통해 획득한 정보 중에 CARP 또는 URSP 규칙이 제공되지 않는 경우 MSE(530)와 정책 업데이트를 수행하지 않을 수도 있다. 다른 실시예에 따르면, MSA(520)는 CARP 또는 URSP 규칙이 제공되더라도 MSA(520)의 자체적인 판단 또는 MSE(530)와의 정보 교환을 통해 정책 업데이트를 수행하지 않을 수도 있다.
동작 1405에서, 프로세서(120)(또는 도 5의 MSA(520))는 제1 인증 정보에 기반하여, MMP 서버(430)로 권한 부여 요청을 위한 제2 요청 메시지를 전송할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 인증 완료 후(또는 MSE(530)와 정책 업데이트 수행 또는 생략한 이후), 권한 부여(authorization) 요청(authorization request)을 위한 메시지를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따르면, MSA(520)는 NAS 시그널링 메시지로부터 획득된 제1 인증 정보(예: Auth Code 또는 추가적으로 ID_token 포함)에 기반하여, MMP 서버(430)에 권한 부여를 요청할 수 있다.
동작 1407에서, 프로세서(120)(또는 도 5의 MSA(520))는 MMP 서버(430)로부터 인증 결과에 따른 제2 인증 정보를 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 MMP 서버(430)를 통해 AA 서버(580)와 인증(예: 권한 부여 절차)을 수행할 수 있고, 인증 결과에 따른 제2 인증 정보를 MMP 서버(430)로부터 획득(또는 수신)할 수 있다. 제2 인증 정보는, 예를 들어, 접속 토큰(예: MAT)과 MMP Info를 포함할 수 있다.
동작 1409에서, 프로세서(120)(또는 도 5의 MSA(520))는 제2 인증 정보에 기반하여 MMP 서버(430)에 접속하여 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 MMP 서버(430)로부터, 인증 결과에 따른 제2 인증 정보(예: MAT)를 수신하는 경우, 수신된 제2 인증 정보를 전자 장치(101)의 MSE(530)에 전달하고, MSE(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 MAT와 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(430)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE API를 통해 MSE(530)로 전달할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 MAT 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP Info 및 MAT를 사용하여 해당 MMP 서버(430)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다.
다양한 실시예들에 따르면, 도 14에 도시된 인증 절차는, 예를 들어, 클라이언트 어플리케이션(510)이 기본 PDU 세션(또는 PDN)을 사용하여 MEC 어플리케이션에 연결하는 시나리오를 포함할 수 있다. 예를 들어, MSE(530)(예: MEL(531))에서 MEC 디스커버리 절차를 수행하여, 전자 장치(101)에 가까운 MEC 호스트에 MEC 어플리케이션 구동 및 연결을 요청하고, 해당 MEC 어플리케이션의 URI를 수신할 수 있다. 이후, 클라이언트 어플리케이션(510)이 해당 MEC 어플리케이션 접속 요청 시, 해당 URI에 대한 DNS 리졸빙을 통해 획득한 MEC 어플리케이션 IP 주소로 접속할 수 있다.
다양한 실시예들에 따르면, 도 14에 도시된 인증 절차는, 예를 들어, 클라이언트 어플리케이션이 기본 PDU 세션(또는 PDN) 외에, 별도의 MEC 전용 PDU 세션을 생성하여 MEC 어플리케이션에 연결하는 시나리오를 포함할 수 있다. 예를 들어, MEC 전용 PDU 세션 생성은 사업자(예: MNO 또는 MMP 서버(430)) 정책에 따르며, MSA(520) 또는 인증된 클라이언트 어플리케이션이 MSE API를 사용하여 UHL(533)을 통해 생성 할 수 있다. 일 실시예에 따라, MEC 전용 PDU 세션은 기본 PDU 세션 외에, 하나 이상의 PDU 세션을 항상 열어둘 수도 있고, 특정 시점에 필요에 따라 MEL(531)의 요청에 의해 동적으로 생성하거나 해제할 수 있다. 일 실시예에 따르면, 사전에 정의된 규칙(rule)(예: CARP 또는 URSP 규칙) 또는 외부 서버(예: MMP 서버(430), AA 서버(580), 또는 AMF/PCF 서버(590))로부터 수신한 라우팅 규칙에 따라 해당 클라이언트 어플리케이션(또는 UID) 또는 접속 URI에 대한 트래픽을 MEC 전용 PDU 세션으로 라우팅 되도록 MSE(530)의 UHL(533)에서 지원할 수 있다.
다양한 실시예들에 따르면, 도 14에 도시된 인증 절차는, 예를 들어, MEL(531)의 기능 없이, 특정 서비스에 대해 전용 PDU 세션만 생성하여 사용하는 시나리오를 포함할 수 있다. 일 실시예에 따르면, MSA(520) 또는 인증된 클라이언트 어플리케이션(510)에 MSE API를 사용하여 별도의 전용 PDU 세션을 생성하고, 해당 PDU 세션을 사용하는 어플리케이션(예: UID) 규칙을 등록하고, 해당 어플리케이션의 트래픽을 해당 PDU 세션으로 라우팅 되도록 할 수 있다.
도 15A는 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 15A에 도시한 바와 같이, 전자 장치(101)는 MSA(또는 서비스 에이전트)(520)(예: AA 클라이언트(525) 포함)와 MSE(또는 서비스 인에이블러)(530)(예: MEL(531), UHL(533) 포함)를 포함할 수 있다. 일 실시예에 따르면, AMF/PCF 서버(590)의 PCF에서 URSP를 추가하여 MMP 접속에 필요한 정보(예: MMP Info, Auth Code, 또는 ID_token)를 관리할 수 있다.
도 15A를 참조하면, 동작 1501에서, 전자 장치(101)의 MSE(530)는 AMF/PCF 서버(590)(예: AMF)와 NAS 시그널링(signaling) 절차를 수행할 수 있다. 일 실시예에 따라, AMF/PCF 서버(590)는 전자 장치(101)로 MMP Info, Auth Code를 제공할 수 있고, 추가적으로 ID_token 및/또는 CARP 또는 URSP 규칙을 제공할 수 있다. 일 실시예에 따르면, MSE(530)는 전자 장치(101)의 모뎀(또는 커뮤니케이션 프로세서)이 AMF(590)로부터 수신하는 NAS 시그널링 메시지를 MSE(530)의 UHL(533)을 통해 수신할 수 있다. 예를 들어, 전자 장치(101)의 모뎀은 AMF로부터 수신하는 NAS 시그널링 메시지로부터 MMP Info 및 Auth Code, ID_token, 또는 CARP 또는 URSP 규칙 중 적어도 하나의 정보를 획득하고, 획득된 정보를 UHL(533)을 통해 MSA(520)에 전달할 수 있다.
동작 1503에서, MSE(530)는 NAS 시그널링 메시지로부터 MMP Info, Auth Code 및/또는 ID_token의 적어도 하나의 정보를 획득할 수 있고, 획득된 정보를 MSA(520)에 전달할 수 있다. 일 실시예에 따라, MMP Info는, 예를 들어, MMP 서버(430) 접속에 관련된 정보(예: MMP 접속 주소)를 포함할 수 있다. 예를 들어, MMP Info는 접속할 새로운 MMP 서버(430)의 주소 정보(예: URI(uniform resource identifier) 또는 IP 주소)와 해당 주소 정보의 유효 시간 및/또는 장소에 관련된 정보를 포함할 수 있다. 일 실시예에 따라, CARP 또는 URSP 규칙은, 예를 들어, DNN 구성(configuration) 관련 정보, DNN 별 사용 가능한 어플리케이션(또는 어플리케이션 그룹)에 관련된 정보, 또는 이후 설정 가능한 DNN 리스트(list) 또는 설정 가능한 DNN 최대 개수에 관련된 정보를 포함할 수 있다.
일 실시예에 따르면, AMF/PCF 서버(590)로부터 제공된 MMP Info, Auth Code, ID_token, 또는 CARP 또는 URSP 규칙 중 적어도 하나의 정보는 MSE(530)를 통해 MSA(520)에서 획득할 수도 있다.
동작 1505에서, MSA(520)는 MSE(530)와 정책 업데이트(policy update)를 수행(예: PDU 세션 설정)할 수 있다. 일 실시예에 따라, MSA(520)는 CARP 또는 URSP 규칙(예: DNN)에 따라 PDU 세션 설정을 수행할 수 있다. 예를 들어, MSA(520)는 MMP 서버(430)로부터 수신 정보에 URSP 규칙이 있는 경우, MSE API를 이용하여 URSP 규칙을 업데이트 할 수 있다. 일 실시예에 따르면, MSA(520)는 NAS 시그널링 메시지를 통해 획득한 정보 중에 CARP 또는 URSP 규칙이 포함되어 있는 경우 MSE(530)와 정책 업데이트를 수행할 수 있다. 일 실시예에 따르면, MSA(520)는 NAS 시그널링 메시지를 통해 획득한 정보 중에 CARP 또는 URSP 규칙이 제공되지 않는 경우 MSE(530)와 정책 업데이트를 수행하지 않을 수도 있다. 다른 실시예에 따르면, MSA(520)는 CARP 또는 URSP 규칙이 제공되더라도 MSA(520)의 자체적인 판단 또는 MSE(530)와의 정보 교환을 통해 정책 업데이트를 수행하지 않을 수도 있다. 일 실시예에 따르면, MSA(520)와 MSE(530) 간 정책 업데이트 시에 PDU 세션 설정을 수행할 수 있다.
동작 1507에서, MSA(520)는 NAS 시그널링 메시지를 수신한 후(또는 MSE(530)와 정책 업데이트 수행 또는 생략한 이후), 권한 부여(authorization) 요청(authorization request)(예: 서비스 사용 권한 요청)을 위한 메시지(예: 권한 요청 메시지)를 MMP 서버(430)에 전송할 수 있다. 일 실시예에 따르면, MSA(520)는 NAS 시그널링 메시지로부터 획득된 인증 정보(예: Auth Code 또는 추가적으로 ID_token 포함)에 기반하여, MMP 서버(430)에 서비스 사용에 대한 권한 부여를 요청할 수 있다.
동작 1509에서, MSA(520)는 MMP 서버(430)를 통해 AA 서버(580)와 인증(예: 권한 부여 절차)을 수행할 수 있다. 일 실시예에 따라, MSA(520)는 AA 서버(580)와 Auth Code 또는 ID_token 중 적어도 하나 또는 모두를 MMP 서버(430)로 제공(또는 전송)하여, 서비스 사용에 대한 권한 부여(service Authorization)를 요청할 수 있다.
동작 1511에서, MMP 서버(430)는 MSA(520)의 권한 부여 요청(예: 권한 요청 메시지)에 대응하여, 인증 정보를 전자 장치(101)(예: MSA(520))에 제공(또는 전송)할 수 있다. 일 실시예에 따르면, 인증 정보는, 예를 들어, 접속 토큰(예: MAT) 및 MMP Info를 포함할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 MSA(520)의 인증 수행 중 또는 수행 이후에 접속 토큰 및 MMP Info을 포함하는 응답을 MSA(520)에 전송할 수 있다.
동작 1513에서, MSA(520)는 MSE(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 MMP 서버(430)로부터, 인증 정보(예: 접속 토큰(MAT), MMP Info)를 수신하는 경우, 수신된 인증 정보(예: 접속 토큰(MAT), MMP Info)를 MSE(530)에 전달하여 MSE(530)를 활성화 할 수 있다. 일 실시예에 따르면, MSA(520)는 접속 토큰(MAT)과 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(430)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE(530)에 전달할 수 있다. 일 실시예에 따르면, MSA(520)는 수신된 접속 토큰(MAT) 및/또는 그 외의 다른 부가 정보에 기반하여 MSE(530)를 활성화(enable MEC)할 수 있다. 일 실시예에 따르면, MSA(520)가 MMP 서버(430)와 권한 부여 절차를 수행하는 경우, MSA(520)는 MMP 서버(430)로부터, 접속 토큰(예: MAT)을 수신할 수 있으며, 예를 들어, MSE API의 enableMecEnablingLayer(true, MMP Info, MAT)를 호출함으로써, MSE(530)에 MMP 접속 정보(MMP Info) 및 접속 토큰(MAT)을 전달할 수 있다.
동작 1515에서, MSE(530)는 인증 정보(예: MAT) 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)을 수신하고, 인증 정보 및/또는 부가 정보에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP Info 및 MAT를 사용하여 해당 MMP 서버(430)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다.
도 15B는 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 15B에 도시한 바와 같이, 도 15B는 다양한 실시예들에 따른 인증 절차(예: AA 및 정책 업데이트에 관한 시나리오 C)를 위한 신호 흐름의 예를 나타낼 수 있다. 예를 들어, 도 15B는 다양한 실시예들에 따른 인증 절차 중 시나리오 C(예: 도 15A에 따른 인증 절차)를 위한 MEC 서비스 인증 플로우의 예를 나타낸 것으로, 5G NAS 기반 모델(5G NAS-based Mode)에서 수행하는 시나리오 에를 나타낼 수 있다.
도 15B를 참조하면, 동작 1531에서, 전자 장치(101)의 MSA(520)는 AMF/PCF 서버(590)와 NAS 시그널링을 통해 수신하는 NAS 메시지로부터, MMP Info(예: URI, DNN), Auth Code, 및 CARP 또는 URSP 규칙과 같은 정보를 획득할 수 있다. 일 실시예에 따르면, NAS 메시지는 ID-token을 더 포함할 수도 있다.
동작 1533에서,, MSA(520)는 NAS 시그널링의 결과로 획득한 정보를 이용하여 MMP 서버(430)로 권한 부여(authorization) 요청(예: 서비스 사용 권한 요청)을 위한 메시지(예: 권한 요청 메시지)를 전송할 수 있다. 예를 들어, MSA(520)는 획득된 정보(예: MMP Info, Auth Code, CARP 또는 URSP 규칙)를 MMP 서버(430)로 전달하여 MMP 서버(430)에 권한 부여를 요청할 수 있다.
동작 1535에서, MMP 서버(430)는 AA 서버(580)에 사용자 프로필(user profile) 정보 접근을 위한 접속 토큰(access token)을 요청할 수 있고, 동작 1537에서, AA 서버(580)로부터 접속 토큰을 획득할 수 있다.
동작 1539에서, MMP 서버(430)는 접속 토큰을 이용하여 사용자 프로필을 획득할 수 있다. 예를 들어, MMP 서버(430)는 MMP 정보와 권한 코드를 AA 서버(580)에 전달하며, 사용자 프로필(user profile) 정보 접근을 위한 접속 토큰을 요청하여 획득할 수 있다.
동작 1541에서, MMP 서버(430)는 권한 부여 요청에 대응하는 권한 부여 응답(quthorization response)을 MSA(520)로 전송할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 해당 접속 토큰을 이용하여 사용자 프로필을 확인하고, 사용자 프로필에 기반하여 MEC 서비스가 가용하다는 것이 확인된 경우, 권한 부여 절차의 결과로 MEC 디스커버리를 위한 MMP Info, 접속 토큰(예: MAT), 및/또는 MEC 데이터 서비스를 위한 라우트 정책(예: CARP 또는 URSP 규칙)을 포함하여 Authorization response을 MSA(520)로 전달할 수 있다.
일 실시예에 따르면, 동작 1541에서, MSA(520)는 권한 부여 절차의 결과로 접속 토큰(예: MAT)을 획득할 수 있다. 일 실시예에 따라, MSA(520)가 MMP 서버(430)와 권한 부여 절차를 수행하는 경우, MSA(520)는 권한 부여 절차의 결과로 접속 토큰을 수신하며, MSE API를 통해 MSE(530)로 MMP 정보 및 접속 토큰을 전달할 수 있다. 다른 실시예에 따라, MSE(530)가 MMP 서버(430)와 권한 부여 절차를 수행하는 경우, 우선 인증을 완료한 MSA(520)가 MMP 서버(430)로부터 수신한 MMP 정보 및 권한 코드(Auth code)와, 선택적으로 ID_token을 MSE API를 통해 MSE(530)로 전달할 수 있다. MSE(530)는 MSA(520)로부터 전달된 정보에 기반하여 MMP 서버(430)와 직접 권한 부여 절차를 수행하고 그 결과로 접속 토큰을 수신할 수 있다.
동작 1543에서, MSA(520)는 MSE(530)를 통해 MMP Info 및 접속 토큰을 이용하여 MEC 디스커버리 절차를 수행할 수 있다.
도 16은 다양한 실시예들에 따른 전자 장치(101)의 동작 방법을 도시하는 흐름도이다.
도 16을 참조하면, 동작 1601에서, 전자 장치(101)의 프로세서(120)(또는 도 4의 MEC 서비스 모듈(410))는 MSA(520)(또는 서비스 에이전트)를 통해, 네트워크의 지정된 외부 서버(예: 인증 서버 또는 MMP 서버)와 MEC 서비스를 위한 인증(예: 사용자 인증 또는 서비스 인증)을 수행할 수 있다
동작 1603에서, 프로세서(120)(또는 도 4의 MEC 서비스 모듈(410))는 외부 서버로부터 인증 결과에 따른 인증 정보를 수신할 수 있다.
동작 1605에서, 프로세서(120)(또는 도 4의 MEC 서비스 모듈(410))는 인증 정보를 수신하는 것에 기반하여, MSE(530)(또는 서비스 인에이블러)와 정책 업데이트(policy update)를 선택적으로 수행할 수 있다.
동작 1607에서, 프로세서(120)(또는 도 4의 MEC 서비스 모듈(410))는 인증 정보에 기반하여 MMP Info와 MMP 서버(430)에 접속을 위한 토큰을 획득할 수 있다.
동작 1609에서, 프로세서(120)는 MMP Info와 토큰을 MSE API를 통해 MSE(530)에 전달하여 MSE(530)를 활성화 할 수 있다.
동작 1611에서, 프로세서(120)(또는 도 4의 MEC 서비스 모듈(410))는 MSE(530)를 통해 해당 MMP 서버(430)에 접속하여 MEC 디스커버리 절차를 수행할 수 있다.
PDU 세션 설정(session setup)
이하에서는, MEC 서비스를 위한 인증 절차에 대응하여 전자 장치(101)의 내부에서 이루어지는 동작들을 설명한다.
도 17은 다양한 실시예들에 따른 전자 장치(101)에서 정책 업데이트 동작 예를 도시하는 도면이다.
도 17에 도시한 바와 같이, 도 17은, 정책 업데이트(예: PDU 세션 설정) 중 PDU 세션 생성(establishment)의 일 예를 나타낼 수 있으며, PDU 세션 설정(또는 PDN 연결 생성(PDN connection establishment))에서 전용 DNN 활성화(dedicated DNN activation)을 위한 동작 예를 나타낼 수 있다. 일 실시예에 따르면, PDU 세션 설정(session setup)은 새로운 PDU 세션 생성(session establishment), 기존 PDU 세션 해제(session release), 및 기존 PDU 세션 업데이트(session update)(예: PDU 세션 별 특성에 대한 설정(예: bandwidth 또는 latency와 같은 QoS 정보) 변경)를 포함할 수 있으며, 도 17에서는 PDU 세션 생성 예를 나타낼 수 있다. 일 실시예에 따라, 전자 장치(101)는 MSA(또는 서비스 에이전트)(520), MSE(또는 서비스 인에이블러)(530), 및 모뎀(또는 CP, communication processor)(1700)을 포함할 수 있다.
도 17을 참조하면, 동작 1701에서, MSA(520)는 DNN 설정에 대한 정보를 획득(또는 수신)하는 경우 DNN을 설정하도록 지시하는 제1 메시지(예: setUrspDNN)를 MSE(530)로 제공(또는 전달)할 수 있다.
동작 1703에서, MSE(530)는 MSA(520)로부터 제공된 제1 메시지(예: setUrspDNN)에 기반하여 DNN 정보를 업데이트(예: update DNN Info)할 수 있다.
동작 1705에서, MSA(520)는 PDU 세션(또는 PDN 연결)을 생성하도록 지시하는 제2 메시지(예: requestPduSession)를 MSE(530)로 제공할 수 있다.
동작 1707에서, MSE(530)는 제2 메시지(예: requestPduSession)를 수신하는 경우, 데이터 호(data call)를 설정하도록 지시하는 제3 메시지(예: setup data call)를 모뎀(1700)으로 제공할 수 있다.
동작 1709에서, 모뎀(1700)은 MSE(530)로부터 제3 메시지(예: setup data call)를 수신하면, 서비스(예: MEC 서비스)의 처리를 위한 미리 구성된 정보에 기반하여 데이터 호를 설정하거나, 또는 지시된 정보에 기반하여 데이터 호를 설정하고, MSE(520)로 제3 메시지에 대응하는 제4 메시지(예: 응답(Response) 메시지)를 제공할 수 있다. 일 실시예에 따르면, 모뎀(1700)이 제3 메시지(예: setup data call)에 의해 코어 망(예: SMF)에 PDU 세션 생성을 요청하는 것에 기반하여 PDU 세션이 생성될 수 있다.
동작 1711에서, MSE(530)는 모뎀(1700)으로부터 제4 메시지(예: 데이터 호 설정 요청에 대응하는 응답)을 수신하는 경우, PDU 세션이 생성(establishment) 되었음을 통지하는 제5 메시지(예: onAvaible)를 MSA(520)로 제공할 수 있다.
동작 1713에서, MSA(520)는 URSP 규칙이 앞서 설명한 방식들 중 어느 하나의 방식을 이용하여 수신되거나, 또는 그 밖의 다른 방식을 통해 수신되는 경우, URSP 규칙의 설정을 지시하는 제6 메시지(예: setUrspRules)를 MSE(530)로 제공할 수 있다. 일 실시예에 따르면, 동작 1715에서, MSA(520)는 MEC 서비스 활성화 모드(예: MSE 활성화)를 실행(true)하도록 지시하는 제7 메시지(예: setMaServiceEnableMode(true))를 MSE(530)로 제공할 수 있다.
동작 1717에서, MSE(530)는 MSA(520)로부터 수신된 제6 메시지(예: setUrspRules)와 제7 메시지(예: setMaServiceEnableMode(true))에 기반하여 라우팅 테이블(routing table)을 생성(또는 추가(add))할 수 있다. 일 실시예에 따르면, URSP 규칙에는 어플리케이션 별 또는 URI 별 사용 PDU 세션 정보를 포함할 수 있으며, 전자 장치(101)(예: MSE(530))는 URSP 규칙 상의 PDU 세션이 생성되어 있지 않은 경우, setUrspDNN API를 통해 PDU 세션을 생성할 수 있다. 일 실시예에 따라, 전자 장치(101)(예: MSE(530))는 PDU 세션 생성 시에, 해당 어플리케이션 ID(AppID) 또는 URI에 대한 데이터 경로를 URSP 규칙 상의 PDU 세션으로 설정되도록 setUrspRules API를 통해 라우팅 테이블을 설정할 수 있다.
도 18은 다양한 실시예들에 따른 전자 장치(101)에서 PDU 세션 설정 동작 예를 도시하는 도면이다.
도 18에 도시한 바와 같이, 도 18은, 정책 업데이트(예: PDU 세션 설정) 중 PDU 세션 해제(release)의 일 예를 나타낼 수 있으며, PDU 세션(또는 PDN 연결(PDN connection))을 해제(release)하기 위한 동작 예를 나타낼 수 있다. 일 실시예에 따르면, PDU 세션 설정(session setup)은 새로운 PDU 세션 생성(session establishment), 기존 PDU 세션 해제(session release), 및 기존 PDU 세션 업데이트(session update)(예: PDU 세션 별 특성에 대한 설정(예: bandwidth 또는 latency와 같은 QoS 정보) 변경)를 포함할 수 있으며, 도 17에서는 PDU 세션 해제 예를 나타낼 수 있다. 일 실시예에 따라, 전자 장치(101)는 MSA(또는 서비스 에이전트)(520), MSE(또는 서비스 인에이블러)(530), 및 모뎀(또는 CP, communication processor)(1700)을 포함할 수 있다.
도 18을 참조하면, 동작 1801에서, MSA(520)는 DNN 설정에 대한 정보의 설정을 해제해야 하는 경우, 해당하는 DNN을 해제하도록 지시하는 제1 메시지(예: setUrspDNN)를 MSE(530)로 제공(또는 전달)할 수 있다.
동작 1803에서, MSE(530)는 MSA(520)로부터 제공된 제1 메시지(예: setUrspDNN)에 기반하여 데이터 호(data call)를 해제(release)하도록 지시하는 제2 메시지(예: Release data call)를 모뎀(1500)으로 제공할 수 있다.
동작 1805에서, 모뎀(1700)은 MSE(530)로부터 제3 메시지(예: Release data call)를 수신하면, 해당하는 서비스(예: MEC 서비스)의 처리를 위해 설정된 구성을 해제하고, MSE(530)로 제3 메시지에 대응하는 제4 메시지(예: 응답(Response) 메시지)를 제공할 수 있다. 일 실시예에 따르면, 모뎀(1700)이 제3 메시지(예: Release data call)에 의해 코어 망(예: SMF)에 PDU 세션 해제를 요청하는 것에 기반하여 PDU 세션이 해제될 수 있다.
동작 1807에서, MSA(520)는 MEC 서비스 비활성화 모드(예: MSE 비활성화)를 실행(false)하도록 지시하는 제5 메시지(예: setMaServiceEnableMode(false))를 MSE(530)로 제공할 수 있다.
동작 1809에서, MSE(530)는 MSA(520)로부터 수신된 제5 메시지(예: setMaServiceEnableMode(false))에 기반하여 메모리(예: 도 1 또는 도 2의 메모리(130))에 저장(또는 생성)된 라우팅 테이블을 메모리에서 삭제(delete)할 수 있다.
도 19는 다양한 실시 예들에 따른 전자 장치(101)에서 MEC 기반 데이터 전송 가능 여부를 확인하는 방법을 도시하는 흐름도이다.
다양한 실시예들에서, 도 19에 도시된 동작들은, 예를 들어, 전자 장치(101)가 사업자 네트워크에 어태치(attach)할 때, 사업자 네트워크가 변경될 때(예: 해외 로밍(roaming)), 지정된 주기에 따라서, 또는 가입자 정보가 변경될 때 중 적어도 하나의 경우에 수행될 수 있다.
도 19를 참조하면, 동작 1901에서, 전자 장치(101)는 전자 장치(101)가 접속된 네트워크가 MEC 기반 데이터 전송이 가능한 네트워크인지 확인할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)(예: MSE(530))는 전자 장치(101)가 접속된 네트워크의 셀 ID, PLMN(public land mobile network), 또는 DNN(data network name(=APN(access point name)) 중 적어도 하나에 기반하여 MEC 기반 데이터 전송이 가능한지를 확인할 수 있다. 일 실시예에 따르면, 셀 ID, PLMN, 또는 DNN 중 적어도 하나는 전자 장치(101)에 미리 등록된 정보일 수 있고, 전자 장치(101)가 MEC 시스템(405)에 요청함으로써 획득될 수 있다.
동작 1903에서, 전자 장치(101)는 전자 장치(101)가 접속된 네트워크의 MEC 서비스 레벨을 확인할 수 있다. 일 실시예에 따르면, MEC 서비스 레벨은, 예를 들어, MEC 사용 권한 또는 MEC QoS(quality of service) 중 적어도 하나를 포함할 수 있다. MEC QoS는, 예를 들어, 사용자 별 가입 정보에 따라 서비스 품질 등급이 차등 적용 되어 있을 경우 이에 대한 정보를 의미할 수 있다. 예를 들어, 프리미엄 가입자의 경우 MEC 서비스 어플리케이션 종류 및/또는 MEC 호스트 자원(예: bandwidth, memory, cpu, 또는 gpu와 같은 자원)을 더 많이 제공할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 SIM(또는 USIM)과 관련된 정보 또는 전자 장치(101)의 사용자 가입 정보(예: IMEI) 중 적어도 하나를 이용하여 MEC 서비스 레벨을 확인할 수 있다.
일 실시예에 따르면, 전자 장치(101)가 접속된 네트워크가 MEC 데이터 전송이 가능하며 전자 장치(101)의 MEC 사용 권한이 있는 경우, 전자 장치(101)는 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 디스커버리 절차를 수행하기 이전에 MEC 데이터 전송 가능 여부 또는 MEC 서비스 레벨을 확인함으로써 불필요한 디스커버리가 발생하는 것을 방지할 수 있다.
MEC 디스커버리(Discovery)
이하에서는, 다양한 실시예들에 따른 MEC 디스커버리 절차에 대하여 살펴보기로 한다. 일 실시예에 따르면, MEC 디스커버리 절차는, 앱 리스트 획득(예: MEC Application Look-up), 어플리케이션 컨텍스트 생성(Application Context Create), MEC 호스트 선택(MEC host selection), 및/또는 DNS 리졸빙(resolving) 동작을 포함할 수 있다.
도 20은 다양한 실시 예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 20을 참조하면, 동작 2001에서, MEC 서비스 모듈(410)(예: MSE(530))은 전자 장치(101)의 이동성과 관련된 이벤트(예: 디스커버리 트리거(discovery trigger))를 감지할 수 있다. 일 실시예에 따르면, 이동성과 관련된 이벤트는, 예를 들어, 전자 장치(101)의 움직임을 감지하는 동작, 전자 장치(101)와 연결된 기지국이 변경됨을 감지하는 동작, 또는 전자 장치(101)가 지정된 지역에 진입함을 감지하는 동작을 포함할 수 있다. 지정된 지역은, 예를 들어, LADN, TA, 기지국의 셀, 기지국 간 핸드오버가 발생하는 영역, 또는 위치 기반 서비스에 의하여 결정된 영역 중 적어도 하나를 의미할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 이동성과 관련된 이벤트를 감지하도록 구성되는 모듈(예: 도 1의 센서 모듈(176) 중 적어도 하나의 센서, 커뮤니케이션 프로세서(예: 도 1의 보조 프로세서(123)), LADN 감지 모듈, 또는 GPS 감지 모듈)을 포함할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 해당 모듈로부터 전자 장치(101)의 이동성과 관련된 이벤트에 대한 알림을 받거나, 해당 모듈을 모니터링 하는 방식으로 전자 장치(101)의 이동성과 관련된 이벤트를 감지할 수 있다.
일 실시예에 따르면, 전자 장치(101)의 이동성과 관련된 이벤트가 감지되면, MEC 서비스 모듈(410)은 MEC 디스커버리 절차를 수행할 수 있다. MEC 디스커버리 절차는, 예를 들어, 전자 장치(101)가 MEC 시스템(405)에서 제공 가능한 어플리케이션(들)(예: MEC 어플리케이션(들))을 확인(또는 발견(discovery))하는 일련의 동작을 의미할 수 있다. 예를 들어, MEC 디스커버리 절차는 동작 2003 내지 2005를 포함할 수 있다. 도 20에서는 도시되지 않았으나, MEC 서비스 모듈(410)는 전자 장치(101)의 이동성과 관련된 이벤트가 감지됨을 나타내는 정보를 클라이언트 어플리케이션(510)에 제공할 수도 있다.
일 실시예에 따르면, 동작 2003에서, MEC 서비스 모듈(410)은 MEC 시스템(405)(예: MMP 서버(430) 또는 LCM 프록시 서버)에게 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보를 요청할 수 있다. 예를 들어, MEC 서비스 모듈(410)은 어플리케이션 룩업 요청(application lookup request) 메시지를 MEC 시스템(405)에 전송할 수 있다. 일 실시예에 따라, MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보는 앱 리스트(list)로 지칭될 수 있다. 일 실시 예에 따르면, 동작 2003에서 전송되는 데이터 패킷은 제어 데이터를 포함하는 제1 데이터 패킷으로서, MEC 서비스 모듈(410)과 관련된 제1 주소를 포함할 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 MEC 시스템(405)과 별도의 제3 서버(미도시)에게 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보를 요청할 수도 있다. 제3 서버는, 예를 들어, 전자 장치(101)가 접속된 사업자 네트워크의 내부 또는 외부에 배치될 수 있다. 이러한 경우, 전자 장치(101)는 네트워크 정보로부터 사업자 네트워크에 관한 정보를 획득하고, 획득된 정보에 기반하여 제3 서버에게 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보를 요청할 수도 있다.
일 실시예에 따르면, 동작 2005에서, MEC 서비스 모듈(410)은 MEC 시스템(405)으로부터 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보(예: 가용 어플리케이션의 앱 리스트)를 수신할 수 있다. 일 실시예에 따라, MEC 서비스 모듈(410)은 어플리케이션 룩업 요청(application lookup request) 메시지를 MEC 시스템(405)에 전송(예: 동작 2003)하고, MEC 시스템(405)으로부터 그에 대응하는 어플리케이션 룩업 응답(application lookup response) 메시지를 수신하여, 가용 어플리케이션의 앱 리스트를 획득할 수 있다.
일 실시예에 따라, 어플리케이션 룩업 요청 메시지에 포함될 수 있는 파라미터(parameter)(예: 앱 리스트 요청 파라미터)의 예는 아래 <표 1>과 같이 나타낼 수 있다.
Name Type Cardinal Description ETSI MEC compatible
appName String 0...N Name to identify the user app Y
appProvider String 0...N Provider of the MEC app Y
appSoftVersion String 0...N Software version of the MEC app Y
serviceCont Enum(inlined) 0...1 Required service continuity mode for this application:0 = SERVICE_CONTINUITY_NOT_REQUIRED1 = SERVICE_CONTINUITY_REQUIRED Y
vendorId String 0...N Vendor Identifier Y
clientappName String 0...N Name to identify the client App N
locationInfo String 0...1 (Longitude, Latitude) or gNB ID or TAI or SSID or Predefined Location ID N
deviceType Enum(inlined) 0...N Predefined device typeExample:0 = Default1 = Smartphone2 = Car3 = Drone ... N
serviceCategory Enum(inlined) 0...N Predefined service categoryExample:0 = Default1 = Video streaming2 = Game3 = V2X4 = AR/VR5 = Enterprise ... N
contextType Enum(inlined) 0...1 Required context type for this application:0 = APP_CONTEXT_NOT_REQUIRED1 = APP_CONTEXT_REQUIRED N
URI Request Boolean 0...1 Request for URI of MEC applications from App Look-up response if available N
NOTE: The value of the attribute of the type String shall not exceed the length of 32 characters.
<표 1>에 예시한 바와 같이, 다양한 실시예들에 따른 앱 리스트 요청 파라미터는, ETSI MEC 규격에서 정의되어 있는 파라미터 외에, 예를 들어, clientappName, locationInfo, deviceType, serviceType, contextType, 또는 URI Request 중 적어도 하나를 포함할 수 있다. 일 실시예에 따라, “clientappName”은 MSA(520)로부터 전달받은 어플리케이션 이름(예: AppNames)을 나타낼 수 있다. 일 실시예에 따라, “Location Info”은 접속 Cell ID, TA(tracking area) ID, 지역 정보(예: 시, 구, 동, 건물, …), 또는 사용자가 지정한 우선 위치(preferred location) 정보를 나타낼 수 있다. 일 실시예에 따라, “Device Type”은 Smartphone, Tablet, Wearable, IoT, Car, 또는 Drone과 같은 전자 장치(101)의 종류를 나타낼 수 있다. 일 실시예에 따라, “Service Type”은 Game, V2X, AR/VR, LBO, Enterprise, 또는 Web과 같은 서비스의 종류를 나타낼 수 있다. 일 실시예에 따라, “Context Type”은 MEC 어플리케이션 구동에 사용자 또는 어플리케이션의 컨텍스트(context) 정보가 필요한지 여부를 나타낼 수 있다. 일 실시예에 따라, “URI Request Flag”는 MEC 어플리케이션의 URI가 가용(available)한 경우 해당 URI를 응답에 포함하도록 요청하는 플래그(flag)를 나타낼 수 있다.
일 실시예에 따라, 어플리케이션 룩업 응답 메시지에 포함될 수 있는 파라미터(예: 앱 리스트 응답 파라미터)의 예는 아래 <표 2>와 같이 나타낼 수 있다. 예를 들어, 아래 <표 2>는 MEC 서비스 모듈(410)이 MEC 시스템(405)으로부터 수신하는 가용 어플리케이션의 앱 리스트의 예를 나타낼 수 있다.
Name Type Cardinal Description ETSI MEC Compatible
appList StructureArray 0...N List of MEC applications available to the client application. As defined below. Y
>appInfo Structure 1 Y
>>appDId String 1 Identifier of this MEC application descriptor. It is equivalent to the appDId defined in clause 6.2.1.2 of ETSI GS MEC 010-2 [1]. This attribute shall be globally unique. Y
>>appName String 1 Name of the MEC application.The length of the value shall not exceed 32 characters. Y
>>appProvider String 1 Provider of the MEC application.The length of the value shall not exceed 32 characters. Y
>>appSoftVersion String 1 Software version of the MEC application.The length of the value shall not exceed 32 characters. Y
>>appDVersion String 1 Identifies the version of the application descriptor. It is equivalent to the appDVersion defined in clause 6.2.1.2 of ETSI GS MEC 010-2 [1]. Y
>>appDescription String 1 Human readable description of the MEC application (see note 2). Y
>>referenceURI URI 0...1 Address of the MEC application.This can be provided if the address of the MEC application is currently available. N
>>clientAppName String 0...N Client app name that is allowed to connect to the mec application. N
>>clientAppPackageURL String 0...1 Address for downloading the corresponding client application package to connect with the MEC application N
>>uriTTL uint32 0...1 Time-to-live of the reference URI N
>>uriLOC String 0...1 Location (range) where the reference URI is available N
>>carpRule Structure 0...1 Client App Routing Policy Rules N
>>>DNN String 0...1 DNN selection for this application N
>>>S-NSSAI String 0...1 Network slice selection for this application N
>>>accessType String 0...1 Preferrend access type for this application (e.g., 4G, 5G, WiFi, etc.) N
>>>sessionType String 0...1 Ipv4, ipv6, etc. N
>>>mptcp Boolean 0...1 Indicates whether to use MPTCP for the matching application N
>>fqdnList StringArray 0...1 FQDN list that can be routed to MEC applications by the DNS proxy N
>>appCharcs Structure 0...1 Characteristics of the application as defined below.The application characteristics relate to the system resources consumed by the application. Device application can use this information e.g. for estimating the cost of use of the application or for the expected user experience. Y
>>>memory String 0...1 The maximum size in Mbytes of the memory resource expected to be used by the MEC application instance in the MEC system. Y
>>>storage String 0...1 The maximum size in Mbytes of the storage resource expected to be used by the MEC application instance in the MEC system. Y
>>>latency String 0...1 The target round trip time in milliseconds supported by the MEC system for the MEC application instance Y
>>>bandwidth String 0...1 The required connection bandwidth in kbit/s for the use of the MEC application instance Y
>>>serviceCont String 0...1 Required service continuity mode for this application.Permitted values:0 = SERVICE_CONTINUITY_NOT_REQUIRED.1 = SERVICE_CONTINUITY_REQUIRED Y
>vendorSpecificExt String 0...1 Extension for vendor specific information (see note 1). Y
>>vendorId String 1 Vendor identifier.The length of the value shall not exceed 32 characters.The rest of the structure of vendor specific extension is not defined. Y
NOTE 1: The vendor specific extension allows submitting information on the application lists that have been made available to the device application of the corresponding vendor.NOTE 2: The language support may be limited. The length of the value shall not exceed 128 characters.
<표 2>에 예시한 바와 같이, 다양한 실시예들에 따른 앱 리스트 응답 파라미터는, ETSI MEC 규격에서 정의되어 있는 파라미터 외에, 예를 들어, referenceURI, clientAppName, clientAppPackageURL, uriTTL, uriLOC, carpRule, DNN, S-NSSAI, accessType, sessionType, mptcp, 또는 fqdnList 중 적어도 하나를 포함할 수 있다.
일 실시 예에 따르면, <표 1> 및 <표 2>에 개시된 정보 이외에도, MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보는, 전자 장치(101)가 현재 접속된 기지국의 ID(identifier), 주변 기지국의 ID, GPS 정보, TA(tracking area) 정보, 또는 Wi-Fi ID 중 적어도 하나의 위치 정보에 대응하여 이용 가능한 적어도 하나의 정보를 포함할 수 있다. 일 실시예에 따르면, MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보는 어플리케이션이 요구하는 전자 장치(101)의 상태에 관한 정보(예: 전자 장치(101)의 이동(또는 움직임) 속도, 스크린 ON/OFF, 배터리 레벨, 기지국 수신 신호 세기, 타임 아웃 정보, 또는 전자 장치(101)와 MEC 호스트 간의 거리 정보 중 적어도 하나 이상의 조합)에 대응하여 이용 가능한 적어도 하나의 정보를 포함할 수 있다.
일 실시예에 따르면, MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보는 MEC 시스템(405)이 제공 가능한 어플리케이션의 도메인 이름(domain name)을 포함할 수 있다. 전자 장치(101)는 도메인 이름을 이용하여 MEC 어플리케이션에 접근(access)할 수 있다. 일 실시예에 따라, 전자 장치(101)가 도메인 이름을 이용하는 실시 예에 대하여 후술하는 도면(예: 도 36 내지 40)을 참조하여 설명된다.
일 실시예에 따르면, MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보는 MEC 시스템(405)(또는 MEC 호스트(447) 또는 MEC 어플리케이션(예: 460-1, 460-2)의 IP 주소를 더 포함할 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 LADN 전용(dedicated) PDU 세션의 설정(establishment)에 연계하여 MEC 디스커버리 절차를 수행할 수 있다. 예를 들어, MEC 서비스 모듈(410)은 PDU 세션(예: LADN 전용 세션)이 설정된 경우에 MEC 디스커버리 절차를 수행할 수도 있고, MEC 디스커버리 절차를 수행하여 적합한 결과(예: 지정된 어플리케이션의 이름 또는 앱 리스트)를 수신한 경우에 PDU 세션(예: LADN 전용 세션)을 설정할 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 디스커버리 절차를 수행하지 않고 동작 2007을 바로 수행할 수도 있다. 예를 들어, MEC 서비스 모듈(410)은 가용 어플리케이션의 앱 리스트가 전자 장치(101)에 이미 저장되어 있고, 앱 리스트를 업데이트 하는 지정된 주기가 지나지 않았거나 업데이트 요청이 없는 경우, 디스커버리 절차를 수행하지 않을 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 디스커버리 절차를 수행하기 이전에 전자 장치(101)가 접속된 네트워크에서 MEC 기반 데이터 전송이 가능한지 여부를 확인하는 동작을 더 포함할 수 있다. 일 실시예에 따르면, 도 20에서는 도시되지 않았지만, MEC 서비스 모듈(410)은 전자 장치(101)의 이동성과 관련된 이벤트가 감지되기 이전 또는 감지된 이후에 전자 장치(101)의 컨텍스트 정보를 모니터링 할 수도 있다. 예를 들어, MEC 서비스 모듈(410)은 동작 2001 이전, 동작 2001 이후, 동작 2003 이후, 또는 동작 2005 이후에 컨텍스트 정보를 모니터링 할 수 있다. 일 실시예에 따르면, 컨텍스트 정보는 전자 장치(101)의 어플리케이션 프로세서(AP)(예: 도 1의 프로세서(120))가 지속적으로 활성화된 상태에서 모니터링 될 수 도 있고, 동작 2001 또는 동작 620과 같은 조건이 만족됨을 감지하는 별도의 모듈(예: 도 1 의 통신 모듈(190) 또는 센서 모듈(176) 중 적어도 하나)이 MEC 서비스 모듈(410)에게 메시지를 전달할 수 있다.
일 실시예에 따르면, 동작 2007에서, MEC 서비스 모듈(410)은 앱 리스트 또는 모니터링된 컨텍스트 정보 중 적어도 하나에 기반하여 전자 장치(101)에 설치된 어플리케이션들 중에서 적어도 하나의 어플리케이션(예: 클라이언트 어플리케이션(510))이 MEC에 기반한 데이터 전송을 이용할 수 있는 조건(예: 제1 조건)을 만족함을 결정할 수 있다. 예를 들어, MEC 서비스 모듈(410)은 (1) 수신된 앱 리스트 중 MEC에 기반한 데이터 전송이 이용 가능한 어플리케이션에 대응하는 어플리케이션이 전자 장치(101)에 있거나, (2) 전자 장치(101)가 현재 접속된 기지국의 ID, 주변 기지국의 ID, GPS 정보, TA 정보, Wi-Fi ID 중 적어도 하나의 위치 정보에 대응하여 이용 가능한 적어도 하나의 어플리케이션이 있거나, 또는 (3) 전자 장치(101)의 상태에 관한 정보에 대응하여 이용 가능한 적어도 하나의 어플리케이션이 있는 경우 제1 조건이 만족되는 것으로 결정할 수 있다. (3) 조건과 관련하여, MEC 서비스 모듈(410)은 동작 2005에서 수신한 ‘어플리케이션이 사용 가능한 전자 장치(101)의 상태에 관한 정보’(예: 전자 장치(101)의 이동 속도, 스크린 ON/OFF, 배터리 레벨, 기지국 수신 신호 세기, 타임 아웃 정보 중 적어도 하나 이상의 조합)에 대응하는 이용 가능한 적어도 하나의 어플리케이션이 있는 경우 제1 조건이 만족되는 것으로 결정할 수 있다. 예를 들어, 제1 어플리케이션(예: 도 3의 제1 App(310-1))은 ‘전자 장치(101)의 이동성 없는 상태의 약 1분 이상 지속, 스크린 ON, 기지국 신호 세기가 임계값 이상(예: 양호)이라고 판단될 때’와 같은 전자 장치(101)의 상태 정보를 요구할 수 있다. 예를 들어, 제2 어플리케이션(예: 도 3의 제2 App(310-2))은 ‘스크린 ON, 배터리 레벨 임계값(예: 30%) 이상’과 같은 전자 장치(101)의 상태 정보를 요구할 수 있다. MEC 서비스 모듈(410)은 전자 장치(101)의 상태가 각 어플리케이션들이 요구하는 상태 정보에 부합할 때 제1 조건이 만족되는 것으로 결정할 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 동작 2007을 수행하지 않고 바로 동작 2009를 수행할 수도 있다.
일 실시예에 따르면, 동작 2009에서, MEC 서비스 모듈(410)은 클라이언트 어플리케이션(510)에게 MEC 기반 데이터 전송이 이용 가능 함을 나타내는 알림 메시지를 전송할 수 있다. 일 실시예에 따르면, MEC 기반 데이터 전송이 이용 가능 한 어플리케이션(예: 클라이언트 어플리케이션(510))이 전자 장치(101)에 설치되지 않은 경우, MEC 서비스 모듈(410)은 어플리케이션 레이어(446)에게 어플리케이션의 설치(또는 저장)를 가이드 하는 메시지를 전송할 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 동작 2009를 수행하지 않을 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 전자 장치(101)의 디스플레이(예: 도 1의 표시 장치(160)) 상에서 특정 어플리케이션의 MEC 기반 데이터 전송이 이용 가능함을 나타내는 GUI(graphic user interface)를 해당 어플리케이션의 아이콘 상에 표시할 수 있다. 다른 실시예에 따르면, MEC 서비스 모듈(410)은 MEC 기반 데이터 전송이 이용 가능한 어플리케이션의 MEC 성능(예: 신호 세기)을 표시할 수 있다. 신호 세기는, 예를 들어, ‘good’, ‘normal’, 또는 ‘bad’로 표시될 수 있다.
동작 2011에서, MEC 서비스 모듈(410)은 MEC 시스템(405)에 포함되는 MEC 어플리케이션을 실행하기 위한 요청(예: 컨텍스트 생성(context create))을 할 수 있다. 일 실시예에 따르면, 도 20에서는 도시되지 않았지만, MEC 서비스 모듈(410)뿐만 아니라 클라이언트 어플리케이션(510)에서도 컨텍스트 생성(context creation)을 수행할 수 있다.
일 실시예에 따르면, 클라이언트 어플리케이션(510)이 전자 장치(101)에서 실행되거나, 또는 클라이언트 어플리케이션(510)이 MEC 어플리케이션의 도메인 이름(예: URI(uniform resource identifier))에 대한 접근을 요청하면, MEC 서비스 모듈(410)은 컨텍스트 생성을 수행할 수 있다. 다른 예를 들어, MEC 서비스 모듈(410)은 지정된 주기에 따라 컨텍스트 생성을 수행할 수 있다. 다른 예를 들어, MEC 서비스 모듈(410)은 전자 장치(101)의 이동성과 관련된 이벤트가 감지되면 컨텍스트 생성을 수행할 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 MEC 제어 평면 상에서 MEC 시스템(405)(예: MMP 서버(430)와 컨텍스트 생성을 수행할 수 있다. MEC 서비스 모듈(410)이 컨텍스트 생성을 통해 MEC 어플리케이션의 실행을 요청하면, MEC 시스템(405)(예: MEP 매니저(445))은 MEC 어플리케이션을 실행할 수 있다. 일 실시예에 따라, MEC 시스템(405)(예: MEC 호스트(447))에 MEC 어플리케이션이 설치되지 않은 경우, MEC 시스템(405)(예: MEP 매니저(445))은 MEC 어플리케이션을 설치한 후 실행할 수 있다.
일 실시예에 따르면, 동작 2013에서, 클라이언트 어플리케이션(410)은 MEC 시스템(405)과 데이터 전송을 수행할 수 있다. 예를 들어, 클라이언트 어플리케이션(410)은 사용자 평면 상에서 MEC 시스템(405)의 MEC 어플리케이션(예: 460-1 또는 460-2)와 데이터 통신을 수행할 수 있다. 일 실시예에 따르면, 동작 2013에서 송수신되는 데이터 패킷은 사용자 데이터를 포함하는 제2 데이터 패킷으로서, 클라이언트 어플리케이션(410)(또는 MEC 어플리케이션)과 관련된 제2 주소를 포함할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)이 동작 2013 이전에 MEC 호스트(447)(또는 MEC 어플리케이션)의 IP 주소를 획득하는 경우, 클라이언트 어플리케이션(410)은 획득된 IP 주소를 이용하여 데이터 전송을 수행할 수 있다. MEC 호스트(447) 또는 MEC 어플리케이션의 IP 주소를 획득하는 실시예는 도 37 내지 도 39에서 후술된다. 일 실시예에 따르면, 클라이언트 어플리케이션(410)은 어플리케이션 레이어(예: 도 3의 사용자 평면) 상에서 HTTP(hypertext transfer protocol)에 기반한 데이터 전송을 수행할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는 HTTP 이외에도 다른 프로토콜에 기반하여 데이터 전송을 수행할 수 있다. 예를 들어, 전자 장치(101)는 RPC(remote procedure call) 프로토콜에 기반하거나, 어플리케이션 레이어(446)의 하위 레이어(예: TCP/IP(transmission control protocol/internet protocol) 또는 UDP/IP(user datagram protocol/internet protocol))에 기반하여 데이터 전송을 수행할 수 있다.
도 20에서는 도시되지 않았지만, MEC 서비스(410)은 전자 장치(101)가 지정된 지역을 벗어남을 감지한 것에 응답하여 MEC 어플리케이션의 종료(예: 컨텍스트 삭제(context delete))를 요청할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 상술한 다양한 방법을 통해 MEC 서비스 모듈(410)이 복수의 어플리케이션들의 MEC 기반 데이터 전송을 지정된 조건에 따라 통합적으로 트리거링 하도록 함으로써, 개별적인 데이터 전송으로 인한 전자 장치(101)의 부하를 줄일 수 있다.
일 실시예에 따르면, 전자 장치(101)는 기업(enterprise) 또는 학교로부터 MEC 기반 서비스를 제공받을 수 있다. 전자 장치(101)가 전자 장치(101)의 이동성과 관련된 이벤트를 감지하면(예: 동작 2001), 전자 장치(101)는 MEC 디스커버리 절차(예: 동작 2003 내지 동작 2005)를 통해 기업 또는 학교에서 제공되는 MEC 기반 서비스(또는 MEC 기반 데이터 전송을 지원하는 어플리케이션)을 식별(identify)할 수 있다. 전자 장치(101)는 위치 측정 기술(예: 셀룰러, 위성, 또는 Wi-Fi에 기반한 위치 측정 기술) 또는 센서 모듈(176) 중 적어도 하나를 이용하여 결정된 전자 장치(101)의 위치(예: 기업 또는 학교 내부)에서 이용 가능한 MEC 어플리케이션이 존재함을 감지할 수 있다(예: 동작 2007). 다른 예를 들어, 전자 장치(101)는 기업(또는 학교) 내부에 설치된 비콘(beacon) 장치로부터 비콘 신호를 수신하거나, NFC(near field communication) 태깅(tagging)을 통해 전자 장치(101)가 이용 가능한 MEC 어플리케이션이 존재함을 감지할 수 있다. MEC 서비스 모듈(410)은 기업 또는 학교에서 MEC 기반 데이터 전송을 수행할 수 있는 어플리케이션에게 알림 메시지를 전송할 수 있다(예: 동작 2009). 알림 메시지를 수신한 어플리케이션은 전자 장치(101)에서 자동적으로 실행되거나, 해당 어플리케이션이 이용 가능함을 나타내는 사용자 인터페이스를 디스플레이(예: 도 1의 표시 장치(160))를 통해 표시할 수 있다. 어플리케이션이 실행되면, 전자 장치(101)는 MEC에 기반한 데이터 전송을 통해 기업 또는 학교로부터 서비스를 제공받을 수 있다(예: 동작 2013).
다른 실시예에 따르면, 전자 장치(101)는 광고 또는 쿠폰을 제공하는 장소(예: 백화점 또는 쇼핑몰)로부터 MEC 기반 서비스를 제공받을 수 있다. 전자 장치(101)가 지정된 지역에 진입하면(예: 동작 2001), 전자 장치(101)는 MEC 디스커버리 절차(예: 동작 2003 내지 동작 2005)를 통해 백화점 또는 쇼핑몰에서 제공되는 MEC 기반 서비스를 식별할 수 있다. 전자 장치(101)는 위치 측정 기술 또는 센서 모듈(176) 중 적어도 하나를 이용하여 결정된 전자 장치(101) 위치(예: 백화점(또는 쇼핑몰)의 특정 구역)에서 이용 가능한 MEC 어플리케이션이 존재함을 감지할 수 있다(예: 동작 2007). MEC 서비스 모듈(410)은 백화점 또는 쇼핑몰에서 MEC 기반 데이터 전송을 수행할 수 있는 어플리케이션에게 알림 메시지를 전송하고(예: 동작 2009), 알림 메시지를 수신한 어플리케이션은 광고 또는 쿠폰을 팝업 형태로 표시할 수 있다.
다른 실시예에 따르면, 전자 장치(101)는 게임 서비스를 제공받을 수 있다. 전자 장치(101)가 지정된 지역에 진입하면(예: 동작 2001), 전자 장치(101)는 MEC 디스커버리 절차(예: 동작 2003 내지 동작 2005)를 통해 게임 어플리케이션들에 관한 정보를 획득할 수 있다. 전자 장치(101)는 <표 1>에 개시된 정보에 적어도 기반하여 MEC 시스템(405)(예: MEC 서버)에서 제공되는 게임 어플리케이션 중 전자 장치(101)에 설치된 게임 어플리케이션이 요구하는 기준(예: 메모리, 지연 시간, 또는 주파수 대역)을 만족하는 게임 어플리케이션을 결정할 수 있다(예: 동작 2007). 다른 예를 들어, 전자 장치(101)에 설치된 게임 어플리케이션이 전자 장치(101)의 움직임을 요구하면, 전자 장치(101)는 전자 장치(101)의 움직임을 감지할 수 있다. MEC 서비스 모듈(410)은 게임 어플리케이션에게 알림 메시지를 전송하고(예: 동작 2009), 게임 어플리케이션이 실행되면, 전자 장치(101)는 MEC에 기반한 데이터 전송을 통해 서비스를 제공받을 수 있다(예: 동작 2013).
도 21은 다양한 실시 예들에 따른 전자 장치(101)에서 디스커버리 절차를 위한 동작 방법을 도시하는 흐름도이다.
다양한 실시예들에서, 도 21에 도시된 동작들은, 예를 들어, 전자 장치(101) 또는 전자 장치(101)에 포함된 구성 요소(예: 도 1의 프로세서(120) 또는 도 4의 MEC 서비스 모듈(410))에 의하여 수행될 수 있다.
도 21을 참조하면, 동작 2101에서, 전자 장치(101)는 전자 장치(101)의 이동성과 관련된 이벤트를 감지할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 전자 장치(101)가 연결된 기지국(예: 도 3의 AN(302))로부터 수신된 위치 정보(예: LADN ID, TA ID, 기지국 ID, 또는 cell ID 중 적어도 하나)에 기반하거나, 위치 측정 기술에 기반하거나, 또는 전자 장치(101)에 실장된 별도의 센서 모듈(176)을 통해 이동성과 관련된 이벤트를 감지할 수 있다.
동작 2103에서, 전자 장치(101)는 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보(예: 앱 리스트)를 요청할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MMP 서버(430)에게 앱 리스트를 요청할 수 있다.
동작 2105에서, 전자 장치(101)는 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보를 수신할 수 있다. MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보는, 예를 들어, <표 1>에 개시된 정보, 전자 장치(101)가 현재 접속된 기지국의 ID(identifier), 주변 기지국의 ID, GPS 정보, TA 정보, 또는 Wi-Fi ID 중 적어도 하나의 위치 정보에 대응하여 이용 가능한 적어도 하나의 어플리케이션, 전자 장치(101)의 상태에 관한 정보에 대응하여 이용 가능한 적어도 하나의 어플리케이션, 또는 도메인 이름에 대한 MEC 호스트(447)의 IP 주소 중 적어도 하나를 포함할 수 있다.
동작 2107에서, 전자 장치(101)는 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보 또는 컨텍스트 정보 중 적어도 하나에 기반하여 전자 장치(101)에 설치된 어플리케이션(예: 클라이언트 어플리케이션(510))이 MEC에 기반한 데이터 전송을 수행할 수 있는 제1 조건을 만족하는지 결정할 수 있다.
동작 2109에서, 전자 장치(101)는 제1 조건을 만족하는 어플리케이션을 통해 데이터 전송을 수행할 수 있다. 예를 들어, 제1 조건을 만족하는 어플리케이션은 MEC 시스템(405)(예: MEC 서버)에 설치된 MEC 어플리케이션과 어플리케이션 레이어 상에서 데이터 전송을 수행할 수 있다.
도 22는 다양한 실시예들에 따른 전자 장치(101)에서 디스커버리 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 22를 참조하면, 동작 2201에서, 전자 장치(101)의 프로세서(120)(또는 도 4의 MEC 서비스 모듈(410))는 MEC 디스커버리 정책(discovery policy)을 MEC 시스템(405)으로부터 획득(또는 수신)할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 MEC 시스템(405)으로부터 MEC 디스커버리 정책을 수신하고, MSE(530)로 MEC 디스커버리 정책을 전달할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 MSA(520)를 이용하여 MEC 디스커버리 정책을 획득하고, MSE(530)를 이용하여 수신된 MEC 디스커버리 정책에 기반한 디스커버리 절차를 수행할 수 있다. 예를 들어, 전자 장치(101)의 MSE(530)는 MSA(520)로부터 MSE API를 통해 MEC 디스커버리 정책을 수신할 수 있다. 일 실시예에 따르면, MEC 디스커버리 정책은 <표 1>에 예시한 바와 같은 파라미터를 포함할 수 있다. 예를 들어, MEC 디스커버리 정책은 클라이언트 어플리케이션 이름(예: clientAppNames), 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType), 컨텍스트 타입(contextType), 어플리케이션 URI 요청(예: URI Request), 또는 동적(dynamic) DNN(예: dynamicDnn) 중 적어도 하나를 포함할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션 이름은 MEC 사용 가능 여부를 확인하기 위한 앱 리스트를 요청하기 위한 정보일 수 있고, 위치는 전자 장치(101)의 현재 위치에 따른 위치 기반 앱 리스트를 요청하기 위한 정보일 수 있고, 동적 DNN은 동적 DNN 업데이트(dynamic DNN update) 사용 여부를 확인하기 위한 정보일 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 디스커버리 정책에 디바이스 타입과 서비스 타입을 포함하여, 각 타입에 대응하는 앱 리스트를 요청할 수 있고, 또한 컨텍스트 타입을 포함하여 어플리케이션의 컨텍스트 필요 여부를 전달할 수도 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 디스커버리 정책에 어플리케이션 URI 요청을 포함하여 MEC 어플리케이션의 URI가 가용할 경우 앱 리스트에 URI를 포함하도록 요청할 수도 있다.
동작 2203에서, 프로세서(120)는 MEC 디스커버리 정책에 기반하여, 지정된 외부 서버(예: MMP 서버(430))로부터 서비스 가능한 MEC 어플리케이션의 앱 리스트를 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 MSA(520)로부터 수신된 MEC 디스커버리 정책에 기반하여 앱 리스트를 획득하기 위한 획득 절차(예: MEC Application Look-up)를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 디스커버리 정책에 따라 서비스 가능한 MEC 어플리케이션에 관련된 앱 리스트를 MMP 서버(430)로 요청하여 수신할 수 있다.
동작 2205에서, 프로세서(120)는 클라이언트 어플리케이션(510)의 어플리케이션 컨텍스트를 생성(예: Appliction Context Create)할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 MEC 시스템(405)에 포함되는 MEC 어플리케이션을 실행하기 위한 요청(예: 컨텍스트 생성(context create))을 할 수 있다. 일 실시예에 따르면, 도 22에서는 도시되지 않았지만, MEC 서비스 모듈(410)뿐만 아니라 클라이언트 어플리케이션(510)에서도 컨텍스트 생성(context creation)을 수행할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 MSA(520)에 의해 자체적으로 클라이언트 어플리케이션(510)의 실행을 감지할 수 있고, MSA(520) 또는 MSE(530)가 제공하는 Context Create API를 통해 클라이언트 어플리케이션(510)이 해당 API를 호출(call)할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(510)은 MSA(520)로 App Launch Detected 또는 API(예: Context Create API) call을 제공(또는 전달)할 수 있다. App Launch Detected는, 예를 들어, 클라이언트 어플리케이션(510)이 실행되는 경우를 나타낼 수 있다. API(Context Create) call은, 예를 들어, 접속하고자 하는 MEC 어플리케이션 이름(예: MEC App Name)에 대한 URI를 요청하는 경우를 나타낼 수 있다. 일 실시예에 따르면, MSA(520)는 App Launch Detected 또는 API(Context Create) call를 수신하면, 클라이언트 어플리케이션(510)의 상태(state)를 통지(notify)하는 상태 통지 메시지(예: notifyClientAppState)를 MSE(530)로 제공할 수 있다. 일 실시예에 따라, 상태 통지 메시지는, 예를 들어, 클라이언트 어플리케이션의 상태(예: START)와 클라이언트 어플리케이션의 이름(예: clientAppName)(및/또는 UID)을 포함(예: notifyClientAppState(START, clientAppName))하여 제공할 수 있다. 일 실시예에 따르면, MSA(520)는 클라이언트 어플리케이션(510) 실행을 감지하는 경우 MSE API 호출에 의하여, 클라이언트 어플리케이션)510)의 실행 상태를 MSE(530)에 통지할 수 있다.
동작 2207에서, 프로세서(120)는 클라이언트 어플리케이션(510)의 실행을 감지하면, 앱 리스트에 기반하여, 클라이언트 어플리케이션(510)과 연관되고 접속하고자 하는 MEC 어플리케이션에 관련된 정보를 지정된 외부 서버(예: MMP 서버(430))로부터 획득할 수 있다. MEC 어플리케이션에 관련된 정보는, 예를 들어, MEC 어플리케이션 이름(MEC App Name)에 대한 URI, 전용 DNN(dedicated DNN) 정보, 또는 MEC 어플리케이션 패키지(package) URI(예: MEC 어플리케이션이 없는 경우) 중 적어도 하나를 포함할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 MSA(520)로부터 상태 통지 메시지를 수신하고, 수신된 상태 통지 메시지에 기반하여 MEC 어플리케이션(또는 해당 MEC 어플리케이션을 포함하는 MEC 호스트(예: 엣지 서버 또는 MEC 서버))을 발견(또는 탐색, 확인)하기 위한 절차(예: 어플리케이션 컨텍스트 생성(application context create))를 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은 MSA(520)가 클라이언트 어플리케이션(510) 실행을 감지하는 경우 MSE API 호출에 의하여 활성화 될 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, 클라이언트 어플리케이션(510)이 컨텍스트 생성(context create) API 호출 시에 활성화 될 수 있다.
동작 2209에서, 프로세서(120)는 획득된 정보에 기반하여, MEC 호스트(Host)를 선택할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 DNS 서버와 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, 호스트 선택 절차는 미리 설정된 정보 및/또는 DNS 서버로 문의한 정보를 이용하여 결정하거나, 또는 DNS 서버로 문의한 정보 및/또는 사용자에게 문의하여 특정한 MEC 호스트를 선택(또는 설정)하도록 할 수 있다.
동작 2211에서, 프로세서(120)는 선택된 MEC 호스트와 데이터 전송을 수행할 수 있다. 예를 들어, 클라이언트 어플리케이션(510)은 MEC 시스템(405)(예: MEC 서버)에 설치된 MEC 어플리케이션과 어플리케이션 레이어 상에서 데이터 전송을 수행할 수 있다.
도 23은 다양한 실시예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 23에 도시한 바와 같이, 도 23은 어플리케이션 상태 기반(App state-based)의 MEC 디스커버리 절차의 예를 나타낼 수 있다. 일 실시예에 따르면, 전자 장치(101)는 클라이언트 어플리케이션(또는 Client App)(510), MSA(또는 서비스 에이전트)(520), MSE(또는 서비스 인에이블러)(530)(예: MEL(531), UHL(533) 포함), 및 DNS 캐시(cache)(2310)를 포함할 수 있다.
도 23을 참조하면, 동작 2301에서, 전자 장치(101)의 MSA(520)는 MSE(530)로 MEC 디스커버리 정책(discovery policy)을 설정할 수 있다. 일 실시예에 따르면, MEC 디스커버리 정책은 클라이언트 어플리케이션 이름(예: clientAppNames)과 디스커버리 정책(예: discoveryPolicy)을 포함하여 제공할 수 있다. 일 실시예에 따라, discoveryPolicy에는 동적 DNN(예: dynamicDnn)의 사용 여부가 포함될 수 있고, 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType), 또는 컨텍스트 타입(예: contextType)과 같은 <표 1>의 정보 중 적어도 하나를 포함하여 제공할 수 있다. 일 실시예에 따르면, MSA(520)는 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType)을 discoveryPolicy에 포함하여 앱 리스트를 해당 조건에 맞는 리스트만 한정하여 수신하도록 할 수도 있다. 일 실시예에 따르면, MSA(520)는 컨텍스트 타입(예: contextType)을 discoveryPolicy에 포함하여 어플리케이션 컨텍스트(application context)가 필요한지 여부에 대한 정보를 포함할 수 있다. 일 실시예에 따르면, MSA(520)는 URI Request Flag를 discoveryPolicy에 포함하여 MEC 어플리케이션의 URI가 가용한 경우 앱 리스트에 URI 포함하도록 요청할 수도 있다. 일 실시예에 따라, 클라이언트 어플리케이션 이름(clientAppNames)은 MEC 사용 가능 여부를 확인하기 위한 앱 리스트를 요청하기 위한 정보일 수 있고, 위치(locationInfo)는 전자 장치(101)의 현재 위치에 따른 위치 기반 앱 리스트를 요청하기 위한 정보일 수 있고, 동적 DNN(dynamicDnn)은 동적 DNN 업데이트(dynamic DNN update) 사용 여부를 확인하기 위한 정보일 수 있다.
동작 2303에서, MSE(530)는 MSA(520)로부터 수신된 정보(예: MEC 디스커버리 정책)에 기반하여 앱 리스트(예: AppList)를 획득하기 위한 획득 절차(예: MEC Application Look-up)를 수행할 수 있다. 일 실시예에 따르면, MSA(520)와 MSE(530) 간에 MEC 디스커버리 정책 설정에 따라 앱 리스트를 획득하기 위한 획득 절차(예: MEC Application Look-up)가 시작될 수 있다. 일 실시예에 따르면, MSE(530)는 MSA(520)로부터 MSE API를 통해 MEC 디스커버리 정책을 수신하는 경우 MEC Application Look-up을 활성화 할 수 있고, 전자 장치(101)의 특정 조건(예: 전자 장치(101)가 움직이는 중 접속 기지국 Cell ID 변경) 만족 시 수행(또는 시작)할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 디스커버리 정책에 따라 서비스 가능한 MEC 어플리케이션(예: MEP App)에 관련된 앱 리스트(예: MEC AppList)를 MMP 서버(430)로 요청하여 수신할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 디스커버리 정책을 <표 1>에 예시한 바와 같은 MEC AppList request message Parameter에 기입하여 MMP 서버(430)에 요청할 수 있고, MMP 서버(430)는 그에 맞는 서비스 가능 앱 리스트(예: <표 2>의 MEC AppList)를 MSE(530)로 제공하여, MSE(530)의 요청에 응답할 수 있다. 다양한 실시예들에 따른 앱 리스트 획득 절차(예: MEC Application Look-up)에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 2305에서, 클라이언트 어플리케이션(510)은 MSA(520)로 App Launch Detected 또는 API(Context Create) call을 제공(또는 전달)할 수 있다. 일 실시예에 따르면, App Launch Detected의 경우는 클라이언트 어플리케이션(510)이 실행되는 경우를 나타낼 수 있다. 일 실시예에 따르면, API(Context Create) call은 접속하고자 하는 MEC 어플리케이션 이름(예: MEC App Name)에 대한 URI를 요청하는 경우를 나타낼 수 있다.
동작 2307에서, MSA(520)는 App Launch Detected 또는 API(Context Create) call를 수신하면, 클라이언트 어플리케이션(510)의 상태(state)를 통지(notify)하는 통지 메시지(예: notifyClientAppState)를 MSE(530)로 제공할 수 있다. 일 실시예에 따라, 통지 메시지(예: notifyClientAppState)는, 예를 들어, 클라이언트 어플리케이션의 상태(예: START)와 클라이언트 어플리케이션의 이름(예: clientAppName)(및/또는 UID)을 포함(예: notifyClientAppState(START, clientAppName))하여 제공할 수 있다.
동작 2309에서, MSE(530)는 MSA(520)로부터 통지 메시지(예: notifyClientAppState)를 수신하고, 수신된 통지 메시지에 기반하여 MEC 어플리케이션(또는 해당 MEC 어플리케이션을 포함하는 MEC 호스트(예: 엣지 서버 또는 MEC 서버))을 발견(또는 탐색, 확인)하기 위한 절차(예: 어플리케이션 컨텍스트 생성(application context create))를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MSA(520)로부터 클라이언트 어플리케이션(510)의 실행과 관련된 이벤트(event)를 수신하는 경우 어플리케이션 컨텍스트 생성을 활성화 할 수 있다. 일 실시예에 따르면, MSE(530)는 수신된 통지 메시지(예: notifyClientAppState)의 정보에 기반하여 MMP 서버(430)를 통해 원하는 MEC 어플리케이션을 포함하는 MEC 호스트를 찾기 위한 어플리케이션 컨텍스트 생성 동작을 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, MSA(520)가 클라이언트 어플리케이션(510) 실행을 감지하는 경우 MSE API 호출에 의하여 활성화(또는 수행)될 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, 클라이언트 어플리케이션(510)이 컨텍스트 생성(context create) API 호출 시에 활성화(또는 수행)될 수 있다. 일 실시예에 따르면, MSE(530)는 접속하고자 하는 MEC 어플리케이션 이름(예: MEC App Name)에 대한 URI를 MMP 서버(430)로 요청 및 수신할 수 있다. 일 실시예에 따라, MSE(530)는 필요에 따라 전용 DNN(dedicated DNN)에 대한 정보를 MMP 서버(430)에 요청 및 수신할 수도 있다. 일 실시예에 따르면, MMP 서버(430)는 해당 MEC 어플리케이션이 없는 경우에는 MEC 어플리케이션 패키지(package) URI를 MSE(530)로 전달할 수도 있다. 다양한 실시예들에 따른 어플리케이션 컨텍스트 생성 절차에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 2311에서, MSE(530)는 DNS 서버(2320)와 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP 서버(430)를 통해 획득한 MEC 호스트가 적어도 둘 이상인 경우, DNS 서버(2320)와 어느 하나의 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, MEC 호스트가 둘 이상인 경우 하나의 MEC 호스트를 선택하기 위한 호스트 선택 절차는 미리 설정된 정보 및/또는 DNS 서버(2320)로 문의한 정보를 이용하여 결정하거나, 또는 DNS 서버(2320)로 문의한 정보 및/또는 사용자에게 문의하여 특정한 MEC 호스트를 선택(또는 설정)하도록 할 수 있다. 일 실시예에 따르면, MSE(530)가, MEC 호스트가 둘 이상인 경우 특정한 MEC 호스트를 설정하기 위한 미리 설정된 정보는 우선순위 정보를 포함할 수 있다. 일 실시예에 따르면, 호스트 선택 절차는 DNS 프리 리졸빙(Pre-resolving) 동작과 MEC 호스트 우선순위 결정(MEC Host Prioritization) 동작을 포함할 수 있다. 일 실시예에 따라, DNS Pre-resolving는, 예를 들어, 클라이언트 어플리케이션(510)의 DNS 쿼리(query)와 상관 없이 MSE(530) 자체적으로 MEC용 FQDN((fully qualified domain name))에 대해 DNS 리졸빙을 수행하는 것을 포함할 수 있다. 일 실시예에 따라, DNS 리졸빙은, 동작 2303의 MEC Application Look-up 단계 또는 동작 2309의 Application Context Creat 단계를 통해 수신한 URI 또는 도메인 이름(domain name)이 사용하여 수행될 수 있다. 일 실시예에 따라, MEC Host Prioritization는, 예를 들어, DNS 쿼리 응답(query response)으로 복수 개의 IP 주소가 수신되는 경우 IP 우선순위를 설정하는 것을 포함할 수 있다. 다양한 실시예들에 따른 호스트 선택 절차(예: MEC Host Selection)에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 2313에서, 클라이언트 어플리케이션(510)은 이상의 동작을 통해 획득한 정보를 이용하여 DNS 리졸빙(Resolving) 동작을 수행할 수 있다. 일 실시예에 따르면, DNS 리졸빙은, 예를 들어, 클라이언트 어플리케이션(510)의 DNS 쿼리 발생 시 수행할 수 있다. 일 실시예에 따르면, DNS 리졸빙은, 예를 들어, Client-driven normal DNS resolving 또는 DNS proxying (hooking DNS query)를 포함할 수 있다. 다양한 실시예들에 따른 DNS 리졸빙에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
도 24는 다양한 실시예들에 따른 전자 장치(101)에서 디스커버리 절차를 위한 동작 방법을 도시하는 흐름도이다.
도 24를 참조하면, 동작 2401에서, 전자 장치(101)의 프로세서(120)(또는 도 4의 MEC 서비스 모듈(410))는 MEC 디스커버리 정책(discovery policy)을 수신할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(520)는 MSE(530)로 MEC 디스커버리 정책을 설정할 수 있다. 예를 들어, 전자 장치(101)의 MSE(530)는 MSA(520)로부터 MSE API를 통해 MEC 디스커버리 정책을 수신할 수 있다. 일 실시예에 따르면, MEC 디스커버리 정책은 <표 1>을 참조한 설명 부분에서 설명한 바와 같은 정보(또는 파라미터) 중 적어도 하나를 포함할 수 있다.
동작 2403에서, 프로세서(120)는 MEC 디스커버리 정책에 기반하여, 지정된 외부 서버(예: MMP 서버(430))로부터 서비스 가능한 MEC 어플리케이션의 앱 리스트를 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 MSA(520)로부터 수신된 MEC 디스커버리 정책에 기반하여 앱 리스트를 획득하기 위한 획득 절차(예: MEC Application Look-up)를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 디스커버리 정책에 따라 서비스 가능한 MEC 어플리케이션에 관련된 앱 리스트를 MMP 서버(430)로 요청하여 수신할 수 있다.
동작 2405에서, 프로세서(120)는 클라이언트 어플리케이션(510)에 의해 발생되는 DNS 쿼리(query)를 감지하여 후킹(hooking)할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 클라이언트 어플리케이션(510)은 MSE(530)로 DNS 쿼리(query)를 위한 메시지(예: DNS query 메시지)를 전달할 수 있다. 일 실시예에 따라, DNS 쿼리는 클라이언트 어플리케이션(510)에서 발생할 수 있으며, 일반적으로, DNS 쿼리는 DNS 서버(2320)로 전달되어, DNS 서버(2320)에서 DNS 쿼리에 대한 응답을 제공할 수 있다. 다양한 실시예들에 따르면, DNS 쿼리는 전자 장치(101)의 MSE(530)(예: DHL(535))에 의해 감지할 수 있다. 예를 들어, 클라이언트 어플리케이션(510)에서 DNS 쿼리가 발생하는 경우, MSE(530)에서 발생된 DNS 쿼리를 감지하고, DNS 서버(2320)로 전달되기 이전에 가로채서(hooking), 후술하는 동작 2407(예: Context Create)과 후술하는 동작 2409(예: DNS resolving)을 수행하고, 이후 DNS 응답을 클라이언트 어플리케이션(510)으로 전달할 수 있다.
동작 2407에서, 프로세서(120)는 클라이언트 어플리케이션(510)에서 DNS 쿼리 메시지가 발생하면, 앱 리스트에 기반하여, 클라이언트 어플리케이션(510)과 연관되고 접속하고자 하는 MEC 어플리케이션에 관련된 정보를 지정된 외부 서버(예: MMP 서버(430))로부터 획득할 수 있다. MEC 어플리케이션에 관련된 정보는, 예를 들어, MEC 어플리케이션 이름(MEC App Name)에 대한 URI, 전용 DNN(dedicated DNN) 정보, 또는 MEC 어플리케이션 패키지(package) URI(예: MEC 어플리케이션이 없는 경우) 중 적어도 하나를 포함할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 클라이언트 어플리케이션(510)으로부터의 DNS 쿼리에 응답하여 MMP 서버(430)와 어플리케이션 컨텍스트 생성 동작을 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 클라이언트 어플리케이션(510)에서 DNS query (with FQDN) 메시지 발생 시 해당 MEC 어플리케이션에 대한 어플리케이션 컨텍스트 생성을 수행할 수 있다.
동작 2409에서, 프로세서(120)는 획득된 정보에 기반하여, MEC 호스트(Host)를 선택할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 DNS 서버(2320)와 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, 호스트 선택 절차는 미리 설정된 정보 및/또는 DNS 서버(2320)로 문의한 정보를 이용하여 결정하거나, 또는 DNS 서버(2320)로 문의한 정보 및/또는 사용자에게 문의하여 특정한 MEC 호스트를 선택(또는 설정)하도록 할 수 있다.
동작 2411에서, 프로세서(120)는 MEC 호스트 선택 후 클라이언트 어플리케이션으로 DNS 응답을 전달할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSE(530)는 클라이언트 어플리케이션(510)으로 이상의 절차들을 통해 획득한 정보를 DNS 응답(Response)으로 제공할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 호스트 선택 후, DNS 쿼리를 제공한 클라이언트 어플리케이션(510)으로, DNS 쿼리에 대응하는 DNS 응답(response)을 전달할 수 있다.
동작 2413에서, 프로세서(120)는 선택된 MEC 호스트와 데이터 전송을 수행할 수 있다. 예를 들어, 클라이언트 어플리케이션(510)은 MEC 시스템(405)(예: MEC 서버)에 설치된 MEC 어플리케이션과 어플리케이션 레이어 상에서 데이터 전송을 수행할 수 있다.
도 25는 다양한 실시예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 25에 도시한 바와 같이, 도 25는 DNS 쿼리 기반(DNS Query-based)의 MEC 디스커버리 절차의 예를 나타낼 수 있다. 일 실시예에 따르면, 전자 장치(101)는 클라이언트 어플리케이션(또는 Client App)(510), MSA(또는 서비스 에이전트)(520), MSE(또는 서비스 인에이블러)(530)(예: MEL(531), UHL(533) 포함), 및 DNS 캐시(cache)(2310)를 포함할 수 있다.
도 25를 참조하면, 동작 2501에서, 전자 장치(101)의 MSA(520)는 MSE(530)로 MEC 디스커버리 정책(discovery policy)을 설정할 수 있다. 일 실시예에 따르면, MEC 디스커버리 정책은 클라이언트 어플리케이션 이름(예: clientAppNames)과 디스커버리 정책(예: discoveryPolicy)을 포함하여 제공할 수 있다. 일 실시예에 따라, discoveryPolicy에는 동적 DNN(예: dynamicDnn)의 사용 여부가 포함될 수 있고, 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType), 또는 컨텍스트 타입(예: contextType)과 같은 <표 1>의 정보 중 적어도 하나를 포함하여 제공할 수 있다. 일 실시예에 따르면, MSA(520)는 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType)을 discoveryPolicy에 포함하여 앱 리스트를 해당 조건에 맞는 리스트만 한정하여 수신하도록 할 수도 있다. 일 실시예에 따르면, MSA(520)는 컨텍스트 타입(예: contextType)을 discoveryPolicy에 포함하여 어플리케이션 컨텍스트(application context)가 필요한지 여부에 대한 정보를 포함할 수 있다. 일 실시예에 따르면, MSA(520)는 URI Request Flag를 discoveryPolicy에 포함하여 MEC 어플리케이션의 URI가 가용한 경우 앱 리스트에 URI 포함하도록 요청할 수도 있다.
동작 2503에서, MSE(530)는 MSA(520)로부터 수신된 정보(예: MEC 디스커버리 정책)에 기반하여 앱 리스트(예: AppList)를 획득하기 위한 획득 절차(예: MEC Application Look-up)를 수행할 수 있다. 일 실시예에 따르면, MSA(520)와 MSE(530) 간에 MEC 디스커버리 정책 설정에 따라 앱 리스트를 획득하기 위한 획득 절차(예: MEC Application Look-up)가 시작될 수 있다. 일 실시예에 따르면, MSE(530)는 MSA(520)로부터 MSE API를 통해 MEC 디스커버리 정책을 수신하는 경우 MEC Application Look-up을 활성화 할 수 있고, 전자 장치(101)의 특정 조건(예: 전자 장치(101)가 움직이는 중 접속 기지국 Cell ID 변경) 만족 시 수행(또는 시작)할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 디스커버리 정책에 따라 서비스 가능한 MEC 어플리케이션(예: MEP App)에 관련된 앱 리스트(예: MEC AppList)를 MMP 서버(430)로 요청하여 수신할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 디스커버리 정책을 <표 1>에 예시한 바와 같은 MEC AppList request message Parameter에 기입하여 MMP 서버(430)에 요청할 수 있고, MMP 서버(430)는 그에 맞는 서비스 가능 앱 리스트(예: <표 2>의 MEC AppList)를 MSE(530)로 제공하여, MSE(530)의 요청에 응답할 수 있다. 다양한 실시예들에 따른 앱 리스트 획득 절차(예: MEC Application Look-up)에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 2505에서, 클라이언트 어플리케이션(510)은 MSE(530)로 DNS 쿼리(query)를 위한 메시지(예: DNS query 메시지)를 전달할 수 있다.
동작 2507에서, MSE(530)는 클라이언트 어플리케이션(510)으로부터의 DNS 쿼리에 응답하여 MMP 서버(430)와 Application Context Create 동작을 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 클라이언트 어플리케이션(510)에서 DNS query (with FQDN) 메시지 발생 시, FQDN 필터링(filtering)을 통해 MEC 용 FQDN 탐지 시, 해당 MEC 어플리케이션(예: MEC App)에 대한 Application Context Create를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 접속하고자 하는 MEC 어플리케이션 이름(예: MEC App Name)에 대한 URI를 MMP 서버(430)로 요청 및 수신할 수 있다. 일 실시예에 따라, MSE(530)는 필요에 따라 전용 DNN(dedicated DNN)에 대한 정보를 MMP 서버(430)에 요청 및 수신할 수도 있다. 일 실시예에 따르면, MMP 서버(430)는 해당 MEC 어플리케이션이 없는 경우에는 MEC 어플리케이션 패키지(package) URI를 MSE(530)로 전달할 수도 있다. 다양한 실시예들에 따른 Application Context Create 절차에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 2509에서, MSE(530)는 클라이언트 어플리케이션(510)으로부터의 DNS 쿼리에 응답하여 DNS 서버(2320)와 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP 서버(430)를 통해 획득한 MEC 호스트(예: 도 4의 MEC 호스트(447))가 적어도 둘 이상인 경우, DNS 서버(2320)와 어느 하나의 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, MEC 호스트가 둘 이상인 경우 하나의 MEC 호스트를 선택하기 위한 호스트 선택 절차는 미리 설정된 정보 및/또는 DNS 서버(2320)로 요청하여 수신한 정보(예: IP 주소, IP 별 location 정보)를 이용하여 결정하거나, 또는 DNS 서버(2320)로 요청하여 수신한 정보 및/또는 사용자에게 UI(user interface)(예: 선택 버튼)를 통하여 특정한 MEC 호스트를 선택(또는 설정)하도록 할 수 있다. 일 실시예에 따르면, MSE(530)가, MEC 호스트가 둘 이상인 경우 특정한 MEC 호스트를 설정하기 위한 미리 설정된 정보는 우선순위 정보를 포함할 수 있다. 일 실시예에 따르면, 우선순위 정보는, 예를 들어, 호스트 우선순위가 URI 별로 우선순위가 결정된 정보를 포함하거나, 또는 하나의 URI를 DNS 리졸빙(resolving)한 결과인 IP 주소가 복수개일 경우 해당 IP 주소 별 우선순위가 결정된 정보를 포함할 수 있다. 일 실시예에 따르면, 호스트 선택 절차는 DNS 리졸빙(resolving) 동작과 MEC 호스트 우선순위 결정(MEC Host Prioritization) 동작을 포함할 수 있다. 일 실시예에 따라, DNS resolving는, 예를 들어, 클라이언트 어플리케이션(510)의 DNS 쿼리(query)와 상관 없이 MSE(530) 자체적으로 MEC용 FQDN에 대해 DNS 리졸빙을 수행하는 것을 포함할 수 있다. 일 실시예에 따라, MEC Host Prioritization는, 예를 들어, DNS 쿼리 응답(query response)으로 복수 개의 IP 주소가 수신되는 경우 IP 우선순위를 설정하는 것을 포함할 수 있다. 일 실시예에 따라, 우선순위가 URI 별 또는 IP 별 미리 정해져 있을 수 있으며, 복수 개의 IP 주소가 수신되는 경우에는 수신된 복수의 IP 별 성능(performance) 테스트를 통해 그 결과에 따라 동적으로 IP 우선순위를 결정할 수도 있다. 다양한 실시예들에 따른 호스트 선택 절차(예: MEC Host Selection)에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 2511에서, MSE(530)는 이상의 절차들이 완료되면, 클라이언트 어플리케이션(510)으로 이상의 절차들을 통해 획득한 정보를 DNS 응답(Response)으로 제공할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 호스트 선택((예: DNS 리졸빙) 후, DNS 쿼리를 제공한 클라이언트 어플리케이션(510)으로, DNS 쿼리에 대응하는 DNS 응답(response)을 전달할 수 있다. 다양한 실시예들에 따른 DNS 응답에 대하여 후술하는 도면을 참조하여 설명된다.
도 26은 다양한 실시예들에 따른 전자 장치(101)에서 디스커버리 절차를 위한 동작 방법을 도시하는 흐름도이다.
다양한 실시예들에서, 도 26에 도시된 동작들은, 예를 들어, 전자 장치(101) 또는 전자 장치(101)에 포함된 구성 요소(예: 도 1의 프로세서(120) 또는 도 4의 MEC 서비스 모듈(410))에 의하여 수행될 수 있다.
도 26을 참조하면, 동작 2601에서, 전자 장치(101)는 디스커버리 정책에 기반하여 MEC 시스템(405)이 제공 가능한 MEC 어플리케이션들에 관한 정보(예: 앱 리스트)를 획득하기 위한 어플리케이션 룩업(Application Look-up) 동작을 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MMP 서버(430)에 앱 리스트를 요청하고 MMP 서버(430)로부터 앱 리스트를 획득(또는 수신)할 수 있다. 일 실시예에 전자 장치(101)의 MSE(530)는 MSA(520)로부터 MSE API를 통해 MEC 디스커버리 정책을 수신하고, MEC 디스커버리 정책에 기반하여, MMP 서버(430)와 통신하여 서비스 가능한 MEC 어플리케이션의 앱 리스트를 획득할 수 있다.
동작 2603에서, 전자 장치(101)는 컨텍스트 생성에 관련된 지정된 조건을 감지할 수 있다. 일 실시예에 따르면, 지정된 조건은 컨텍스트 생성을 위한 트리거를 나타낼 수 있다. 일 실시예에 따르면, 컨텍스트 생성을 위한 트리거는, 예를 들어, 클라이언트 어플리케이션(510)이 실행되거나, 클라이언트 어플리케이션(510)에 의해 컨텍스트 생성이 요청되거나, 또는 클라이언트 어플리케이션(510)이 DNS 쿼리를 발생하는 것을 포함할 수 있다.
동작 2605에서, 전자 장치(101)는 지정된 조건에 기반하여 MEC 호스트(예: 엣지 서버 또는 MEC 서버)를 확인하기 위한 어플리케이션 컨텍스트 생성 동작을 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 앱 리스트에 기반하여 클라이언트 어플리케이션(510)과 연관되고 접속하고자 하는 MEC 어플리케이션에 관련된 정보를 MMP 서버(430)로부터 획득할 수 있다. MEC 어플리케이션에 관련된 정보는, 예를 들어, MEC 어플리케이션 이름(MEC App Name)에 대한 URI, 전용 DNN(dedicated DNN) 정보, 또는 MEC 어플리케이션 패키지(package) URI(예: MEC 어플리케이션이 없는 경우) 중 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 아래 <표 3>과 <표 4>는 컨텍스트 생성 동작에서 교환되는 컨텍스트 생성 요청 메시지(context create request message)(예: <표 3>)와 컨텍스트 생성 응답 메시지(context create response message)(예: <표 4>)의 예를 나타낼 수 있다.
Name Type Cardinal Description ETSI MEC Compatible
contextId String 0...1 Uniquely identifies the application context in the MEC system. Assigned by the MEC system and shall be present other than in a create request. The length of the value shall not exceed 32 characters. Y
associateUeAppId String 1 Uniquely identifies the device application.The length of the value shall not exceed 32 characters. Y
callbackReference URI 0...1 URI assigned by the device application to receive application lifecycle related notifications. Inclusion in the request implies the client supports the pub/sub-mechanism and is capable of receiving notifications.This endpoint shall be maintained for the lifetime of the application context. Y
appInfo Structure(inlined) 1 - Y
>appDId String 0...1 Identifier of this MEC application descriptor. It is equivalent to the appDId defined in clause 6.2.1.2 of ETSI GS MEC 010-2 [1]. This attribute shall be globally unique. Y
>appName String 1 Name of the MEC application.The length of the value shall not exceed 32 characters. Y
>appProvider String 1 Provider of the MEC application.The length of the value shall not exceed 32 characters. Y
>appSoftVersion String 0...1 Software version of the MEC application.The length of the value shall not exceed 32 characters. Y
>appDVersion String 1 Identifies the version of the application descriptor. It is equivalent to the appDVersion defined in clause 6.2.1.2 of ETSI GS MEC 010-2 [1]. Y
>appDescription String 0...1 Human readable description of the MEC application (see note 2). Y
>queriedURI URI 0...1 It may be FQDN included in the DNS query of a client Application. N
>appPackage-Source URI 0...1 URI of the application package.Included in the request if the application is not one in the ApplicationList. appPackageSource enables on-boarding of the application package into the MEC system. The application package shall comply with the definitions in clause 6.2.1.2 of ETSI GS MEC 010-2 [1].This should be the MEC application package source. Y
deviceLocation String 0...1 Current location information of the user device N
NOTE 1: If a value of the attribute is included in the request, the same value shall be included in the response.NOTE 2: The design of the current operation with callback reference assumes no web proxy between the entity that originates the notification and the entity that receives it.NOTE 3: The language support for the application description may be limited.
<표 3>에 예시한 바와 같이, 다양한 실시예들에 따른 컨텍스트 생성 요청 메시지는, ETSI MEC 규격에서 정의되어 있는 파라미터 외에, 예를 들어, contextId, associatedUeAppId, app information, callbackReferenceURI, appPackageSource, 또는 deviceLocation 중 적어도 하나를 포함할 수 있다. 일 실시예에 따라, “contextId”는 MEC 어플리케이션 식별을 위한 ID를 나타낼 수 있다. 일 실시예에 따라, “associatedUeAppId”는 전자 장치(101)(예: 사용자 단말)를 식별하기 위한 ID를 나타낼 수 있다. 일 실시예에 따라, “app information”는, 예를 들면, appName, appVersion(예: appSoftVersion, appDVersion), appProvider, appDescription를 포함할 수 있다. 일 실시예에 따라, “callbackReferenceURI”는 MMP 서버(430)로부터 notification을 수신하기 위한 전자 장치(101)의 콜백 주소를 나타낼 수 있다. 일 실시예에 따라, “appPackageSource”는 MEC 시스템(405) 상에 관련 MEC 어플리케이션이 없을 경우 MEC 시스템(405)에서 해당 어플리케이션을 다운로드하여 설치할 수 있도록 지원하기 위한 MEC app package의 다운로드 주소를 나타낼 수 있다. 일 실시예에 따라, “deviceLocation”은 전자 장치(101)의 위치 정보(예: 해당 위치 근처의 MEC 호스트(447)에 MEC 어플리케이션을 인스턴스화(instantiation) 하기 위함)를 나타낼 수 있다. 일 실싱예에 따르면, “deviceLocation”은 컨텍스트 생성 시점의 전자 장치(101)의 위치를 제공하기 위한 것으로, MEC 시스템(405)에서는 전자 장치(101)의 위치에 기반하여 근접 MEC 호스트(447)에 MEC 어플리케이션의 컨텍스트 생성을 수행할 수 있다.
다양한 실시예들에 따르면, 컨텍스트 생성 요청 메시지는, “queriedURI”를 포함할 수 있다. 일 실시예에 따라, “queriedURI”는 클라이언트 어플리케이션(510)에서 DNS 쿼리(query)한 URI (FQDN)를 포함할 수 있으며, 이러한 경우, 컨텍스트 생성 응답 메시지에 이에 대응되는 MEC app URI (referenceURI)가 포함될 수 있다. 일 실시예에 따라, referenceURI는 MEC 어플리케이션에 접속하기 위한 FQDN 또는 IP 주소를 포함할 수 있다.
Name Type Cardinal Description ETSI MEC Compatible
contextId String 0...1 Uniquely identifies the application context in the MEC system. Assigned by the MEC system and shall be present other than in a create request. The length of the value shall not exceed 32 characters. Y
associateUeAppId String 1 Uniquely identifies the device application.The length of the value shall not exceed 32 characters. Y
callbackReference URI 0...1 URI assigned by the device application to receive application lifecycle related notifications. Inclusion inthe request implies the client supports the pub/submechanism and is capable of receiving notifications.This endpoint shall be maintained for the lifetime ofthe application context. Y
appInfo Structure(inlined) 1 - Y
>appDId String 0...1 Identifier of this MEC application descriptor. It is equivalent to the appDId defined in clause 6.2.1.2 of ETSI GS MEC 010-2 [1]. This attribute shall be globally unique. Y
>appName String 1 Name of the MEC application.The length of the value shall not exceed 32 characters. Y
>appProvider String 1 Provider of the MEC application.The length of the value shall not exceed 32 characters. Y
>appSoftVersion String 0...1 Software version of the MEC application.The length of the value shall not exceed 32 characters. Y
>appDVersion String 1 Identifies the version of the application descriptor. It is equivalent to the appDVersion defined in clause 6.2.1.2 of ETSI GS MEC 010-2 [1]. Y
>appDescription String 0...1 Human readable description of the MEC application (see note 2). Y
>referenceURI URI 0...1 Address of the user application.It shall only be included in the response. Y
>clientAppName String 0...N Client app name that is allowed to connect to the MEC application. If the MEC application is open to all the client application, this field can be omitted. N
>uriTTL uint32 0...1 Time-to-live of the reference URI N
>uriLOC String 0...1 Location (range) where the reference URI is available N
>carpRule Structure 0...1 Client App Routing Policy Rules N
>>DNN String 0...1 DNN selection for this application N
>>S-NSSAI String 0...1 Network slice selection for this application N
>>accessType String 0...1 Preferrend access type for this application (e.g., 4G, 5G, WiFi, etc.) N
>>sessionType String 0...1 Ipv4, ipv6, etc. N
>>mptcp Boolean 0...1 Indicates whether to use MPTCP for the matching application N
NOTE 1: If a value of the attribute is included in the request, the same value shall be included in the response.NOTE 2: The design of the current operation with callback reference assumes no web proxy between the entity that originates the notification and the entity that receives it.NOTE 3: The language support for the application description may be limited.
<표 4>에 예시한 바와 같이, 다양한 실시예들에 따른 컨텍스트 생성 응답 메시지는, ETSI MEC 규격에서 정의되어 있는 파라미터 외에, 예를 들어, App information, clientAppName, refereceURI, uriTTL, uriLOC, 또는 CARP rule 중 적어도 하나를 포함할 수 있다. 일 실싱예에 따라, “app information”는, 예를 들면, appName, appProvider, appVersion(예: appSoftVersion, appDVersion), appDescription를 포함할 수 있다. 일 실싱예에 따르면, “app information”과 “clientAppName”은 MEC 어플리케이션에 접속이 허용된 클라이언트 앱 리스트를 나타낼 수 있다. 일 실시예에 따라, “refereceURI”는 MEC 어플리케이션 접속 주소를 나타낼 수 있다. 일 실시예에 따라, “uriTTL”은 MEC 어플리케이션 접속 주소 가용 시간을 나타낼 수 있다. 일 실시예에 따라, “uriLOC”는 MEC 어플리케이션 접속 가능 지역 정보를 나타낼 수 있다. 일 실시예에 따라, “CARP rule”은 해당 어플리케이션 접속을 위한 DNN과 같은 경로 정보를 나타낼 수 있다.
동작 2607에서, 전자 장치(101)는 MEC 호스트를 선택하기 위한 MEC 호스트 선택 동작을 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 획득된 MEC 어플리케이션에 관련된 정보에 기반하여, DNS 서버(2320)와 MEC 호스트 선택 동작을 통해 최적 MEC 호스트를 선택할 수 있다. 일 실시예에 따르면, MEC 호스트 위치와 사용자 현재 위치, 사용자 이동(또는 움직임) 속도, 또는 MEC 호스트 성능(performance)(예: RTT(round trip time), throughput) 중 적어도 하나에 기반하여 최적 MEC 호스트를 선택할 수 있다. 예를 들어, 전자 장치(101)는 전자 장치(101)에 가장 가까이 위치하거나, 사전 성능 측정(또는 테스트)(예: ping probing 또는 bandwidth estimation)을 통해 최적의 성능을 가지거나, 또는 클라이언트 어플리케이션(510)과 매칭(또는 요청)되는 최적 MEC 어플리케이션을 포함하는 MEC 호스트를 선택할 수 있다.
동작 2609에서, 전자 장치(101)는 선택된 MEC 호스트와 데이터 전송을 수행할 수 있다. 예를 들어, 전자 장치(101)는 클라이언트 어플리케이션(510)과 선택된 MEC 호스트에 설치된 MEC 어플리케이션과 어플리케이션 레이어 상에서 데이터 전송을 수행할 수 있다.
도 27은 다양한 실시예들에 따른 디스커버리 절차에서 앱 리스트를 획득하는 동작 예를 도시하는 도면이다.
도 27에 도시한 바와 같이, 도 27은 일 실시예에 따른 MEC 디스커버리 절차에서 앱 리스트 생성 및 획득(예: MEC Application Look-up)에 관한 동작 예를 나타낼 수 있다.
도 27을 참조하면, 동작 2701에서, 전자 장치(101)의 MSA(520)는 MSE(530)로 MEC 디스커버리 정책(discovery policy)을 전달할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 MSA(520)를 이용하여 MEC 디스커버리 정책을 획득하고, MSE(530)를 이용하여 수신된 MEC 디스커버리 정책에 기반한 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MEC 디스커버리 정책은 클라이언트 어플리케이션 이름(예: clientAppNames), 위치(locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType), 컨텍스트 타입(예: contextType), URI 요청 플래그(예: URI Request), 또는 동적 DNN(예: dynamicDnn) 중 적어도 하나를 포함하여 제공할 수 있다. 일 실시예에 따라, 디스커버리 정책은 <표 1>를 참조한 설명 부분에서 설명한 바와 같은 정보들 중 적어도 하나를 포함할 수 있다.
동작 2703에서, MSE(530)는 MSA(520)로부터 수신된 정보(예: MEC 디스커버리 정책)에 기반하여 앱 리스트(예: AppList)를 획득하기 위한 획득 절차(예: MEC Application Look-up)를 수행할 수 있다. 일 실시예에 따르면, 앱 리스트를 획득하는 동작은 MSA(520)와 MSE(530) 간에 MEC 디스커버리 정책 설정에 따라 시작될 수 있다. 일 실시예에 따르면, 앱 리스트 획득 절차는 MSA(520)에서 MEC 디스커버리 정책 API 호출 시 활성화될 수 있고, MEC 디스커버리 정책에 부합하는 MEC 앱 리스트 및/또는 URI를 MMP 서버(430)로 요청하여 수신할 수 있다. 일 실시예에 따르면, 앱 리스트 획득 절차는, 동작 2710, 동작 2720, 동작 2730을 포함할 수 있다.
동작 2710에서, MSE(530)는 앱 리스트를 요청하는 요청 메시지(예: HTTP Get AppList Request Parameters)를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 디스커버리 정책을 요청 메시지(예: HTTP Get AppList Request Parameters)에 포함(또는 기입)하여 MMP 서버(430)로 제공할 수 있다. 예를 들어, MSE(530)는 <표 1>에 예시한 바와 같은 앱 리스트 요청 파라미터를 포함하여 MMP 서버(430)로 제공할 수 있다. 예를 들어, 요청 메시지는 <표 1>을 참조한 설명 부분에서 설명한 바와 같은 정보(또는 파라미터) 중 적어도 하나의 정보를 포함할 수 있다.
일 실시예에 따르면, Request Parameter에 지원 가능한 필드(field) 정보는 인증(AA) 단계에서 Authorization Response 내 MMP Info에 정의할 수 있다. 일 실시예에 따르면, 앱 리스트 요청과 관련된 파라미터(또는 정보)(예: AppList Request Parameters)는 요청 메시지(예: HTTP GET)의 파라미터 필드(parameter field)에 포함될 수 있다. 일 실시예에 따르면, 앱 리스트 요청 파라미터는, MSA(520)로부터 전달 받은(예: 동작 2701의 setMecDiscoveryPolicy(clientAppNames, discoveryPolicy)) 어플리케이션 이름(예: clientAppNames), 접속 Cell ID, 트래킹 영역(TA, Tracking Area) ID, 지역 정보(예: 시, 구, 동, 건물), 또는 사용자가 지정한 우선 위치(preferred location) 정보 중 적어도 하나를 포함하는 전자 장치(101)의 위치와 관련된 위치 정보(Location Info), 전자 장치(101)의 종류를 식별할 수 있는 디바이스 타입(Device Type)(예: Smartphone, Tablet, Wearable, IoT, Car, Drone), 서비스의 종류를 식별할 수 있는 서비스 타입(Service Type)(예: Game, V2X, AR/VR, LBO, Enterprise, Web), 컨텍스트 정보의 필요 여부를 식별할 수 있는 컨텍스트 타입(Context Type)(예: MEC 어플리케이션 구동에 사용자 또는 어플리케이션의 컨텍스트(context) 정보가 필요한지 여부), 또는 MEC 어플리케이션의 URI가 활성화 가능(available)한 경우 해당 URI를 응답에 포함하도록 요청하는 플래그(Flag)(예: URI Request Flag) 중 적어도 하나를 포함할 수 있다. 일 실시예에 따라, 컨텍스트 타입은 전자 장치(101)의 서비스 어플리케이션 타입을 식별하기 위한 정보로, 예를 들어, 전자 장치(101)에 설치된 어플리케이션(예: 특정 런처 또는 지정된 어플리케이션), 실행 어플리케이션의 이름, 도메인(domain) 중 적어도 하나를 포함할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 앱 리스트를 요청하는 절차에서, 전자 장치(101)에 설치된 어플리케이션 정보(예: 특정 런처 또는 지정된 어플리케이션)를 MMP 서버(430)로 전달할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 전자 장치(101)에 설치된 어플리케이션 정보의 변경(예: 업데이트)이 있는 경우, MMP 서버(430)에 앱 리스트를 요청하는 절차에서, 전자 장치(101)에 설치된 어플리케이션 정보를 전달할 수도 있다.
동작 2720에서, MMP 서버(430)는 MSE(530)로부터 수신된 요청 메시지에 대응하는 응답으로 앱 리스트(예: MEC AppList)를 포함하는 응답 메시지(예: HTTP 200 OK AppList response Data)를 MSE(530)로 제공할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 수신된 클라이언트 어플리케이션 이름에 기반하여 MEC 어플리케이션을 검색하고, 검색된 MEC 어플리케이션을 포함하는 앱 리스트를 응답 메시지에 포함하여 MSE(530)로 제공할 수 있다.
일 실시예에 따르면, 앱 리스트 응답과 관련된 데이터(또는 정보)(예: AppList Response Data)는 응답 메시지(예: HTTP 200 OK)의 메시지 바디(message body)에 포함될 수 있다. 일 실시예에 따라, 응답 메시지는 <표 2>를 참조한 설명 부분에서 설명한 바와 같은 정보들 중 적어도 하나를 포함할 수 있다.
일 실시예에 따르면, MMP 서버(430)는 앱 리스트를 제공할 때, 가용한 전체 MEC App List 또는 Request Parameters 중 적어도 하나에 기반하여 서비스 가능한 MEC App List를 제공할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(Client App) 별 접속 가능한 MEC App Name을 포함할 수 있으며, MEC App Name은 이후 Application Context Create 동작에서 사용(또는 필요)할 수 있다.
일 실시예에 따르면, MMP 서버(430)는 오퍼레이터의 위치 API(Operator’s Location API)가 가용한 경우 알림을 앱 리스트에 포함하여 제공할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 요청 메시지에서, URI Request Flag가 true이고, 전자 장치(101)(예: 사용자 단말) 근처의 가용 MEC 호스트에 해당 MEC App이 실행 중일 경우, 해당 MEC App의 URI를 앱 리스트에 포함하여 제공할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 요청 메시지에서, URI 요청 플래그(URI Request Flag)가 없는 경우에서도, MEC 호스트에 해당 MEC App이 실행 중일 경우, 해당 MEC App의 URI를 앱 리스트에 포함하여 제공할 수도 있다. 일 실시예에 따르면, MMP 서버(430)는 전자 장치(101)로부터 앱 리스트 요청 수신 시, 요청 메시지에서, 컨텍스트 타입에 따라 MEC App이 바로 구동이 가능한 경우 MEC App을 구동한 후 해당 URI를 앱 리스트에 포함하여 제공할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 URI의 유효시간/유효 장소 정보를 앱 리스트에 더 포함하여 제공할 수 있다. 일 실시예에 다르면, URI의 유효시간에 대한 정보는 전자 장치(101)가 결정할 수도 있고, 또는 MMP 서버(430)에서 MEC App 구동 상태에 따라 가변적으로 결정할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 어플리케이션 별 전용 DNN 규칙이 존재하는 경우, 해당 규칙을 제공할 수도 있다.
일 실시예에 따르면, 앱 리스트에 포함된 URI는 하이퍼링크 및/또는 하이라이트 되어 구분될 수 있고, 전자 장치(101)는 앱 리스트에서, URI를 포함하지 않는 MEC App과 하이퍼링크 및/또는 하이라이트에 기반하여 구분하여 표시할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는 앱 리스트에서, URI를 포함하는 MEC App과 URI를 포함하지 않은 MEC App을 구분하지 않고 동일하게 표시할 수도 있다. 일 실시예에 따르면, 전자 장치(101)는 앱 리스트에서, 어플리케이션 별 서비스 가능한 위치 및/또는 시간 정보를 포함하여 제공할 수도 있다.
일 실시예에 따르면, MMP 서버(430)는 앱 리스트를 응답하는 절차에서, 어플리케이션 단위로 DNN 설정이 가능한 경우, 앱 리스트에 어플리케이션 별(또는 앱 별) 사용 DNN 정보를 포함할 수 있다. 일 실시예에 따라, 해당 DNN 서버는, 인증(AA) 정차에서 수신된 DNN 리스트에 포함된 DNN일 수 있다.
일 실시예에 따르면, 전자 장치(101)는 MMP 서버(430)에 앱 리스트를 요청하고, 그에 대한 응답을 수신하는 절차에서, 앱 리스트 및 앱 리스트의 해당 어플리케이션(들)에 대한 MEC 호스트(예: 엣지 서버 또는 MEC 서버)에 대한 정보(예: URI)를 획득(또는 수신)할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 호스트에 대한 정보(예: URI)를 수신하지 않은 경우, 예를 들어, 해당 앱에 대해, Application Context Create 절차를 더 수행하여, 해당 어플리케이션에 대한 MEC 호스트의 정보(예: URI)를 외부 서버로부터 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 호스트에 대한 정보(예: URI)를 수신한 경우, 예를 들어, 해당 어플리케이션에 대해, Application Context Create 절차를 수행하지 않고, 바로 해당 MEC 호스트(예: URI를 사용하여)로 접속을 수행할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 MMP 서버(430)에 앱 리스트를 요청하고, 그에 대한 응답을 수신하는 절차에서, 앱 리스트 및 앱 리스트의 해당 어플리케이션(들)에 대한 지정된 네트워킹 경로에 대한 정보(예: DNN)를 수신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 지정된 네트워킹 경로에 대한 정보(예: DNN)를 수신한 경우, 네트워크와 지정된 네트워킹 경로를 설정하는 절차를 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 DNN 정보를 수신한 어플리케이션들에 대해서만 지정된(또는 전용) DNN(dedicated DNN)으로 통신하도록 DNN 경로를 설정할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 호스트에 컨텍스트를 생성 요청하는 절차(예: Application Context Create)에서, DNN 정보를 수신한 어플리케이션들에 대해 지정된 DNN 경로를 설정할 수 있다.
동작 2730에서, MSE(230)는 정책 업데이트를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 앱 리스트를 획득하는 동작(동작 2703)에서, 추가적으로(또는 선택적으로) 정책 업데이트 동작을 포함할 수 있다. 일 실시예에 따르면, MSE(530)는 전용 PDU 세션(dedicated PDU session) 필요 시(또는 새로운 전용 DNN 규칙이 설정된 경우) URSP 규칙(예: DNN)을 수신하고, URSP 규칙에 따라 어플리케이션 별 또는 URI 별 별도 PDU 세션을 설정 및 사용하도록 할 수 있다. 예를 들어, URSP 규칙(또는 CARP 규칙)은 인증 절차의 결과(예: MSA(520)가 수신하여 MSE(530)에 전달), 또는 MSE(530)가 어플리케이션 룩업(예: App lookup) 결과, 또는 컨텍스트 생성(Context Create) 결과로 수신할 수 있으며, URSP 규칙에 새로운 DNN 규칙이 설정되어 있는 경우, PDU 세션 설정(setup)을 수행할 수 있다. 일 실시예에 따르면, PDU 세션 설정(예: 도 17의 PDU 세션 생성, 도 18의 PDU 세션 해제)은 전술한 도 17 또는 도 18을 참조한 설명 부분에서 설명한 바와 같이 MSE(530)가 모뎀(1700)에 요청하면, 모뎀(1700)에서 5G 망(또는 코어 망)의 SMF에 요청하여 생성/해제할 수 있다.
도 28은 다양한 실시예들에 따른 앱 리스트가 제공되는 예를 설명하기 위한 도면이다.
도 28에 도시한 바와 같이, 도 28은 위치 기반 서비스 영역(Location-based Service Area)의 을 예시할 수 있다.
도 28을 참조하면, 일 실시예에 따라, MMP 서버(430)는 제1 서버(Server 1)(2810)(또는 사용자 인접의 제1 MEC 호스트)(예: 도 4의 MEC 호스트(447))로부터 가능한 어플리케이션(Available Apps)에 대한 제1 정보(예: A(+URI), B, C)를 획득하는 것을 가정할 수 있다. 일 실시예에 따라, MMP 서버(430)는 제2 서버(Server 2)(2820)(또는 사용자 인접의 제2 MEC 호스트)(예: 도 4의 MEC 호스트(447))로부터 가능한 어플리케이션에 대한 제2 정보(예: A(+URI), C(+URI), D)를 획득하는 것을 가정할 수 있다.
다양한 실시예들에 따르면, MMP 서버(430)는 제1 서버(2810)와 제2 서버(2820)로부터 획득한 각각의 어플리케이션에 대한 정보들(예: 제1 정보, 제2 정보)을 취합하여, 예를 들어, A(+URI), B, C(+URI), D의 정보를 생성(또는 획득)할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 제1 서버(2810)와 제2 서버(2820)로부터 생성된 A(+URI), B, C(+URI), D를 포함하여 앱 리스트를 생성하고, 생성된 앱 리스트를 사용자(2830)(예: 전자 장치(101))에 제공할 수 있다.
도 29는 다양한 실시예들에 따른 어플리케이션의 라이프 사이클(2900)을 도시하는 도면이다.
다양한 실시예들에 따르면, 전자 장치(101)에 설치된 어플리케이션은 사용자 입력 또는 프로세서(예: 도 1의 프로세서(120))의 명령에 의하여 상태(state)가 변경될 수 있다.
도 29를 참조하면, 어플리케이션(예: 클라이언트 어플리케이션(510))의 라이프 사이클(2900)은, 예를 들어, 어플리케이션의 상태가 시작 상태(launch)(2905), 실행(running) 상태(2910), 중지(paused) 상태(2915), 종료(shut down) 상태(2920), 또는 강제 종료(killed) 상태(2925)로 변경되는 일련의 주기(cycle)를 의미할 수 있다.
일 실시예에 따르면, 전자 장치(101)에 설치된 어플리케이션은 사용자 입력 또는 미리 설정된 조건에 의하여 시작 상태가 될 수 있다. 어플리케이션은 어플리케이션과 관련된 화면이 사용자에게 보여지는 실행 상태(또는 포어그라운드(foreground) 상태)가 되거나, 어플리케이션이 전자 장치(101)의 프로세서(120)(예: 어플리케이션 프로세서(AP))에 의하여 실행(executed) 중이지만 어플리케이션과 관련된 화면이 사용자에게 보여지지 않는 정지(pause) 상태(또는 백그라운드(background) 상태)가 될 수도 있다. 또한, 어플리케이션은 사용자 입력에 의하여 종료(shut down) 상태가 되거나, 메모리 부족으로 인하여 강제 종료(killed) 상태가 될 수 있다.
일 실시예에 따르면, MEC 시스템(405)은 어플리케이션의 상태에 따라서 MEC에 기반한 데이터 전송을 수행하므로, 라이프 사이클이 동기화되지 않으면, MEC 시스템(405)은 자원을 낭비할 수 있다. 일 실시예에 따르면, MSE(230)는 어플리케이션들(310-1, 310-2, …)의 사용 여부를 MMP 서버(430)로 통지할 수 있다. 일 실시예에 따라, 어플리케이션들(예: 310-1, 310-2, …)이 사용 중일 때만 MEC 어플리케이션들(예: 460-1, 460-2, …)이 동작(예: 데이터 전송)을 수행하고, 어플리케이션들(예: 310-1, 310-2, …)이 미사용 중(예: screen off, 클라이언트 어플리케이션 백그라운드(background) 상태 변경, 사용자 이동 속도가 일정 이상 중 적어도 하나 만족)일 때에는 MEC 어플리케이션들(460-1, 460-2, …)이 동작(예: 데이터 전송)을 중지할 수 있다. 일 실시예에 따르면, MSE(530)가 상기와 같이 어플리케이션들(310-1, 310-2, …)의 사용 여부를 MMP 서버(430)에 알려줌으로써, MEC 호스트(447)(또는 엣지 서버(305))의 자원을 효율적으로 관리하도록 할 수 있다. 일 실시예에 따라, 미사용 중인 어플리케이션에 대해서는 MEC 어플리케이션의 자원 할당을 해제하여 MEC 호스트(447)의 자원 소모를 줄일 수 있다. 다양한 실시예들에 따르면, MEC 서비스 모듈(410)(예: MSE(530))에서 어플리케이션(예: 전자 장치(101)의 클라이언트 어플리케이션(예: 310-1, 310-2, …)과 MEC 호스트(447)의 MEC 어플리케이션(예; 460-1, 460-2, …)의 라이프 사이클을 실시간으로 모니터링하고, 모니터링 된 라이프 사이클을 MEC 시스템(505)(예: MMP 서버(430)(또는 LCM 프록시 서버))에게 알려줌으로써 불필요한 자원 소모를 줄일 수 있다.
일 실시예에 따르면, 복수의 어플리케이션들 중에서 라이프 사이클 동기화를 요구하는 어플리케이션과 그렇지 않은 어플리케이션이 존재할 수 있다. 예를 들어, 영상 감시(video surveillance)와 관련된 어플리케이션의 경우, MEC 시스템(405)에 포함되는 MEC 어플리케이션(예: 460-1 또는 460-2)은 전자 장치(101)의 카메라 모듈(예: 도 1의 카메라 모듈(180))에 의하여 획득된 영상 데이터를 분석하고 전자 장치(101)의 요청에 한하여 분석 결과를 전송하므로, 전자 장치(101)와 MEC 어플리케이션 간 라이프 사이클 동기화가 요구되지 않을 수 있다. 다른 예를 들어, 증강 현실(augmented reality) 어플리케이션의 경우, MEC 어플리케이션이 카메라 모듈(180)에 의하여 획득된 영상을 실시간으로 분석하고, 분석된 영상과 관련된 서비스를 전자 장치(101)에게 제공하므로, 전자 장치(101)와 MEC 어플리케이션 간 라이프 사이클 동기화가 요구될 수 있다.
일 실시예에 따르면, 어플리케이션(310-1 또는 310-2)의 라이프 사이클이 변경되면, MEC 서비스 모듈(410)(예: MSE(530))는 라이프 사이클의 변경을 MEC 시스템(405)에게 요청할 수 있다. 예를 들어, MEC 서비스 모듈(410)은 MEC 어플리케이션의 컨텍스트 생성(context create), 컨텍스트 삭제(context delete), 연기(suspend), 또는 재개(resume) 중 적어도 하나를 요청할 수 있다.
도 30은 다양한 실시예들에 따른 디스커버리 절차에서 컨텍스트 생성 절차의 예를 도시하는 도면이다.
도 30에 도시한 바와 같이, 도 30은 일 실시예에 따른 MEC 디스커버리 절차에서 어플리케이션 컨텍스트 생성(예: Application Context Create)에 관한 동작 예를 나타낼 수 있다. 일 실시예에 따라, 어플리케이션 컨텍스트 생성 절차는, 예를 들면, 클라이언트 어플리케이션(510)이 실행되는 경우, MSA(520)가 해당 클라이언트 어플리케이션에 관련된 정보(예: 패키지 이름 또는 UID)와 함께 어플리케이션 시작 정보를 MSE API를 통해 MSE(530)에 전달하는 것으로부터 수행될 수 있다. 다양한 실시예들에 따르면, 어플리케이션 컨텍스트 생성은, 앱 리스트 상의 어플리케이션이 실행(launch)되거나(제1 케이스), 어플리케이션이 MSE API를 통해 컨텍스트 생성(contextcreate)을 요청(예: context create API 호출)하거나(제2 케이스), 또는 어플리케이션에서 DNS 쿼리 전송 시 미리 수신한 앱 리스트에 포함된 어플리케이션 이름 및/또는 URI(예: FQDN)와 매칭이 되는 경우(제3 케이스)에 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, 예를 들어, MEC 디스커버리 정책(예: setDiscoveryPolicy(discoveryPolicy))을 통해 전달된 위치 정보 또는 어플리케이션 룩업 응답을 통해 전달된 앱 리스트에 포함된 어플리케이션 별 가용 위치(예: uriLOC)가 현재 사용자(또는 전자 장치(101))의 위치와 매칭되는 경우(예: 제4 케이스)에도 수행할 수 있다. 다양한 실시예들에 따르면, 제1 케이스, 제2 케이스, 제3 케이스, 또는 제4 케이스에 따른 조건 중 적어도 하나가 만족할 때 어플리케이션 컨텍스트 생성을 수행할 수 있다. 도 30에서는 제1 케이스에 따라 어플리케이션 컨텍스트 생성을 수행하는 동작 예를 나타낼 수 있다.
도 30을 참조하면, 동작 3001에서, 특정 클라이언트 어플리케이션(510)이 실행되는(launched) 경우, 해당 클라이언트 어플리케이션(510)은 어플리케이션의 실행을 알리는 정보(예: App Launched)를 MSA(520)로 제공할 수 있다. 일 실시예에 따르면, 동작 3001은 수행하지 않을 수도 있다. 예를 들어, 클라이언트 어플리케이션(510)이 실행되는 경우, 클라이언트 어플리케이션(510)에 의한 실행을 알리는 동작 없이, MSA(520)(예: Framework level)에서 자체적으로 클라이언트 어플리케이션(510)의 실행을 감지할 수 있다.
동작 3003에서, MSA(520)는 클라이언트 어플리케이션(510)의 실행을 알리는 정보(예: App Launched)를 수신하면, 클라이언트 어플리케이션(510)의 상태(state)를 통지(notify)하는 통지 메시지(예: notifyClientAppState)를 MSE(530)로 제공할 수 있다. 일 실시예에 따라, 통지 메시지(예: notifyClientAppState)는, 예를 들어, 클라이언트 어플리케이션의 상태(예: START)와 클라이언트 어플리케이션의 이름(예: clientAppName)(및/또는 UID)을 포함(예: notifyClientAppState(START, clientAppName))하여 제공할 수 있다.
동작 3005에서, MSE(530)는 MSA(520)로부터 통지 메시지(예: notifyClientAppState)를 수신하고, 수신된 통지 메시지의 정보에 기반하여 어플리케이션 컨텍스트 생성 절차를 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성 절차(동작 3005)는, 동작 3010, 동작 3020, 동작 3030을 포함할 수 있다.
동작 3010에서, MSE(530)는 어플리케이션 컨텍스트 생성을 요청하는 요청 메시지(예: HTTP POST AppContext Data)를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 어플리케이션 컨텍스트 생성이 필요한 경우(예: 앱 리스트에 URI가 없는 경우), URI를 요청하는 요청 메시지를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP 서버(430)에 MEC 어플리케이션이 있을 경우 MEC 어플리케이션 이름(MEC App Name)을 요청 메시지에 포함하여 MMP 서버(430)로 전송할 수 있다. 다른 실시예에 따르면, MSE(530)는 MMP 서버(430)에 MEC 어플리케이션이 없을 경우 해당 MEC 어플리케이션을 다운로드 할 수 있는 URI(예: 어플리케이션 패키지 다운로드 URI(App package download URI)만을 요청 메시지에 포함하여 MMP 서버(430)로 전송할 수 있다.
동작 3020에서, MMP 서버(430)는 MSE(530)로부터 수신된 요청 메시지에 대응하는 응답으로 MEC 어플리케이션의 URI를 포함하는 응답 메시지(예: HTTP OK 200 Response AppContext Data)를 MSE(530)로 제공할 수 있다. 일 실시예에 따르면, 응답 메시지는 해당하는 어플리케이션(예: MEC 어플리케이션)의 URI(FQDN)를 포함할 수 있다. 일 실시예에 따르면, 응답 메시지는 MEC 어플리케이션의 URI 및 해당 URI의 유효 시간 및/또는 유효 위치에 관한 정보를 포함할 수 있다. 일 실시예에 따르면, MSE(530)는 유효 시간 초과 또는 유효 위치 변경 시, 어플리케이션 컨텍스트 재수행 또는 핸드오버 트리거링(handover triggering)이 수행될 수 있다. 일 실시예에 따르면, 응답 메시지는 DNN 정보를 포함할 수 있다.
동작 3030에서, MSE(530)는 정책 업데이트를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 어플리케이션 컨텍스트 생성 절차(동작 3005)에서, 추가적으로(또는 선택적으로) 정책 업데이트 동작을 포함할 수 있다. 일 실시예에 따르면, MSE(530)는 전용 PDU 세션(dedicated PDU session) 필요 시(또는 새로운 전용 DNN 규칙이 설정된 경우) URSP 규칙(예: DNN)을 수신하고, URSP 규칙에 따라 어플리케이션 별 또는 URI 별 PDU 세션을 설정할 수 있다. 예를 들어, URSP 규칙(또는 CARP 규칙)은 인증 절차의 결과(예: MSA(520)가 수신하여 MSE(530)에 전달), 또는 MSE(530)가 어플리케이션 룩업(예: App lookup) 결과, 또는 컨텍스트 생성(Context Create) 결과로 수신할 수 있으며, URSP 규칙에 새로운 DNN 규칙이 설정되어 있는 경우, PDU 세션 설정(setup)을 수행할 수 있다. 일 실시예에 따르면, PDU 세션 설정(예: 도 17의 PDU 세션 생성, 도 18의 PDU 세션 해제)은 전술한 도 17 또는 도 18을 참조한 설명 부분에서 설명한 바와 같이 MSE(530)가 모뎀(1700)에 요청하면, 모뎀(1700)에서 5G 망(또는 코어 망)의 SMF에 요청하여 생성/해제할 수 있다.
다양한 실시예들에 따르면, 어플리케이션 컨텍스트 생성 절차(동작 3005)는, 예를 들어, 클라이언트 어플리케이션(510)이 접속해야 할 MEC 어플리케이션이 이미 구동 중이고, 앱 리스트 획득 절차(예: MEC Application Look-up)에서 URI가 수신된 경우에는 생략할 수도 있다.
도 31은 다양한 실시예들에 따른 디스커버리 절차에서 컨텍스트 생성 동작의 예를 도시하는 도면이다.
도 31에 도시한 바와 같이, 도 31은 일 실시예에 따른 MEC 디스커버리 절차에서 어플리케이션 컨텍스트 생성(예: Application Context Create)에 관한 동작 예를 나타낼 수 있다. 일 실시예에 따라, 어플리케이션 컨텍스트 생성 동작은, 예를 들면, 클라이언트 어플리케이션(510)이 컨텍스트 생성 요청을 MSE API를 통해 MSE(530)에 전달하는 것으로부터 수행될 수 있다. 다양한 실시예들에 따르면, 어플리케이션 컨텍스트 생성은, 앱 리스트 상의 어플리케이션이 실행(launch)되거나(제1 케이스), 어플리케이션이 MSE API를 통해 컨텍스트 생성(contextcreate)을 요청(예: context create API 호출)하거나(제2 케이스), 또는 어플리케이션에서 DNS 쿼리 전송 시 미리 수신한 앱 리스트에 포함된 어플리케이션 이름 및/또는 URI(예: FQDN)와 매칭이 되는 경우(제3 케이스)에 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, 예를 들어, MEC 디스커버리 정책(예: setDiscoveryPolicy(discoveryPolicy))을 통해 전달된 위치 정보 또는 어플리케이션 룩업 응답을 통해 전달된 앱 리스트에 포함된 어플리케이션 별 가용 위치(예: uriLOC)가 현재 사용자(또는 전자 장치(101))의 위치와 매칭되는 경우(예: 제4 케이스)에도 수행할 수 있다. 다양한 실시예들에 따르면, 제1 케이스, 제2 케이스, 제3 케이스, 또는 제4 케이스에 따른 조건 중 적어도 하나가 만족할 때 어플리케이션 컨텍스트 생성을 수행할 수 있다. 도 31에서는 제2 케이스에 따라 어플리케이션 컨텍스트 생성을 수행하는 동작 예를 나타낼 수 있다.
도 31을 참조하면, 동작 3101에서, 클라이언트 어플리케이션(510)은 MSE(530)로 컨텍스트 생성을 위한 메시지(예: contextCreate)를 전달할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(510)은 컨텍스트 생성이 필요한 경우, 해당 클라이언트 어플리케이션에 관련된 정보(예: 어플리케이션 이름(appName) 또는 UID)와 함께 컨텍스트 생성 요청을 MSE API를 통해 MSE(530)로 전달할 수 있다.
동작 3103에서, MSE(530)는 클라이언트 어플리케이션(510)으로부터 컨텍스트 생성을 위한 메시지를 수신하고, 수신된 메시지의 정보(예: 어플리케이션 이름)에 기반하여 어플리케이션 컨텍스트 생성 동작을 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성 동작(동작 3103)은, 동작 3110, 동작 3120, 동작 3130을 포함할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성 동작(동작 3103)은, 전술한 도 30에서 동작 3005의 어플리케이션 컨텍스트 생성 동작에 따른 동작 3010, 동작 3020, 동작 3030를 참조한 설명 부분에서 설명한 바에 각각 대응할 수 있다.
도 32는 다양한 실시예들에 따른 디스커버리 절차에서 컨텍스트 생성 동작의 예를 도시하는 도면이다.
도 32에 도시한 바와 같이, 도 32는 일 실시예에 따른 MEC 디스커버리 절차에서 어플리케이션 컨텍스트 생성(예: Application Context Create)에 관한 동작 예를 나타낼 수 있다. 일 실시예에 따라, 어플리케이션 컨텍스트 생성 동작은, 예를 들면, 클라이언트 어플리케이션(510)이 DNS 쿼리를 MSE(530)에 전달하는 것으로부터 수행될 수 있다. 다양한 실시예들에 따르면, 어플리케이션 컨텍스트 생성은, 앱 리스트 상의 어플리케이션이 실행(launch)되거나(제1 케이스), 어플리케이션이 MSE API를 통해 컨텍스트 생성(contextcreate)을 요청(예: context create API 호출)하거나(제2 케이스), 또는 어플리케이션에서 DNS 쿼리 전송 시 미리 수신한 앱 리스트에 포함된 어플리케이션 이름 및/또는 URI(FQDN)와 매칭이 되는 경우(제3 케이스)에 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, 예를 들어, MEC 디스커버리 정책(예: setDiscoveryPolicy(discoveryPolicy))을 통해 전달된 위치 정보 또는 어플리케이션 룩업 응답을 통해 전달된 앱 리스트에 포함된 어플리케이션 별 가용 위치(예: uriLOC)가 현재 사용자(또는 전자 장치(101))의 위치와 매칭되는 경우(예: 제4 케이스)에도 수행할 수 있다. 다양한 실시예들에 따르면, 제1 케이스, 제2 케이스, 제3 케이스, 또는 제4 케이스에 따른 조건 중 적어도 하나가 만족할 때 어플리케이션 컨텍스트 생성을 수행할 수 있다. 도 32에서는 제3 케이스에 따라 어플리케이션 컨텍스트 생성을 수행하는 동작 예를 나타낼 수 있다.
도 32를 참조하면, 동작 3201에서, 클라이언트 어플리케이션(510)은 MSE(530)로 DNS 쿼리(query)를 위한 메시지(예: DNS Query)를 전달할 수 있다.
동작 3203에서, MSE(530)는 클라이언트 어플리케이션(510)으로부터 DNS 쿼리를 수신하고, DNS 쿼리가 미리 수신한 앱 리스트에 포함된 어플리케이션 또는 URI와 매칭이 되는 경우 어플리케이션 컨텍스트 생성 동작을 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성 동작(동작 3203)은, 동작 3210, 동작 3220, 동작 3230을 포함할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성 동작(동작 3203)은, 전술한 도 30에서 동작 3005의 어플리케이션 컨텍스트 생성 동작에 따른 동작 3010, 동작 3020, 동작 3030를 참조한 설명 부분에서 설명한 바에 각각 대응할 수 있다.
다양한 실시예들에서, 도시하지는 않았으나, 다양한 실시예들에 따른 어플리케이션 컨텍스트 생성 동작은, 예를 들어, MEC 디스커버리 정책(예: setDiscoveryPolicy(discoveryPolicy))을 통해 전달된 위치 정보 또는 어플리케이션 룩업 응답을 통해 전달된 앱 리스트에 포함된 어플리케이션 별 가용 위치(예: uriLOC)가 현재 사용자(또는 전자 장치(101))의 위치와 매칭되는 경우에도 수행할 수 있다.
도 33은 다양한 실시예들에 따른 디스커버리 절차에서 MEC 호스트 선택 절차의 예를 도시하는 도면이다.
도 33에 도시한 바와 같이, 도 33은 MSE(530)가 DNS 서버(2320)와 MEC 호스트를 선택하기 위한 MEC 호스트 선택 동작(MEC Host selection)(3301)을 나타낼 수 있다. 일 실시예에 따르면, MEC 호스트 선택 동작(동작 3301)은, DNS (pre)resolving 동작(예: 동작 3310), MEC Host Prioritization 동작(예: 동작 3320), DNS 캐싱(caching) 동작(예: 동작 3330)을 포함할 수 있다.
도 33을 참조하면, 동작 3310에서, MSE(530)는 DNS 리졸빙(resolving 또는 pre-resolving)을 수행할 수 있다. 일 실시예에 따르면, DNS 리졸빙은, 예를 들어, 클라이언트 어플리케이션(510)의 DNS 쿼리(query)와 상관 없이 MSE(530) 자체적으로 MEC용 FQDN에 대해 DNS 리졸빙 할 수 있다. 일 실시예에 따라, DNS 리졸빙(동작 3310)은, 동작 3311과 동작 3313을 포함할 수 있다.
일 실시예에 따라, 동작 3311에서, MSE(530)는 DHL(535)에 의한 DNS 리졸빙 동작을 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MEC 어플리케이션에 대한 URI(FQDN)로 DNS 쿼리를 DNS 서버(2320)에 전송할 수 있다.
일 실시예에 따라, 동작 3313에서, DNS 서버(2320)는 MSE(530)로부터 DNS 쿼리를 수신하고, DNS 쿼리에 대응하는 응답으로, DNS 응답을 MSE(530)에 전송할 수 있다. 일 실시예에 따르면, DNS 응답은 MEC 호스트에 관련된 적어도 하나의 주소 정보(예: URI 또는 IP 주소)를 포함할 수 있다.
동작 3320에서, MSE(530)는 MEC 호스트 우선순위 결정(MEC Host Prioritization) 동작을 수행할 수 있다. 일 실시예에 따르면, MEC Host Prioritization는, 예를 들어, DNS 쿼리 응답(query response)으로 복수 개의 IP 주소가 수신되는 경우 IP 우선 순위(prioritization)를 설정하는 것을 포함할 수 있다. 예를 들면, MSE(530)는 MEC 호스트에 대한 우선 순위를 설정할 수 있다.
일 실시예에 따르면, MSE(530)는 MMP 서버(430)로부터 복수 개의 MEC 호스트에 대한 후보 IP 리스트(candidate IP list)를 획득(또는 수신)할 수 있고, 후보 IP 리스트의 추가 정보(예: MEC 호스트 위치 사용자 현재 위치, 사용자 속도, 또는 MEC 호스트 성능(performance)(예: RTT(round trip time), throughput) 중 적어도 하나)로부터 MEC 호스트 후보 IP 및 리모트(remote) 서버(예: 도 3의 리모트 서버(306)) IP 주소 중 접속 IP 선택 또는 우선 순위를 지정할 수 있다. 일 실시예에 따르면, 후보 IP 리스트 중 접속 IP 선택 시, MEC 호스트 IP 또는 리모트 서버의 IP 중 어느 하나를 선택할 수 있다. 예를 들어, 사용자 위치로부터 모든 MEC 호스트 위치가 일정 거리 이상이거나, RTT 값이 일정 값 이상이거나, 또는 사용자 움직임 속도가 일정 값 이상일 경우, MEC 호스트 IP를 선택하지 않고 리모트 서버 IP를 선택할 수 있다. 일 실시예에 따르면, MSE(530)(예: MEL(531))는 복수의 후보 MEC 호스트에 대해 사전 성능 측정(또는 테스트)(예: ping probing 또는 bandwidth estimation)을 통해 최적의 MEC 호스트를 선택할 수 있다. 일 실시예에 따르면, DNS 서버(2320)는 DNS 응답(DNS response) 메시지에 MEC 호스트의 IP 주소와 함께, 해당 MEC 호스트의 위치 정보(location information)를 기록(record)할 수 있다. 예를 들어, MSE(530)는 DNS 리졸빙 시 DNS 쿼리(query) 후 수신한 DNS 응답 메시지 내 DNS 타입 중 위치 기록 타입(예: LOC record type)에 대해 MEC 호스트의 위치 정보가 포함되어 있을 경우, 해당 위치 정보를 이용하여 인접 MEC 호스트를 선택할 수도 있다. 일 실시예에 따르면, MSE(530)는 MEC 호스트의 IP 주소를 획득하는 DNS 쿼리 동작에서 DNS 서버(2320)로부터 MEC 호스트의 위치 정보(예: 위도, 경도, 서빙 셀 ID, 도시 정보, 또는 ID)를 획득할 수 있다. 예를 들어, DNS 타입 필드에 MEC 호스트의 위치 정보가 포함될 수 있다.
동작 3330에서, MSE(530)는 DNS 캐시(2310)로 DNS 캐싱(caching)을 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 DNS 서버(2320)로부터 DNS 쿼리에 대응하여 주소 정보를 포함하는 DNS 응답을 수신하는 경우, DNS 응답에 포함된 주소 정보(예: MEC 호스트에 관련된 URI(FQDN)에 대응되는 IP 주소)를 MEC 용 로컬 DNS 캐시(Local DNS Cache)(예: DNS Cache 2)에 저장할 수 있다. 일 실시예에 따르면, MSE(530)는 클라이언트 어플리케이션(510)으로부터 MEC 어플리케이션에 대한 주소 정보(예: URI 또는 IP 주소)가 요청되는 경우, MEC 용 로컬 DNS 캐시에 저장된 주소 정보를 전달할 수 있다. 다양한 실시예들에 따르면, MEC 용 로컬 DNS 캐시(예: DNS Cache 2)의 운영과 관련하여, 후술하는 도 34의 MEC 용 로컬 DNS 캐시(예: DNS Cache 2)를 별도 운용하는 방안, 또는 도 35의 MSE(530) 내에 MEC 용 로컬 DNS 캐시(예: DNS Cache 2)를 포함하여 운용하는 방안이 이용될 수 있다. 일 실시예에 따른 MEC 용 로컬 DNS 캐시를 운용하는 동작과 관련하여 후술하는 도면을 참조하여 상세히 설명된다.
다양한 실시예들에 따르면, 전자 장치(101)는 MEC 호스트 선택 동작에 기반하여, MMP 서버(430)와의 통신 절차(예: 디스커버리/어플리케이션 컨텍스트 생성)에서, MEC 어플리케이션이 동작할 수 있는 복수 개의 MEC 호스트 정보(예: URI 또는 IP 주소)를 수신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 수시된 복수 개의 MEC 호스트 중 어느 하나의 MEC 호스트를 선택하여 통신할 수 있다. 다양한 실시예들에 따르면, 전자 장치(101)는 MEC 어플리케이션이 동작할 수 있는 복수 개의 MEC 호스트에 대하여, 우선 순위에 따라 선택할 수 있다. 일 실시예에 따르면, 우선 순위는 전자 장치(101)와 MEC 호스트 간의 지연 시간(latency) 측정 정보 또는 MEC 호스트의 위치 정보에 적어도 기반하여 결정될 수 있다.
이하에서, 다양한 실시예들에 따라, 전자 장치(101)에서 일반 클라이언트 어플리케이션(general client Apps)에 대한 DNS 캐싱 데이터와 별도로, MEC 클라이언트 어플리케이션(MEC client Apps)에 대한 DNS 캐싱 데이터를 유지 및/또는 관리하는 동작을 설명한다.
도 34는 다양한 실시예들에 따른 전자 장치(101)에서 MEC 용 로컬 DNS 캐시를 별도로 운용하는 예를 도시하는 도면이다.
도 34를 참조하면, 도 34는 MEC 용 로컬 DNS 캐시(예: 제2 DNS 캐시(3430))를 전자 장치(101)의 MSE(530)와 별도로 구분하여 구성하는 예를 나타낼 수 있다. 일 실시예에 따르면, 일반 클라이언트 어플리케이션(general client Apps)(3410)은 제1 DNS 캐시(3420)로 DNS 캐싱을 수행할 수 있고, MEC 클라이언트 어플리케이션(MEC Client Apps)(510)은 제2 DNS 캐시(3430)로 DNS 캐싱을 수행할 수 있다. 예를 들어, 일반 클라이언트 어플리케이션(3410)은 제1 DNS 캐시(3420)를 이용할 수 있고, MEC 클라이언트 어플리케이션(510)은 제2 DNS 캐시(3430)를 이용할 수 있다.
일 실시예에 따르면, 클라이언트 애플리케이션의 접근하고자 하는 URI에 대해 DNS 리졸빙 API를 사용하여 요청만 수행하고 그에 대한 IP 주소를 수신할 수 있다. 예를 들어, MSE(530)(예: DHL(535))(또는 전자 장치(101)의 OS, 또는 프레임워크(framework) 상의 DNS 처리 모듈)는 클라이언트 어플리케이션의 해당 요청을 DNS 쿼리(예: FQDN) 메시지로 변경하여 DNS 서버(2320)로 요청하고, DNS 응답(예: FQDN에 대응하는 IP 주소)를 수신하여 이를 캐싱하고, 클라이언트 어플리케이션에 전달할 수 있다. 일 실시예에 따르면, MSE(530)는 클라이언트 어플리케이션 별 똔 URI(FQDN) 별로 어떠한 DNS 캐시를 사용할 지에 대한 결정을 할 수 있으며, 그에 따라 별도 DNS 처리 모듈(예: 도 34) 또는 MSE의 DHL(도 35)이 제1 DNS 캐시(3420) 또는 제2 DNS 캐시(3430)를 참조하여 IP 주소를 클라이언트 어플리케이션에 전달할 수 있다. 일 실시예에 따라, DNS 처리 모듈 또는 DHL은 요청받은 URI(FQDN)에 대해 DNS 캐시를 먼저 참조하여 해당 URI에 대응되는 IP가 있으면 이를 전달하고, 캐시에 없을 경우 DNS 서버(2320)로 DNS 쿼리를 수행할 수 있다.
다양한 실시예들에 따라, 일반 클라이언트 어플리케이션(3410)과 MEC 클라이언트 어플리케이션(510)을 구분하여, DNS 캐싱을 수행하는 것과 관련하여, 후술하는 도면(예: 도 36)을 참조하여 상세히 설명된다.
도 35는 다양한 실시예들에 따른 전자 장치(101)에서 MSE(530) 내에 MEC 용 로컬 DNS 캐시를 운용하는 예를 도시하는 도면이다.
도 35를 참조하면, 도 35는 MEC 용 로컬 DNS 캐시(예: 제2 DNS 캐시(3430)를 전자 장치(101)의 MSE(530) 내에 구성하는 예를 나타낼 수 있다. 일 실시예에 따르면, 일반 클라이언트 어플리케이션(3410)은 제1 DNS 캐시(3420)로 DNS 캐싱을 수행할 수 있고, MEC 클라이언트 어플리케이션(510)은 제2 DNS 캐시(3430)로 DNS 캐싱을 수행할 수 있다. 예를 들어, 일반 클라이언트 어플리케이션(3410)은 제1 DNS 캐시(3420)를 이용할 수 있고, MEC 클라이언트 어플리케이션(510)은 제2 DNS 캐시(3430)를 이용할 수 있다.
일 실시예에 따르면, 클라이언트 애플리케이션의 접근하고자 하는 URI에 대해 DNS 리졸빙 API를 사용하여 요청만 수행하고 그에 대한 IP 주소를 수신할 수 있다. 예를 들어, MSE(530)(예: DHL(535))(또는 전자 장치(101)의 OS, 또는 프레임워크(framework) 상의 DNS 처리 모듈)는 클라이언트 어플리케이션의 해당 요청을 DNS 쿼리(예: FQDN) 메시지로 변경하여 DNS 서버(2320)로 요청하고, DNS 응답(예: FQDN에 대응하는 IP 주소)를 수신하여 이를 캐싱하고, 클라이언트 어플리케이션에 전달할 수 있다. 일 실시예에 따르면, MSE(530)는 클라이언트 어플리케이션 별 똔 URI(FQDN) 별로 어떠한 DNS 캐시를 사용할 지에 대한 결정을 할 수 있으며, 그에 따라 별도 DNS 처리 모듈(예: 도 34) 또는 MSE의 DHL(도 35)이 제1 DNS 캐시(3420) 또는 제2 DNS 캐시(3430)를 참조하여 IP 주소를 클라이언트 어플리케이션에 전달할 수 있다. 일 실시예에 따라, DNS 처리 모듈 또는 DHL은 요청받은 URI(FQDN)에 대해 DNS 캐시를 먼저 참조하여 해당 URI에 대응되는 IP가 있으면 이를 전달하고, 캐시에 없을 경우 DNS 서버(2320)로 DNS 쿼리를 수행할 수 있다.
다양한 실시예들에 따라, 일반 클라이언트 어플리케이션(3410)과 MEC 클라이언트 어플리케이션(510)을 구분하여, DNS 캐싱을 수행하는 것과 관련하여, 후술하는 도면(예: 도 36)을 참조하여 상세히 설명된다.
도 36은 다양한 실시예들에 따라 도메인 이름에 대한 IP 주소를 이용하는 동작을 도시하는 도면이다.
도 36을 참조하면, 네트워크 환경(3600)(예: 도 3의 네트워크 환경(300))에서, 제1 상태(3601)는 MEC 서비스 모듈(410)(예: MSE(530))이 비활성화(disabled)된 상태를 나타낼 수 있고, 제2 상태(3602)는 MEC 서비스 모듈(410)이 활성화(enabled)된 상태를 나타낼 수 있다.
일 실시예에 따르면, 전자 장치(101)는 도메인 이름 및 도메인 이름에 대한 IP 주소를 저장하도록 구성되는 제1 DNS 캐시(domain name server cache)(3610) 및 제2 DNS 캐시(3620)를 포함할 수 있다. 일 실시예에 따르면, 제1 DNS 캐시(3610)는 일반적인 어플리케이션의 어플리케이션 이름, 도메인 이름 또는 도메인 이름에 대한 IP 주소 중 적어도 하나를 저장할 수 있고, 제2 DNS 캐시(3620)는 MEC 어플리케이션(460)의 어플리케이션 이름, 도메인 이름, 또는 도메인 이름에 대한 IP 주소 중 적어도 하나를 저장할 수 있다. 전자 장치(101)는 도메인 이름에 매핑되는 IP 주소로 접속하므로, 일 실시예에 따르면 도메인 이름 및 도메인 이름에 대한 IP 주소는 쌍(pair)으로 저장될 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 어플리케이션에 대한 도메인 이름을 프록시 서버(예: 도 4의 MMP 서버(430)(또는 LCM 프록시 서버) 또는 별도의 프록시 서버)로부터 획득할 수 있다. 도메인 이름은, 예를 들어, FQDN(fully qualified domain name) 또는 URI 중 적어도 하나를 포함할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 도메인 이름을 디스커버리 절차에서 획득할 수 있다.
일 실시예에 따르면, MEC 서비스 모듈(410)은 도메인 이름에 기반하여 도메인 이름에 대한 IP 주소를 획득할 수 있다. MEC 서비스 모듈(410)은 획득된 IP 주소가 MEC 서비스를 지원하는 MEC 어플리케이션에 접근할 수 있는 도메인 이름에 대한 IP 주소이면, IP 주소를 제2 DNS 캐시(3620)에 저장할 수 있다.
일 실시예에 따르면, 어플리케이션(예: 클라이언트 어플리케이션(510))이 도메인 이름(예: http:www.xxx.com)에 접근하려 할 때, MEC 서비스 모듈(410)이 비활성화된 상태(예: 제1 상태(3601))이면, 어플리케이션(510)은 제1 DNS 캐시(3610)에 저장된 도메인 이름의 IP 주소(예: 111.222.333)를 이용하여 인터넷(3630)을 통해 연결된 리모트(또는 중앙(central)) 서버(3640)로 접근할 수 있다. 예를 들어, MEC 서비스 모듈(410)은 MEC 서비스 모듈(410)이 비활성화 된 상태이면 제1 DNS 캐시(3610)에 저장된 IP 주소(예: 111.222.333)를 참조하여 도메인 이름을 IP 주소로 변환할 수 있다. 어플리케이션(510)이 접근하려는 도메인 이름에 대응하는 IP 주소가 제1 DNS 캐시(3610)에 없으면, MEC 서비스 모듈(410)은 별도의 서버(예: DNS 서버)로 IP 주소를 요청할 수 있다.
일 실시예에 따라 MEC 서비스 모듈(410)이 활성화된 상태(예: 제2 상태(3602))이면, MEC 서비스 모듈(410)은 어플리케이션(510)이 접근하려는 도메인 이름을 제2 DNS 캐시(3620)를 참조하여 도메인 이름에 대응하는 IP 주소(예: 10.22.33)로 변환하고, 변환된 IP 주소를 통해 어플리케이션(510)이 MEC 시스템(405)에 포함되는 MEC 어플리케이션(460)에 접근하도록 유도할 수 있다. 어플리케이션(510)이 접근하려는 도메인 이름에 대응하는 IP 주소가 제2 DNS 캐시(3620)에 없으면, MEC 서비스 모듈(410)은 별도의 서버(예: DNS 서버)로 IP 주소를 요청할 수 있다.
도 37은 다양한 실시예들에 따라 IP 주소를 공유하기 위한 신호 흐름도(3700)를 도시한다.
도 37을 참조하면, DNS 서버(2320)는 MEC 시스템(405)과 별도의 개체일 수도 있고, MEC 시스템(405)에 포함될 수도 있다.
동작 3705에서, MEC 서비스 모듈(410)(예: MSE(530))는 MEC 시스템(405)(예: 도 4의 MMP 서버(430)(또는 LCM 프록시 서버)에 어플리케이션(예: 클라이언트 어플리케이션(510))에 대한 도메인 이름을 요청할 수 있다. 도메인 이름은, 예를 들어, FQDN을 포함할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 어플리케이션(510)에 대한 도메인 이름과 함께 DNS 서버(2320)의 주소를 요청할 수 있다.
동작 3710에서, MEC 시스템(405)은 도메인 이름을 포함하는 정보를 MEC 서비스 모듈(410)에게 전송할 수 있다. 일 실시예에 따르면, MEC 시스템(405)은 도메인 이름과 함께 DNS 서버(2320)의 주소를 MEC 서비스 모듈(410)에게 전송할 수 있다.
일 실시예에 따르면, 동작 3705 및 동작 3710은 MEC 디스커버리 절차에 포함될 수 있다. 예를 들어, MEC 서비스 모듈(410)은 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보와 함께 도메인 이름을 요청할 수 있다. 다른 예를 들어, MEC 서비스 모듈(410)은 MEC 디스커버리 절차에서 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보와 별도로 도메인 이름을 요청할 수도 있다. MEC 시스템(405)은 도메인 이름과 MEC 시스템(405)이 제공 가능한 어플리케이션들에 관한 정보를 함께 전송하거나, 또는 별도로 전송할 수 있다.
다른 실시예에 따르면, MEC 서비스 모듈(410)은 동작 3705 및 동작 3710을 MEC 디스커버리 절차와 별도로 수행할 수도 있다. 예를 들어, MEC 서비스 모듈(410)은 어플리케이션(510)이 전자 장치(101)에 설치될 때, 전자 장치(101)의 이동성과 관련된 이벤트를 감지할 때, 어플리케이션(510)이 도 20의 제1 조건을 만족함을 감지할 때, 또는 지정된 주기에 따라서 동작 3705 및 동작 3710을 수행할 수 있다.
동작 3715에서, 어플리케이션(510)은 도메인 이름에 대한 접근을 요청할 수 있다. 일 실시예에 따르면, 동작 3715는 DNS 쿼리(query)로 지칭될 수 있다. 일 실시예에 따르면, 어플리케이션(510)이 MEC 어플리케이션(예: 도 36의 ME 어플리케이션(460))과 MEC 기반 데이터 전송을 수행하기 위해서는 MEC 어플리케이션(460)에 대한 IP 주소가 필요하므로, 이를 위한 DNS 쿼리를 수행할 수 있다.
일 실시예에 다르면, MEC 서비스 모듈(410)은 DNS 쿼리에 포함된 정보 및/또는 제2 DNS 캐시(예: 도 36의 제2 DNS 캐시(3620))에 저장된 정보에 기반하여 동작 3720 내지 동작 3725를 수행하거나 수행하지 않을 수 있다. 예를 들어, MEC 서비스 모듈(410)은 DNS 쿼리에 포함된 어플리케이션의 이름 또는 도메인 이름(예: FQDN 또는 URI) 중 적어도 하나에 대응하는, 제2 DNS 캐시(3620)에 저장된 어플리케이션의 이름 또는 도메인 이름 중 적어도 하나를 식별할 수 있다.
일 실시예에 따라, 식별된 어플리케이션의 이름 또는 도메인 이름 중 적어도 하나에 대응하는 IP 주소가 제2 DNS 캐시(3620)에 존재하면, 동작 3730에서 MEC 서비스 모듈(410)은 IP 주소를 어플리케이션(510)에게 전달(transfer)할 수 있다.
일 실시예에 따라, 식별된 어플리케이션의 이름 또는 도메인 이름 중 적어도 하나에 대응하는 IP 주소가 제2 DNS 캐시(3620)에 존재하지 않다면, 동작 3720에서, MEC 서비스 모듈(410)은 DNS 서버(2320)로 MEC 어플리케이션에 대한 IP 주소를 요청할 수 있다. 동작 3720에서 전송되는 메시지(또는 데이터 패킷)는, 예를 들어, 동작 3710에서 MEC 시스템(405)으로부터 수신된 도메인 이름을 포함할 수 있다. 동작 3725에서, DNS 서버(2320)는 MEC 어플리케이션에 대한 IP 주소를 MEC 서비스 모듈(410)에게 전송할 수 있다. 동작 3730에서, MEC 서비스 모듈(410)은 수신된 IP 주소를 어플리케이션(510)에게 전달할 수 있다.
일 실시예에 따른 도 37은 DNS 쿼리 동작에 응답하여 MEC 서비스 모듈(410)이 IP 주소를 요청하는 실시예를 도시하지만, 다른 실시 예들에 따르면, MEC 서비스 모듈(410)은 DNS 쿼리와 별도로 IP 주소를 DNS 서버(2320)에게 요청할 수도 있다. 이러한 경우, MEC 서비스 모듈(410)이 IP 주소를 요청하기 위해서는 MEC 어플리케이션에 대한 도메인 이름이 요구되므로, MEC 서비스 모듈(410)은 동작 3710 이후에 IP 주소를 요청할 수 있다. 예를 들어, MEC 서비스 모듈(410)은 컨텍스트 생성 동작을 통해 IP주소를 요청할 수도 있다.
동작 3735에서, 어플리케이션(510)은 MEC 서비스 모듈(410)로부터 전달받은 IP 주소를 이용하여 MEC 시스템(405)에 포함된 MEC 어플리케이션과 데이터 전송을 수행할 수 있다.
다양한 실시예들에 따를 때, 전자 장치(101)는 복수의 어플리케이션들에 대응하는 복수의 MEC 어플리케이션들의 IP 주소를 MEC 서비스 모듈(410)을 통하여 일괄적으로 관리할 수 있으므로, 자원 소모를 줄이고 안정적인 서비스를 제공할 수 있다.
도 38은 다양한 실시예들에 따른 전자 장치(101)에서 도메인 이름에 대한 IP 주소를 이용하는 방법을 도시하는 흐름도이다.
다양한 실시예들에서, 도 38에 도시된 동작들은, 전자 장치(101) 또는 전자 장치(101)에 포함된 구성 요소(예: 도 1의 프로세서(120) 또는 도 4의 MEC 서비스 모듈(410))에 의하여 수행될 수 있다.
도 38을 참조하면, 동작 3855에서, 전자 장치(101)(예: MEC 서비스 모듈(410))는 어플리케이션(예: 클라이언트 어플리케이션(510))이 도메인 이름에 접근을 요청함을 감지할 수 있다(예: 도 37의 동작 3715).
동작 3860에서, 전자 장치(101)는 어플리케이션(510)이 접근을 요청하는 도메인 이름이 MEC를 지원할 수 있는지 확인할 수 있다. 예를 들어, 전자 장치(101)는 디스커버리 절차를 통해 수신된 정보에 기반하여, 어플리케이션(510)이 접근을 요청하는 도메인 이름이 MEC를 지원할 수 있는지 여부를 확인할 수 있다.
동작 3860에서, 전자 장치(101)는 접근 요청된 도메인 이름이 MEC를 지원 가능하면(예: 동작 3860의 YES), 동작 3865에서, 제2 DNS 캐시(3820)를 이용하여 도메인 이름에 접근할 수 있다.
동작 3860에서, 전자 장치(101)는 접근 요청된 도메인 이름이 MEC를 지원 가능하지 않으면(예: 동작 3860의 NO), 동작 3870에서, 제1 DNS 캐시(3610)를 이용하여 도메인 이름에 접근할 수 있다.
도 39는 다양한 실시예들에 따른 전자 장치(101)에서 IP 주소를 요청하는 방법을 도시하는 흐름도이다.
다양한 실시예들에서, 도 39에 도시된 동작들은, 전자 장치(101) 또는 전자 장치(101)에 포함된 구성 요소(예: 도 1의 프로세서(120) 또는 도 4의 MEC 서비스 모듈(410))에 의하여 수행될 수 있다. 일 실시예에 따라, 도 39에 도시된 동작들은, 예를 들어, 도 38의 동작 3865의 일 실시예일 수 있다.
도 39를 참조하면, 동작 3940에서, MEC 서비스 모듈(410)는 제2 DNS 캐시(3620)에 MEC 어플리케이션에 대한 IP 주소가 저장되었는지를 식별할 수 있다.
동작 3940에서, MEC 서비스 모듈(410)은 제2 DNS 캐시(3620)에 IP 주소가 저장되어 있으면(예: 동작 3940의 YES), 동작 3945에서, 제2 DNS 캐시(3620)에 저장된 IP 주소를 어플리케이션(510)에게 전달할 수 있다.
동작 3940에서, MEC 서비스 모듈(410)은 제2 DNS 캐시(3620)에 IP 주소가 저장되어 있지 않으면(예: 동작 3940의 NO), 동작 3950에서, DNS 서버(2320)에게 IP 주소를 요청할 수 있다.
동작 3955에서, MEC 서비스 모듈(410)은 DNS 서버(2320)로부터 IP 주소를 수신할 수 있다. 일 실시예에 따르면, 동작 3945를 수행하기 이전에 MEC 서비스 모듈(410)은 수신된 IP 주소를 일시적으로 제2 DNS 캐시(3620)에 저장할 수 있다. 일 실시 예에 따라, 동작 3955에서, MEC 서비스 모듈(410)이 IP 주소와 함께 유효 기간을 나타내는 정보를 포함하면, MEC 서비스 모듈(410)은 정보가 나타내는 유효기간 동안에 IP 주소를 제2 DNS 캐시(3620)에 저장할 수 있다.
동작 3945에서, MEC 서비스 모듈(410)은 제2 DNS 캐시(3620)에 저장된 IP 주소를 어플리케이션(510)에게 전달할 수 있다.
도 40은 다양한 실시예들에 따른 전자 장치(101)에서 IP 주소를 이용하여 MEC 기반 데이터 전송을 수행하는 방법을 도시하는 흐름도이다.
다양한 실시예들에서, 도 38에 도시된 동작들은, 전자 장치(101) 또는 전자 장치(101)에 포함된 구성 요소(예: 도 1의 프로세서(120) 또는 도 4의 MEC 서비스 모듈(410))에 의하여 수행될 수 있다.
도 40을 참조하면, 동작 4065에서, 전자 장치(101)는 MEC 서비스 모듈(410)(예: MSE(530))와 관련된 제1 주소를 포함하고, 도메인 이름을 요청하는 제1 데이터 패킷을 적어도 하나의 외부 서버(예: MEC 시스템(405)(또는 엣지 서버 또는 MEC 서버)의 일부 구성 요소)로 전송할 수 있다. 일 실시예에 따르면, 제1 주소는 전자 장치(101)의 IP 주소 및 MEC 서비스 모듈(410)과 관련된 IP 포트 식별자를 포함할 수 있다. 일 실시예에 따르면, 도메인 이름은 외부 서버에 포함된 MEC 어플리케이션(예: 도 36의 MEC 어플리케이션(460))과 관련된 도메인 이름일 수 있다.
일 실시예에 따르면, 전자 장치(101)는 어플리케이션(510)이 MEC 어플리케이션에 대한 접근을 요청하는 것에 응답하여, 제1 데이터 패킷을 전송할 수 있다. 예를 들어, 어플리케이션(510)이 전자 장치(101)에 설치되거나 또는 어플리케이션(510)의 실행을 요청하는 사용자 입력이 수신되면, 어플리케이션(510)은 MEC 어플리케이션에 대한 접근을 요청할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는 MEC 디스커버리 절차에서 제1 데이터 패킷을 전송할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는 전자 장치(101)의 이동성이 감지되거나, 어플리케이션(510)이 MEC에 기반한 데이터 전송을 수행할 수 있는 조건(예: 도 20의 제1 조건)이 만족되면, 제1 데이터 패킷을 전송할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는 지정된 주기로 제1 데이터 패킷을 전송할 수 있다.
동작 4070에서, 전자 장치(101)는 도메인 이름을 포함하는 정보를 적어도 하나의 외부 서버로부터 수신할 수 있다. 도메인 이름은, 예를 들어, MEC 어플리케이션들과 연관된 도메인 이름일 수 있다.
동작 4075에서, 전자 장치(101)는 제1 주소 및 MEC 어플리케이션들과 연관된 도메인 이름을 포함하고, 도메인 이름에 대한 IP 주소를 요청하는 제2 데이터 패킷을 적어도 하나의 외부 서버(예: DNS 서버(2320))로 전송할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 MEC 디스커버리 절차에서 제2 데이터 패킷을 전송하거나, 전자 장치(101)의 이동성이 감지되거나, 제1 조건이 만족되거나, 또는 지정된 주기로 제2 데이터 패킷을 전송할 수 있다.
동작 4080에서, 전자 장치(101)는 적어도 하나의 외부 서버로부터 도메인 이름에 대한 IP 주소를 포함하는 정보를 수신할 수 있다.
동작 4085에서, 전자 장치(101)는 수신된 IP 주소에 기반하여, 사용자 데이터 및 제2 주소를 포함하는 제3 데이터 패킷을 적어도 하나의 외부 서버(예: MEC 시스템(405)의 일부 구성 요소)로 전송할 수 있다. 제2 주소는 전자 장치(101)의 IP 주소 및 어플리케이션(510)과 관련된 IP 포트 식별자를 포함할 수 있다. 일 실시예에 따르면, 어플리케이션(510)과 관련된 IP 포트 식별자는 MEC 서비스 모듈(410)과 관련된 IP 포트 식별자와 상이할 수 있다.
다른 실시예에 따라, MEC 어플리케이션과 연관된 도메인 이름에 대한 IP 주소가 전자 장치(101)에 기 저장되어 있는 경우, 전자 장치(101)는 동작 4075 및 동작 4080을 생략하고, 동작 4085를 수행할 수 있다.
도 41은 다양한 실시예들에 따른 디스커버리 절차에서 DNS 리졸빙 동작의 예를 도시하는 도면이다.
도 41에 도시한 바와 같이, 도 41은 클라이언트 어플리케이션(510)의 DNS 쿼리에 대한 DNS 리졸빙 동작을 나타낼 수 있다. 일 실시예에 따르면, DNS 리졸빙 동작은, DNS 서버(2320)가 비활성화된 상태인 경우의 동작(예: 동작 4110)과 DNS 서버(2320)가 활성화된 상태인 경우의 동작(예: 동작 4130)을 포함할 수 있다.
일 실시예에 따르면, 동작 4110의 DNS 리졸빙 동작은, 예를 들어, DNS 캐시(2310)에서 MEC용 로컬 DNS 캐시(예: 제2 DNS 캐시(3430))가 비활성화된 상태의 동작 예를 나타낼 수 있다. 도 41을 참조하면, 클라이언트 어플리케이션(510)은 URI에 대한 DNS 쿼리를 DNS 캐시(2310)로 전달(동작 4111)할 수 있고, DNS 캐시(2310)는 클라이언트 어플리케이션(510)의 DNS 쿼리에 대한 응답(예: DNS Cache Response)을 클라이언트 어플리케이션(510)에 전달(동작 4113)할 수 있다. 일 실시예에 따라, DNS 캐시(2310)는 MEC 어플리케이션의 어플리케이션 이름, 도메인 이름, 또는 도메인 이름에 대한 IP 주소 중 적어도 하나를 저장할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(510)의 URI에 대한 DNS 쿼리 시 DNS 캐시(2310)에 해당 URI의 MEC 어플리케이션의 IP 주소가 존재하지 않는 경우(예: DNS 캐시 미스(cache miss)), 클라이언트 어플리케이션(510)은 DNS 서버(2320)로 DNS 쿼리를 전달(동작 4115)하고, DNS 서버(2320)로부터 DNS 쿼리에 대응하는 응답(4117)에 기반하여, IP 주소를 획득할 수 있다.
일 실시예에 따르면, 동작 4130의 DNS 리졸빙 동작은, 예를 들어, DNS 캐시(2310)에서 MEC용 로컬 DNS 캐시(예: 제2 DNS 캐시(3430)가 활성화된 상태의 동작 예를 나타낼 수 있다. 도 41을 참조하면, 클라이언트 어플리케이션(510)은 URI에 대한 DNS 쿼리를 MSE(530)를 통해 DNS 캐시(2310)로 전달(동작 4131, 동작 4133)할 수 있다. 일 실시예에 따라, DNS 캐시(2310)는 MSE(530)로 DNS 쿼리에 대한 DNS 응답을 전달(동작 4135)할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(510)의 URI에 대한 DNS 쿼리 시 DNS 캐시(2310)에 해당 URI의 MEC 어플리케이션의 IP 주소가 존재하지 않는 경우(예: DNS 캐시 미스), MSE(530)는 DNS 서버(2320)로 DNS 쿼리를 전달(동작 4137)하고, DNS 서버(2320)로부터 DNS 쿼리에 대응하는 응답을 수신(동작 4139)하고, 수신된 응답을 클라이언트 어플리케이션(510)에 포워딩(동작 4141) 할 수 있다.
일 실시예에 따르면, 클라이언트 어플리케이션(510)의 URI에 대한 DNS 쿼리 시 DNS 캐시(2310)에 해당 URI의 MEC 어플리케이션의 IP 주소가 있을 경우, 해당 주소로 MEC 어플리케이션에 접속할 수 있다. 일 실시예에 따르면, DNS 리졸빙에서, DNS 캐시 미스 시, DNS 리졸빙을 통해 리모트(remote) 서버(예: 도 3의 리모트 서버(306)) 또는 Client App-driven MEC 어플리케이션에 접속할 수 있다. 일 실시예에 따르면, DNS 리졸빙에서, DNS 프록시(proxy)가 있을 경우, DNS 프록시가 클라이언트 어플리케이션의 DNS 쿼리를 후킹(hooking)하여 MEC 앱 리스트에 따라 DNS 리졸빙을 수행할 수 있다.
일 실시예에 따르면, MSE(530)에서는 3rd 파티 어플리케이션(party application)에 DNS Pre-resolving 또는 DNS 프록시 기능을 지원할 수 있다. 예를 들어, 기존 기본 PDU 세션을 통해 데이터 연결이 된 상태에서 MEC 용 클라이언트 어플리케이션(510)이 특정 서비스 접속을 위한 DNS 쿼리를 하면, DNS 프록시가 DNS 쿼리를 가로채서, MEC 용 도메인 이름으로 DNS 서버(2320)에 쿼리를 하거나, 또는 DNS 캐시(2310)에서 룩업(lookup)하여 해당 MEC 도메인 IP 주소를 반환할 수 있다. 이를 통해, 3rd 파티 어플리케이션이 별도의 소프트웨어 수정 없이, 그리고 오퍼레이터의 별도 트래픽 필터링(traffic filtering)(또는 steering) 작업 없이 MEC 서비스를 제공할 수 있다.
도 42는 다양한 실시예들에 따른 디스커버리 절차에서 서비스 클로즈 절차의 예를 도시하는 도면이다.
도 42에 도시한 바와 같이, 도 42는 일 실시예에 따른 MEC 디스커버리 절차에서 MEC 서비스 클로즈(MEC Service Close)(예: MEC Application Context Delete)에 관한 동작 예를 나타낼 수 있다. 일 실시예에 따라, 어플리케이션 컨텍스트 삭제 동작은, 예를 들면, 클라이언트 어플리케이션(510)이 종료되는 경우, MSA(520)가 앱 종료 이벤트를 MSE API를 통해 MSE(530)에 전달하는 것으로부터 수행될 수 있다. 다양한 실시예들에 따르면, 어플리케이션 컨텍스트 삭제는, 클라이언트 어플리케이션 사용이 종료되거나(제1 케이스), 또는 클라이언트 어플리케이션이 직접 MSE API를 통해 컨텍스트 삭제(contextDelete)를 요청(제2 케이스)하는 경우에 수행할 수 있으며, 도 42에서는 제1 케이스에 따라 어플리케이션 컨텍스트 삭제를 수행하는 동작 예를 나타낼 수 있다.
도 42를 참조하면, 동작 4201에서, 특정 클라이언트 어플리케이션(510)이 종료되는(App stop detected) 경우, 해당 클라이언트 어플리케이션(510)은 어플리케이션의 사용 종료를 알리는 정보(예: App Stop)를 MSA(520)로 제공할 수 있다.
동작 4203에서, MSA(520)는 클라이언트 어플리케이션(510)의 종료를 알리는 정보를 수신하면, 클라이언트 어플리케이션(510)의 상태(state)를 통지(notify)하는 통지 메시지(예: notifyClientAppState)를 MSE(530)로 제공할 수 있다. 일 실시예에 따라, 통지 메시지(예: notifyClientAppState)는, 예를 들어, 클라이언트 어플리케이션의 상태(예: STOP)와 클라이언트 어플리케이션의 이름(예: clientAppName)(및/또는 UID)을 포함(예: notifyClientAppState(STOP, clientAppName))하여 제공할 수 있다.
동작 4205에서, MSE(530)는 MSA(520)로부터 통지 메시지(예: notifyClientAppState)를 수신하고, 수신된 통지 메시지의 정보에 기반하여 어플리케이션 컨텍스트 삭제 동작을 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 삭제 동작(동작 4205)은, 동작 4210, 동작 4220, 동작 4230을 포함할 수 있다.
동작 4210에서, MSE(530)는 어플리케이션 컨텍스트 삭제를 요청하는 요청 메시지(예: HTTP DELETE AppContext Data)를 MMP 서버(430)로 전송할 수 있다. 일 실시예에 따르면, MSE(530)는 여러 개의 클라이언트 어플리케이션이 한 번에 종료되는 경우(예: 파워 오프(power off) 또는 네트워크 오프(network off)), 컨텍스트 삭제 요청을 여러 번 반복하여 MMP 서버(430)로 전송하거나, 또는 하나의 컨텍스트 삭제 요청에, 여러 컨텍스트 정보(Context Info)를 포함하여 MMP 서버(430)로 전송할 수 있다.
동작 4220에서, MMP 서버(430)는 MSE(530)로부터 수신된 요청 메시지에 대응하는 응답으로 응답 메시지(예: HTTP OK 204 No Content)를 MSE(530)로 제공할 수 있다. 일 실시예에 따르면, MMP 서버(430)는 구동 중인 MEC 어플리케이션에서 컨텍스트 삭제 요청된 MEC 어플리케이션을 종료하고, 그 결과(예: No content)를 응답 메시지에 포함하여, MSE(530)로 제공할 수 있다.
동작 4230에서, MSE(530)는 PDU 세션 해제(session release)를 수행할 수 있다. 일 실시예에 따르면, MSE(530)는 MMP 서버(430)로 컨텍스트 삭제 요청 후, 필요에 따라(예: PDU 세션 해제가 필요한 경우), 해당 PDU 세션의 해제(release) 작업을 수행할 수 있다. 예를 들어, URSP 규칙(또는 CARP 규칙)은 인증 절차의 결과(예: MSA(520)가 수신하여 MSE(530)에 전달), 또는 MSE(530)가 어플리케이션 룩업(예: App lookup) 결과, 또는 컨텍스트 생성(Context Create) 결과로 수신할 수 있으며, URSP 규칙에 새로운 DNN 규칙이 설정되어 있는 경우, PDU 세션 설정(setup)을 수행할 수 있다. 일 실시예에 따르면, PDU 세션 설정(예: 도 17의 PDU 세션 생성, 도 18의 PDU 세션 해제)은 전술한 도 17 또는 도 18을 참조한 설명 부분에서 설명한 바와 같이 MSE(530)가 모뎀(1700)에 요청하면, 모뎀(1700)에서 5G 망(또는 코어 망)의 SMF에 요청하여 생성/해제할 수 있다.
도 43은 다양한 실시예들에 따른 디스커버리 절차에서 서비스 클로즈 절차의 예를 도시하는 도면이다.
도 43에 도시한 바와 같이, 도 43은 일 실시예에 따른 MEC 디스커버리 절차에서 MEC 서비스 클로즈(MEC Service Close)(예: MEC Application Context Delete)에 관한 동작 예를 나타낼 수 있다. 일 실시예에 따라, 어플리케이션 컨텍스트 삭제 동작은, 예를 들면, 클라이언트 어플리케이션(510)이 컨텍스트 삭제 요청을 MSE API를 통해 MSE(530)에 전달하는 것으로부터 수행될 수 있다. 다양한 실시예들에 따르면, 어플리케이션 컨텍스트 삭제는, 클라이언트 어플리케이션 사용이 종료되거나(제1 케이스), 또는 클라이언트 어플리케이션이 직접 MSE API를 통해 컨텍스트 삭제(contextDelete)를 요청(제2 케이스)하는 경우에 수행할 수 있으며, 도 43에서는 제2 케이스에 따라 어플리케이션 컨텍스트 삭제를 수행하는 동작 예를 나타낼 수 있다.
도 43을 참조하면, 동작 4301에서, 클라이언트 어플리케이션(510)은 MSE(530)로 컨텍스트 삭제를 위한 메시지(예: contextDelete)를 전달할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(510)은 사용이 종료되는 경우, 해당 클라이언트 어플리케이션에 관련된 정보(예: 어플리케이션 이름(appName) 또는 UID)와 함께 컨텍스트 삭제 요청을 MSE API를 통해 MSE(530)로 전달할 수 있다.
동작 4303에서, MSE(530)는 클라이언트 어플리케이션(510)으로부터 컨텍스트 삭제를 위한 메시지를 수신하고, 수신된 메시지의 정보(예: 어플리케이션 이름)에 기반하여 어플리케이션 컨텍스트 삭제 동작을 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 삭제 동작(동작 4303)은, 동작 4310, 동작 4320, 동작 4330을 포함할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 삭제 동작(동작 4303)은, 전술한 도 42에서 동작 4205의 어플리케이션 컨텍스트 삭제 절차에 따른 동작 4210, 동작 4220, 동작 4230을 참조한 설명 부분에서 설명한 바에 각각 대응할 수 있다.
본 명세서와 도면에 개시된 본 개시의 다양한 실시예들은 본 개시의 기술 내용을 쉽게 설명하고 본 개시의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 개시의 범위를 한정하고자 하는 것은 아니다. 따라서 본 개시의 범위는 여기에 개시된 실시예들 이외에도 본 개시의 기술적 사상을 바탕으로 도출되는 모든 변경 또는 변형된 형태가 본 개시의 범위에 포함되는 것으로 해석되어야 한다.

Claims (15)

  1. 전자 장치에 있어서,
    네트워크 인터페이스; 및
    프로세서를 포함하고, 상기 프로세서는,
    상기 네트워크 인터페이스를 이용하여, 기지국 내에 또는 상기 기지국을 통하여 연결 가능한 적어도 하나의 외부 서버로, 상기 적어도 하나의 외부 서버가 제공 가능한 어플리케이션들에 관한 정보를 획득하고,
    상기 어플리케이션들에 관한 정보에 기반하여, 지정된 조건에 대응하는 어플리케이션을 포함하는 외부 서버를 선택하고,
    상기 선택된 외부 서버와 데이터 전송을 수행하도록 설정된 전자 장치.
  2. 제1항에 있어서, 상기 프로세서는,
    상기 어플리케이션들에 관한 정보를 요청하는 요청 메시지를 상기 적어도 하나의 외부 서버로 전송하고,
    상기 적어도 하나의 외부 서버로부터 상기 어플리케이션들에 관한 정보를 포함하는 응답 메시지를 수신하고,
    상기 응답 메시지로부터 상기 어플리케이션들에 관한 정보를 획득하도록 설정된 전자 장치.
  3. 제2항에 있어서, 상기 프로세서는,
    상기 요청 메시지에 상기 어플리케이션들에 관한 정보의 조건을 지정하여 상기 적어도 하나의 외부 서버로 전송하도록 설정된 전자 장치.
  4. 제3항에 있어서, 상기 요청 메시지는,
    clientappName, locationInfo, deviceType, serviceType, contextType, 또는 URI Request 중 적어도 하나를 포함하는 전자 장치.
  5. 제2항에 있어서, 상기 응답 메시지는,
    referenceURI, clientAppName, clientAppPackageURL, uriTTL, uriLOC, carpRule, DNN, S-NSSAI, accessType, sessionType, mptcp, 또는 fqdnList 중 적어도 하나를 포함하는 전자 장치.
  6. 전자 장치에 있어서,
    네트워크 인터페이스; 및
    프로세서를 포함하고, 상기 프로세서는,
    디스커버리 정책에 기반하여, 지정된 외부 서버로부터 서비스 가능한 어플리케이션의 앱 리스트를 획득하고,
    상기 앱 리스트에 기반하여 상기 전자 장치의 클라이언트 어플리케이션과 연관되고 접속하고자 하는 어플리케이션에 관련된 정보를 상기 지정된 외부 서버로부터 획득하고,
    상기 획득된 정보에 기반하여, 데이터 전송을 위한 호스트를 결정하고,
    상기 호스트와 데이터 전송을 수행하도록 설정된 전자 장치.
  7. 제6항에 있어서, 상기 프로세서는,
    상기 외부 서버와 통신하여 인증 및 권한 부여와 관련된 동작을 수행하는 서비스 에이전트(service agent),
    상기 외부 서버와 통신하여 앱 리스트를 획득하고, 디스커버리(discovery)와 관련된 동작을 수행하는 서비스 인에이블러(service enabler)를 포함하는 전자 장치.
  8. 제7항에 있어서, 상기 프로세서는,
    상기 서비스 에이전트와 상기 서비스 인에이블러 사이의 API를 통해 상기 서비스 인에이블러를 활성화 하고, 상기 서비스 인에이블러를 통해 상기 외부 서버와 디스커버리 절차를 수행하도록 설정된 전자 장치.
  9. 제7항에 있어서, 상기 프로세서는,
    상기 서비스 에이전트에서 상기 서비스 인에이블러로 상기 디스커버리 정책을 설정하는 것을 포함하고,
    상기 디스커버리 정책은 클라이언트 어플리케이션 이름(clientAppName) 및 디스커버리 정책(discoveryPolicy)을 포함하고,
    상기 디스커버리 정책(discoveryPolicy)은 동적 DNN(dynamicDnn)의 사용 여부, 위치 정보(locationInfo), 디바이스 타입(deviceType), 서비스 타입(serviceType), 또는 컨텍스트 타입(contextType) 중 적어도 하나를 포함하는 전자 장치.
  10. 제9항에 있어서, 상기 프로세서는,
    상기 서비스 에이전트로부터 상기 디스커버리 정책 수신에 기반하여 상기 서비스 인에이블러를 활성화 하고, 상시 서비스 인에이블러를 통해 상기 디스커버리 정책에 따라 지정된 조건을 만족하는 앱 리스트를 프록시 서버로 요청하도록 설정된 전자 장치.
  11. 제7항에 있어서, 상기 프로세서는,
    상기 앱 리스트에 상기 클라이언트 어플리케이션과 연관되는 어플리케이션이 없는 경우, 상기 서비스 인에이블러를 통해 프록시 서버로 상기 어플리케이션의 URI를 요청하고,
    상기 앱 리스트에 상기 클라이언트 어플리케이션과 연관되는 어플리케이션이 있는 경우, 상기 어플리케이션의 어플리케이션 이름을 포함하여 상기 프록시 서버로 전송하도록 설정된 전자 장치.
  12. 제11항에 있어서, 상기 프로세서는,
    상기 프록시 서버에 상기 어플리케이션이 없을 경우 상기 프록시 서버로부터 상기 어플리케이션의 다운로드 또는 설치를 위한 어플리케이션 패키지(package) URI을 획득하도록 설정된 전자 장치.
  13. 제11항에 있어서, 상기 프로세서는,
    상기 서비스 인에이블러를 통해 상기 어플리케이션에 대한 URI로 DNS 쿼리(query)를 수행하고,
    상기 DNS 쿼리에 대응하는 DNS 응답으로 획득된 IP 주소를 로컬 DNS 캐시(cache)에 저장하도록 설정된 전자 장치.
  14. 제7항에 있어서, 상기 프로세서는,
    상기 외부 서버로부터 복수의 호스트에 대한 후보 IP 리스트(candidate IP list)가 수신되는 경우, 추가 정보에 기반하여 상기 호스트를 선택하도록 설정되고,
    상기 추가 정보는, 호스트 위치, 사용자 현재 위치, 사용자 속도, 또는 호스트 성능(performance)에 관한 정보를 포함하는 전자 장치.
  15. 전자 장치에 있어서,
    네트워크 인터페이스; 및
    프로세서를 포함하고, 상기 프로세서는,
    디스커버리 정책에 기반하여, 지정된 외부 서버로부터 서비스 가능한 어플리케이션의 앱 리스트를 획득하고,
    클라이언트 어플리케이션에 의한 컨텍스트 생성과 관련된 이벤트에 기반하여, 상기 클라이언트 어플리케이션과 연관되고 접속하고자 하는 어플리케이션에 관련된 정보를 상기 지정된 외부 서버로부터 획득하고,
    상기 획득된 정보에 기반하여, 데이터 전송을 위한 호스트를 선택하고,
    상기 호스트와 데이터 전송을 수행하도록 설정된 전자 장치.
PCT/KR2019/008730 2018-07-13 2019-07-15 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치 WO2020013677A1 (ko)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP19835024.1A EP3731495B1 (en) 2018-07-13 2019-07-15 Method and electronic device for edge computing service
CN201980010111.1A CN111656754B (zh) 2018-07-13 2019-07-15 用于边缘计算服务的方法及其电子装置
AU2019300978A AU2019300978B2 (en) 2018-07-13 2019-07-15 Method and electronic device for edge computing service
CN202211687835.XA CN116232667A (zh) 2018-07-13 2019-07-15 用于边缘计算服务的方法及其电子装置
US16/938,824 US11134127B2 (en) 2018-07-13 2020-07-24 Method and electronic device for providing multi-access edge computing service using multi-access edge computing discovery
US17/486,793 US20220014595A1 (en) 2018-07-13 2021-09-27 Method and electronic device for providing multi-access edge computing service using multi-access edge computing discovery

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
KR10-2018-0081919 2018-07-13
KR20180081919 2018-07-13
KR10-2019-0018833 2019-02-18
KR1020190018833A KR20200007634A (ko) 2018-07-13 2019-02-18 데이터 전송을 수행하기 위한 전자 장치 및 그에 관한 방법
US201962826275P 2019-03-29 2019-03-29
US62/826,275 2019-03-29
KR1020190085343A KR20200007754A (ko) 2018-07-13 2019-07-15 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
KR10-2019-0085343 2019-07-15

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/938,824 Continuation US11134127B2 (en) 2018-07-13 2020-07-24 Method and electronic device for providing multi-access edge computing service using multi-access edge computing discovery

Publications (1)

Publication Number Publication Date
WO2020013677A1 true WO2020013677A1 (ko) 2020-01-16

Family

ID=69142744

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/008730 WO2020013677A1 (ko) 2018-07-13 2019-07-15 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치

Country Status (1)

Country Link
WO (1) WO2020013677A1 (ko)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021150380A1 (en) * 2020-01-22 2021-07-29 Cisco Technology, Inc. Systems and methods for managing mec application hosting
CN113312059A (zh) * 2021-06-15 2021-08-27 北京百度网讯科技有限公司 一种服务处理系统、方法及云原生系统
WO2021194868A1 (en) * 2020-03-24 2021-09-30 Apple Inc. Efficient discovery of edge computing servers
CN113595801A (zh) * 2021-08-09 2021-11-02 湘潭大学 一种基于任务流量和时效性的边缘云网络服务器部署方法
CN113923032A (zh) * 2021-10-12 2022-01-11 成都安恒信息技术有限公司 一种应用访问控制的接入方法
CN113973099A (zh) * 2020-07-24 2022-01-25 中国电信股份有限公司 获取eas的ip地址的方法、装置及系统
CN114125838A (zh) * 2020-08-31 2022-03-01 中国电信股份有限公司 Mec应用接入认证授权方法、系统和mec业务管理平台
CN114528448A (zh) * 2022-02-25 2022-05-24 南京苏维博欣信息技术有限公司 一种全球外贸客户客户画像精准分析系统
TWI768534B (zh) * 2020-11-05 2022-06-21 財團法人工業技術研究院 多重接取邊緣運算裝置及網路接取控制方法
US11626989B2 (en) * 2019-03-21 2023-04-11 Verizon Patent And Licensing Inc. System and method for allocating multi-access edge computing services
US11653323B2 (en) 2020-10-05 2023-05-16 Samsung Electronics Co., Ltd. Method and apparatus for providing service to edge application server (eas) in edge data network (EDN)
US11743342B2 (en) 2021-02-05 2023-08-29 Samsung Electronics Co., Ltd. Electronic device for performing edge computing service and a method for the same

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130080613A1 (en) * 2011-09-26 2013-03-28 Limelight Networks, Inc. Dynamic route requests for multiple clouds
WO2017100640A1 (en) * 2015-12-11 2017-06-15 Interdigital Patent Holdings, Inc. Method and apparatus for enabling third party edge clouds at the mobile edge
KR20180019538A (ko) * 2015-06-18 2018-02-26 소니 주식회사 시스템, 방법 및 단말 장치
WO2018089417A1 (en) * 2016-11-09 2018-05-17 Interdigital Patent Holdings, Inc. Systems and methods to create slices at a cell edge to provide computing services
US20180183855A1 (en) * 2016-12-28 2018-06-28 Intel Corporation Application computation offloading for mobile edge computing

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130080613A1 (en) * 2011-09-26 2013-03-28 Limelight Networks, Inc. Dynamic route requests for multiple clouds
KR20180019538A (ko) * 2015-06-18 2018-02-26 소니 주식회사 시스템, 방법 및 단말 장치
WO2017100640A1 (en) * 2015-12-11 2017-06-15 Interdigital Patent Holdings, Inc. Method and apparatus for enabling third party edge clouds at the mobile edge
WO2018089417A1 (en) * 2016-11-09 2018-05-17 Interdigital Patent Holdings, Inc. Systems and methods to create slices at a cell edge to provide computing services
US20180183855A1 (en) * 2016-12-28 2018-06-28 Intel Corporation Application computation offloading for mobile edge computing

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11626989B2 (en) * 2019-03-21 2023-04-11 Verizon Patent And Licensing Inc. System and method for allocating multi-access edge computing services
US12010565B2 (en) 2020-01-22 2024-06-11 Cisco Technology, Inc. Systems and methods for managing MEC application hosting
WO2021150380A1 (en) * 2020-01-22 2021-07-29 Cisco Technology, Inc. Systems and methods for managing mec application hosting
WO2021194868A1 (en) * 2020-03-24 2021-09-30 Apple Inc. Efficient discovery of edge computing servers
EP4277302A3 (en) * 2020-03-24 2024-01-17 Apple Inc. Efficient discovery of edge computing servers
US11723056B2 (en) 2020-03-24 2023-08-08 Apple Inc. Efficient discovery of edge computing servers
JP2023518296A (ja) * 2020-03-24 2023-04-28 アップル インコーポレイテッド エッジコンピューティングサーバの効率的な発見
CN113973099A (zh) * 2020-07-24 2022-01-25 中国电信股份有限公司 获取eas的ip地址的方法、装置及系统
CN113973099B (zh) * 2020-07-24 2023-12-15 中国电信股份有限公司 获取eas的ip地址的方法、装置及系统
CN114125838A (zh) * 2020-08-31 2022-03-01 中国电信股份有限公司 Mec应用接入认证授权方法、系统和mec业务管理平台
US11653323B2 (en) 2020-10-05 2023-05-16 Samsung Electronics Co., Ltd. Method and apparatus for providing service to edge application server (eas) in edge data network (EDN)
TWI768534B (zh) * 2020-11-05 2022-06-21 財團法人工業技術研究院 多重接取邊緣運算裝置及網路接取控制方法
US11431631B2 (en) 2020-11-05 2022-08-30 Industrial Technology Research Institute Multi-access edge computing device and network access control method
US11743342B2 (en) 2021-02-05 2023-08-29 Samsung Electronics Co., Ltd. Electronic device for performing edge computing service and a method for the same
CN113312059B (zh) * 2021-06-15 2023-08-04 北京百度网讯科技有限公司 一种服务处理系统、方法及云原生系统
CN113312059A (zh) * 2021-06-15 2021-08-27 北京百度网讯科技有限公司 一种服务处理系统、方法及云原生系统
CN113595801A (zh) * 2021-08-09 2021-11-02 湘潭大学 一种基于任务流量和时效性的边缘云网络服务器部署方法
CN113923032A (zh) * 2021-10-12 2022-01-11 成都安恒信息技术有限公司 一种应用访问控制的接入方法
CN113923032B (zh) * 2021-10-12 2024-04-09 成都安恒信息技术有限公司 一种应用访问控制的接入方法
CN114528448A (zh) * 2022-02-25 2022-05-24 南京苏维博欣信息技术有限公司 一种全球外贸客户客户画像精准分析系统

Similar Documents

Publication Publication Date Title
WO2020013677A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2020204269A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2020204505A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
AU2019312061B2 (en) Electronic device for displaying indicator regarding network and method thereof
WO2020204474A1 (ko) 무선 통신 시스템에서 에지 컴퓨팅 서비스를 제공하기 위한 장치 및 방법
WO2021049710A1 (en) Method and apparatus for edge computing service
WO2019050325A1 (en) METHOD AND APPARATUS FOR SUPPORTING PROFILE TRANSFER BETWEEN DEVICES IN A WIRELESS COMMUNICATION SYSTEM
WO2021029512A1 (ko) 어플리케이션 서버의 변경에 관련된 통신
WO2021066353A1 (en) Method and apparatus for performing authorization for unmanned aerial system service in wireless communication system
WO2018199597A1 (en) Electronic device and proximity discovery method thereof
WO2021137579A1 (ko) 에지 컴퓨팅 시스템에서 어플리케이션 컨텍스트 재배치 조정 방법 및 장치
WO2015190895A1 (en) Method and device for selective communication service in communication system
WO2021187893A1 (ko) 무선 통신 시스템에서 저지연 위치 정보 서비스를 제공하기 위한 장치 및 방법
WO2017043869A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2020171672A1 (en) Method for interoperating between bundle download process and esim profile download process by ssp terminal
WO2021002696A1 (en) Method for transferring subscription and electronic device for supporting the same
WO2016108646A1 (ko) 블루투스 le 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2020080909A1 (en) Method and apparatus for handling remote profile management exception
WO2014189323A1 (en) Apparatus and method for performing wireless docking operation in communication system supporting universal plug and play protocol
WO2019107876A1 (en) Method and apparatus for managing event in communication system
WO2017116034A1 (ko) 전자 장치, 전자 장치의 통신 방법 및 이동 단말기의 통신 방법
WO2022045789A1 (en) Method and apparatus for recovering profile in case of device change failure
EP3155866A1 (en) Method and device for selective communication service in communication system
EP3854115A1 (en) Method and apparatus for handling remote profile management exception
EP4026394A1 (en) Electronic device supporting multiple sims and operation method thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19835024

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019835024

Country of ref document: EP

Effective date: 20200724

ENP Entry into the national phase

Ref document number: 2019300978

Country of ref document: AU

Date of ref document: 20190715

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE