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

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

Info

Publication number
WO2020204505A1
WO2020204505A1 PCT/KR2020/004257 KR2020004257W WO2020204505A1 WO 2020204505 A1 WO2020204505 A1 WO 2020204505A1 KR 2020004257 W KR2020004257 W KR 2020004257W WO 2020204505 A1 WO2020204505 A1 WO 2020204505A1
Authority
WO
WIPO (PCT)
Prior art keywords
mec
electronic device
authentication
server
information
Prior art date
Application number
PCT/KR2020/004257
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
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to JP2021558600A priority Critical patent/JP2022528867A/ja
Priority to EP20784458.0A priority patent/EP3934208A4/en
Priority to CN202080036547.0A priority patent/CN113826372A/zh
Priority to US17/599,331 priority patent/US20220201597A1/en
Publication of WO2020204505A1 publication Critical patent/WO2020204505A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H04L61/3015—Name registration, generation or assignment
    • H04L61/3025—Domain name generation or assignment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/365—Application layer names, e.g. buddy names, unstructured names chosen by a user or home appliance name
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/58—Caching of addresses or names
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/59—Network arrangements, protocols or services for addressing or naming using proxies for addressing

Definitions

  • Various embodiments of the present disclosure disclose a method for supporting an edge computing service (eg, a multi-access edge computing (MEC) service) and an electronic device thereof.
  • an edge computing service eg, a multi-access edge computing (MEC) service
  • MEC multi-access edge computing
  • the 5G communication system or the pre-5G communication system is called a communication system after a 4G network (Beyond 4G Network) or a system after an LTE system (Post LTE).
  • the 5G communication system is being considered for implementation in the ultra-high frequency (mmWave) band (for example, the 60 gigabyte (60 GHz) band).
  • mmWave ultra-high frequency
  • 60 GHz 60 gigabyte
  • FD-MIMO Full Dimensional MIMO
  • advanced small cell in 5G communication system, advanced small cell, advanced small cell, cloud radio access network (cloud RAN), ultra-dense network , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation And other technologies are being developed.
  • cloud RAN cloud radio access network
  • D2D Device to Device communication
  • wireless backhaul moving network
  • cooperative communication CoMP (Coordinated Multi-Points)
  • CoMP Coordinatd Multi-Points
  • interference cancellation And other technologies are being developed.
  • ACM advanced coding modulation
  • FQAM Hybrid FSK and QAM Modulation
  • SWSC Small Cellular Cellular System
  • FBMC Filter Bank Multi Carrier
  • NOMA non orthogonal multiple access
  • SCMA sparse code multiple access
  • a technology using a channel bonding method for high-speed data transmission in a WiFi wireless communication system which is one of various wireless communication systems, has emerged.
  • a channel bonding technique is used to increase a data rate by bonding an additional band to a base band.
  • the IEEE 802.11ac standard combines eight 20MHz channels to support a maximum bandwidth of 160MHz, and the IEEE 802.11ay standard also plans to apply a channel combining technology. In this way, when the channel combining technology is used, it is inevitable that power consumption in the electronic device increases.
  • the edge computing technology may include, for example, multi-access edge computing (MEC) or fog computing.
  • the edge computing technology may refer to a technology that provides data to an electronic device through a location geographically close to an electronic device, for example, a separate server (hereinafter, referred to as an edge server or MEC server) installed inside a base station or near a base station.
  • an edge server or MEC server installed inside a base station or near a base station.
  • an application that requires low latency is located in a geographically close location without going through a server located in an external data network (DN) (eg, Internet).
  • DN external data network
  • MEC-based service a service using edge computing technology
  • an application of a mobile communication electronic device may transmit and receive edge computing-based data on an edge server (or an application of an edge server) and an application layer.
  • MEC-based services for example, it is necessary to provide a secure environment for executing services between electronic devices (or users), networks, operators, or application providers.
  • the edge server or MEC application(s)
  • the access authority or authorization
  • Service or access
  • an application of an electronic device may communicate with an application of an edge server, and an application of the electronic device may be authenticated by the edge server, and authorization may be granted according to an authentication result.
  • an application permitted between an electronic device and an edge server may communicate with each other.
  • the electronic device and the edge server may perform a discovery (eg, MEC discovery) procedure (or a MEC service discovery procedure).
  • each of the applications may individually communicate with the edge server on an application layer in order to perform edge computing-based data transmission.
  • applications may individually perform authentication, authorization, and discovery procedures for use of MEC services in an electronic device.
  • a method and apparatus capable of providing a service by executing a MEC application for an electronic device based on a more optimal MEC host are disclosed.
  • a method and apparatus capable of providing a service by executing a MEC application for an electronic device based on a more optimal MEC host are 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
  • MEC discovery is not performed by individual applications, but by an electronic device (eg, a MEC service module), so that discovery can be performed more quickly and efficiently, and an MEC host that can receive optimal quality.
  • an electronic device eg, a MEC service module
  • a method and apparatus capable of providing a stable edge computing service by integrally managing a state of applications and an electronic device through a MEC service module installed in an electronic device are disclosed.
  • a method is an authentication method of an electronic device receiving an edge computing service from an authentication server of a mobile communication system, and the authentication and key agreement (AKA) method with the electronic device is used.
  • a method is an authentication method for an edge computing service in a mobile communication system in which an electronic device of a mobile communication system provides an edge computing service, wherein the electronic device includes an authentication server and a key of the mobile communication system.
  • Performing (403) first authentication in an agreement (Authentication and Key Agreement, AKA) method and receiving first authentication information;
  • AKA Authentication and Key Agreement
  • a method is a method for providing edge computing service information to an electronic device receiving an edge computing service from a multi-access edge computing management proxy (MMP) server of a mobile communication system, the electronic device Receiving a query message from at least one edge computing server including a fully qualified domain name (FQDN) for the MMP; And transmitting a response message in response to the query to the electronic device, wherein the response message may include a list of applications capable of providing edge computing services through the MMP.
  • MMP multi-access edge computing management proxy
  • Another method is a method for an electronic device to obtain edge computing service information in a mobile communication system providing an edge computing service through a multi-access edge computing management proxy (MMP) server, and normalizing the MMP Transmitting a query message of at least one edge computing server including a fully qualified domain name (FQDN) to the MMP; And receiving a response message in response to the query from the MMP;
  • MMP multi-access edge computing management proxy
  • the response message may include a list of applications capable of providing an edge computing service through the MMP.
  • An electronic device includes: a network interface; At least one application for multi-access edge computing services (MEC); A multi-access service edge agent (MSA) performing control according to authentication of the electronic device, authentication of the MEC, policy of the MEC, and data path setting of the MEC through the network interface; And through the network interface, the MEC management proxy server (MMP) of the mobile communication system and the path for session establishment and data transmission are set, the transmission of query information and the response signal are received, and the search of the MEC application server through the MMP ( A multi-access service enabler (MSE) that performs discovery).
  • MEC multi-access edge computing services
  • MSA multi-access service edge agent
  • a service may be provided by executing a MEC application for the electronic device based on a more optimal MEC host.
  • the service discovery operation may be performed by an electronic device (eg, a service enabler) rather than an individual application.
  • MEC discovery is not carried out by individual applications, but by an electronic device (eg, a service enabler), so that discovery can be performed more quickly and efficiently, and optimal quality can be provided.
  • MEC host can be selected.
  • a stable edge computing service may be provided by integrally managing the state of applications and the state of the electronic device through the MEC service module installed in the electronic device.
  • FIG. 1 is a block diagram of an electronic device 101 in a network environment 100 according to various embodiments.
  • 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.
  • FIG. 3 is a diagram illustrating an electronic device 101 and an external server 300 for supporting MEC-based services in a network environment according to various embodiments of the present disclosure.
  • FIG. 4 is a diagram illustrating an example of an authentication procedure according to various embodiments of the present disclosure.
  • FIG. 5 is a diagram illustrating an example of an authentication procedure according to various embodiments of the present disclosure.
  • FIG. 6 is a diagram illustrating an example of an authentication procedure according to various embodiments of the present disclosure.
  • FIG. 7 is a diagram illustrating an example of an authentication procedure according to various embodiments of the present disclosure.
  • FIG. 8 is a diagram illustrating an example of a policy update operation in the electronic device 101 according to various embodiments of the present disclosure.
  • FIG. 9 is a diagram illustrating an example of a PDU session establishment operation in the electronic device 101 according to various embodiments of the present disclosure.
  • FIG. 10 is a diagram illustrating an example of a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 11 is a diagram illustrating an example of a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 12 is a diagram illustrating an operation example of obtaining an app list in a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 13 is a diagram for describing an example in which an app list is provided according to various embodiments of the present disclosure.
  • FIG. 14 is a diagram illustrating an example of a context creation procedure in a discovery procedure according to various embodiments of the present disclosure.
  • 15 is a diagram illustrating an example of a MEC host selection procedure in a discovery procedure according to various embodiments of the present disclosure.
  • 16 is a diagram illustrating an example of separately operating a local DNS cache for MEC in the electronic device 101 according to various embodiments of the present disclosure.
  • 17 is a diagram illustrating an example of operating a local DNS cache for MEC in the MSE 330 in the electronic device 101 according to various embodiments of the present disclosure.
  • FIG. 18 is a diagram illustrating an example of a DNS resolving operation in a discovery procedure according to various embodiments of the present disclosure.
  • 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 a second network 199 It is possible to communicate with the electronic device 104 or the server 108 through (eg, a long-distance wireless communication network). According to an embodiment, the electronic device 101 may communicate with the electronic device 104 through the server 108.
  • a first network 198 eg, a short-range wireless communication network
  • a second network 199 It is possible to communicate with the electronic device 104 or the server 108 through (eg, a long-distance wireless communication network).
  • the electronic device 101 may communicate with the electronic device 104 through the server 108.
  • the electronic device 101 includes 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 ) Can be included.
  • 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
  • at least one of these 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 as one integrated circuit.
  • the sensor module 176 eg, a fingerprint sensor, an iris sensor, or an illuminance sensor
  • the display device 160 eg, a display.
  • the processor 120 for example, executes software (eg, a program 140) to implement at least one other component (eg, a hardware or software component) of the electronic device 101 connected to the processor 120. Control, and perform various data processing or operations. According to an embodiment, as at least part of data processing or operation, the processor 120 may convert commands or data received from other components (eg, the sensor module 176 or the communication module 190) into a volatile memory. ) 132, process commands or data stored in the volatile memory 132, and store result data in a non-volatile memory 134. According to an embodiment, the processor 120 is a main processor 121 (for example, a central processing unit (CPU) or an application processor (AP)), and a coprocessor that can be operated independently or together.
  • main processor 121 for example, a central processing unit (CPU) or an application processor (AP)
  • the coprocessor 123 may be set to use lower power than the main processor 121 or to be specialized for a designated function.
  • the secondary processor 123 may be implemented separately from the main processor 121 or as a part thereof.
  • the coprocessor 123 is, for example, on behalf of the main processor 121 while the main processor 121 is in an inactive (eg, sleep) state, or the main processor 121 While in an active (eg, application execution) state, together with the main processor 121, at least one of the components of the electronic device 101 (eg, display device 160, sensor module 176) ), or at least some of functions or states related to the communication module 190).
  • the coprocessor 123 eg, an image signal processor or a communication processor
  • may be implemented as part of another functionally related component eg, the camera module 180 or the communication module 190. have.
  • the memory 130 may store various data used by at least one component of the electronic device 101 (for example, the processor 120 or the sensor module 176 ).
  • the data may include, for example, software (eg, the program 140) and input data or output data for commands 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, a middleware 144, or an application 146. .
  • OS operating system
  • middleware middleware
  • application application
  • the input device 150 may receive commands or data to be used for components of the electronic device 101 (eg, the processor 120) from outside (eg, 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 an 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 can be used for general purposes such as multimedia playback or recording playback, and the receiver can be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part of it.
  • the display device 160 may visually provide information to the outside of the electronic device 101 (eg, a user).
  • 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 includes a touch circuitry set to sense a touch, or a sensor circuit set to measure the strength of a force generated by the touch (for example, a pressure sensor). It may include.
  • the audio module 170 may convert sound into an electric signal or, conversely, convert an electric signal into sound. According to an embodiment, the audio module 170 acquires sound through the input device 150, the sound output device 155, or an external electronic device directly or wirelessly connected to the electronic device 101 (for example, Sound may be output through the electronic device 102) (for example, a speaker or headphones).
  • 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 is, for example, a gesture sensor, a gyro sensor, a barometer sensor, a magnetic sensor, an acceleration sensor. ), grip sensor, proximity sensor, color sensor (e.g. RGB (red, green, blue) sensor), IR (infrared) sensor, biometric sensor, temperature A sensor (temperature sensor), a humidity sensor (humidity sensor), or an illumination sensor (illuminance sensor) may be included.
  • the interface 177 may support one or more designated protocols that may be used to connect directly or wirelessly to 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 can 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 the user can perceive through tactile or motor sensations.
  • the haptic module 179 may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.
  • the camera module 180 may capture a still image and a video.
  • 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 as, for example, at least a 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 includes a direct (eg, wired) communication channel or a wireless communication channel between the electronic device 101 and an external electronic device (eg, electronic device 102, electronic device 104, or server 108). It is possible to support establishment and communication through the established communication channel.
  • the communication module 190 operates independently of the processor 120 (eg, an application processor), and may include one or more communication processors that support direct (eg, wired) communication or wireless communication.
  • the communication module 190 is a wireless communication module 192 (eg, a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (eg : A LAN (local area network) communication module, or a power line communication module) may be included.
  • a corresponding communication module is a first network 198 (for example, a short-range communication network such as Bluetooth, Wi-Fi direct or IrDA (infrared data association)) or a second network 199 (for example, a cellular network, the Internet.
  • a computer network eg, a long-distance communication network such as a LAN or a wide area network (WAN)
  • a computer network eg, a long-distance communication network such as a LAN or a wide area network (WAN)
  • WAN wide area network
  • modules may be integrated into one component (eg, a single chip), or may be implemented as a plurality of separate components (eg, multiple chips).
  • the wireless communication module 192 uses subscriber information (eg, international mobile subscriber identity (IMSI)) stored in the subscriber identification module 196 to communicate with the first network 198 or the second network 199.
  • subscriber information eg, international mobile subscriber identity (IMSI)
  • IMSI international mobile subscriber identity
  • the antenna module 197 may transmit a signal or power to the outside (eg, an external electronic device) or receive from the outside.
  • the antenna module 197 may include one antenna including a conductor formed on a substrate (eg, a PCB) or a radiator formed of a conductive pattern.
  • the antenna module 197 may include a plurality of antennas. In this case, at least one antenna suitable for a communication method used in a communication network such as the first network 198 or the second network 199 is, for example, provided by the communication module 190 from the plurality of antennas. Can be chosen.
  • the signal or power may be transmitted or received between the communication module 190 and an external electronic device through the at least one selected antenna.
  • components other than the radiator eg, RFIC may be additionally formed as part of the antenna module 197.
  • At least some of the components are connected to each other through a communication method (e.g., a bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI))) between peripheral devices, and signal (Eg commands or data) can be exchanged with each other
  • a communication method e.g., a bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)
  • GPIO general purpose input and output
  • SPI serial peripheral interface
  • MIPI mobile industry processor interface
  • commands 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 the operations executed by the electronic device 101 may be executed by one or more 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 does not execute the function or service by itself.
  • the one or more external electronic devices 102 and 104 that have received the request execute at least a part of the requested function or service, or an additional function or service related to the request, and transmit the execution result to the electronic device 101.
  • the electronic device 101 may process the result as it is or additionally and provide it as at least a 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 phone
  • the electronic device 101 according to the embodiment of the present document is not limited to the above-described devices.
  • phrases such as “at least one of B or C” may include any one of the items listed together in the corresponding one of the phrases, or all possible combinations thereof.
  • Terms such as “first”, “second”, or “first” or “second” may be used simply to distinguish the component from other corresponding components, and the components may be referred to in other aspects (eg, importance or Order) is not limited.
  • module used in this document may include a unit implemented in hardware, software, or firmware, and, for example, logic, logic block, component ), or may be used interchangeably with the term of a circuit.
  • the module may be an integrally configured component or a minimum unit of the component or a part thereof that 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 the present document include one or more stored in a storage medium (eg, internal memory 136 or external memory 138) readable by a machine (eg, electronic device 101). It may be implemented as software (for example, the program 140) including instructions.
  • the 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 commands stored from a storage medium. This makes it possible for the device to be operated to perform at least one function according to the at least one command invoked.
  • the one or more instructions may include code generated by a compiler or code that can be executed by an interpreter.
  • the device-readable storage medium may be provided in the form of a non-transitory storage medium.
  • non-transient only means that the storage medium is a tangible device and does not contain a signal (e.g., electromagnetic waves), and this term refers to a case where data is semi-permanently stored It does not distinguish between temporary storage cases.
  • a signal e.g., electromagnetic waves
  • a method according to various embodiments disclosed in the present document may be provided by being included in a computer program product.
  • Computer program products can be traded between sellers and buyers as commodities.
  • Computer program products are distributed in the form of device-readable storage media (e.g. CD-ROM, compact disc read only memory), or via an application store (e.g. Play StoreTM) or two user devices (e.g. : It can be distributed (e.g., downloaded or uploaded) directly between smartphones).
  • an application store e.g. Play StoreTM
  • two user devices e.g. : It can be distributed (e.g., downloaded or uploaded) directly between smartphones).
  • at least a portion of the computer program product may be temporarily stored or temporarily generated in a storage medium that can be read by a device such as a server of a manufacturer, a server of an application store, or a memory of a relay server.
  • each component (eg, module or program) of the above-described components may include a singular number or a plurality of entities.
  • one or more components or operations among the above-described corresponding components 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 each component of the plurality of components in the same or similar to that performed by the corresponding component among the plurality of components prior to the integration. .
  • operations performed by a module, program, or other component are sequentially, parallel, repetitively, or heuristically executed, or one or more of the operations are executed in a different order. It may be omitted, omitted, or one or more other operations 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 includes a first communication processor 212, a second communication processor 214, a first RFIC 222, a second RFIC 224, a third RFIC 226, and 4 RFIC 228, a first radio frequency front end (RFFE) 232, a second RFFE 234, a first antenna module 242, a second antenna module 244, and the antenna 248.
  • 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 illustrated 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 part of the wireless communication module 192.
  • the fourth RFIC 228 may be omitted or included as a part of the third RFIC 226.
  • the first communication processor 212 may support establishment of a communication channel of a band to be used for wireless communication with the first network 292 and communication of a legacy network 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 (eg, about 6 GHz to about 60 GHz) among bands to be used for wireless communication with the second network 294, and communicates 5G network through the established communication channel.
  • a designated band eg, about 6 GHz to about 60 GHz
  • the second network 294 may be a 5G network defined by 3GPP.
  • the first communication processor 212 or the second communication processor 214 corresponds to another designated band (eg, about 6 GHz or less) among the bands to be used for wireless communication with the second network 294. It is possible to establish a communication channel and support 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 auxiliary processor 123, or the communication module 190. have.
  • the first RFIC 222 transmits a baseband signal generated by the first communication processor 212 from about 700 MHz to about 3 GHz used for the first network 292 (eg, a legacy network). Can be converted to a radio frequency (RF) signal.
  • RF radio frequency
  • an RF signal is obtained from the first network 292 (eg, a legacy network) through an antenna (eg, the first antenna module 242), and through an RFFE (eg, the first RFFE 232). It can be preprocessed.
  • the first RFIC 222 may convert the preprocessed RF signal into a baseband signal to be processed by the first communication processor 212.
  • the second RFIC 224 transmits the baseband signal generated by the first communication processor 212 or the second communication processor 214 to the second network 294 (e.g., 5G network). It can be converted into an RF signal (hereinafter, referred to as 5G Sub6 RF signal) of the Sub6 band (eg, about 6 GHz or less).
  • 5G Sub6 RF signal RF signal
  • a 5G Sub6 RF signal is obtained from the second network 294 (eg, 5G network) through an antenna (eg, the second antenna module 244), and RFFE (eg, the second RFFE 234) Can be pretreated through.
  • the second RFIC 224 may convert the preprocessed 5G Sub6 RF signal into a baseband signal to be processed by a corresponding one of the first communication processor 212 or the second communication processor 214.
  • the third RFIC 226 transmits the baseband signal generated by the second communication processor 214 to the RF of the 5G Above6 band (eg, about 6 GHz to about 60 GHz) to be used in the second network 294 (eg, 5G network). It can be converted into a signal (hereinafter, 5G Above6 RF signal).
  • the 5G Above6 RF signal may be obtained from the second network 294 (eg, 5G network) through an antenna (eg, antenna 248) and preprocessed through the third RFFE 236.
  • the third RFIC 226 may convert the pre-processed 5G Above6 RF signal into a baseband signal to be processed by the second communication processor 214.
  • the third RFFE 236 may be formed as part of the third RFIC 226.
  • the electronic device 101 may include a 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) of an intermediate frequency band (eg, about 9 GHz to about 11 GHz). After conversion, the 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.
  • the 5G Above6 RF signal may be received from the second network 294 (eg, 5G network) through 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 so that the second communication processor 214 can process it.
  • 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 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 plurality of corresponding 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 a partial area (eg, the lower surface) of the second substrate (eg, sub PCB) separate from the first substrate, and the antenna is disposed in another area (eg, upper surface).
  • a third antenna module 246 may be formed. By disposing the third RFIC 226 and the antenna 248 on the same substrate, it is possible to reduce the length of the transmission line therebetween.
  • the electronic device 101 may improve the quality or speed of communication with the second network 294 (for example, a 5G network).
  • the antenna 248 may be formed as an antenna array including a plurality of antenna elements that can be used for beamforming.
  • the third RFIC 226 may include, for example, a plurality of phase shifters 238 corresponding to a plurality of antenna elements as part of the third RFFE 236.
  • each of the plurality of phase converters 238 may convert the phase of the 5G Above6 RF signal to be transmitted to the outside of the electronic device 101 (eg, the base station of the 5G network) through a corresponding antenna element.
  • each of the plurality of phase converters 238 may convert the phase of the 5G Above6 RF signal received from the outside through a corresponding antenna element into the same or substantially the same phase. This enables transmission or reception through beamforming between the electronic device 101 and the outside.
  • the second network 294 can be operated independently from the first network 292 (e.g., a legacy network) (e.g., Stand-Alone (SA)), or can be connected and operated (e.g.: 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 the core network (eg, evolved packed core (EPC)) of the legacy network.
  • EPC evolved packed core
  • Protocol information (eg, LTE protocol information) for communication with a legacy network or protocol information (eg, New Radio (NR) protocol information) for communication with a 5G network is stored in the memory 230 and other components (eg, processor information) 120, the first communication processor 212, or the second communication processor 214.
  • LTE protocol information for communication with a legacy network
  • protocol information eg, New Radio (NR) protocol information
  • 5G network is stored in the memory 230 and other components (eg, processor information) 120, the first communication processor 212, or the second communication processor 214.
  • the 5G network technology described in the drawings and description refers to a standard standard (eg, TS 23.501) defined by an international telecommunication union (ITU) or 3GPP, and the MEC technology is ETSI (European telecommunication standards). institute) defined by the standard (eg, MEC 001 to MEC 016).
  • ITU international telecommunication union
  • 3GPP 3rd Generation Partnership Project
  • MEC European telecommunication standards
  • MEC 001 to MEC 016 European telecommunication standards
  • the contents will be 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 illustrating an electronic device 101 and an external server 300 for supporting MEC-based services in a network environment according to various embodiments of the present disclosure.
  • the electronic device 101 of FIG. 3 may show 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 is an application(s) for multi-access edge computing services (hereinafter referred to as MEC service) (hereinafter referred to as a client application). 310), a service agent (e.g., MSA) 320 (hereinafter, referred to as MSA 320), and a service enabler (e.g., MSE) 330 (hereinafter referred to as MSE 330).
  • MEC service multi-access edge computing services
  • MSE multi-access edge computing services
  • the electronic device 101 is a network interface 340 for establishment of a protocol data unit (PDU) session related to data transmission (for example, the wireless communication module of FIG. 1 or 2 ).
  • PDU protocol data unit
  • a network driver eg, a software driver
  • the client application 310, the MSA 320, and the MSE 330 may be installed as software on the electronic device 101 or configured to have a physical configuration.
  • the MSA 320 and the MSE 330 may be driven as part of a processor (eg, the processor 120 of FIG. 1 ).
  • the MSA 320 and the MSE 330 may be separate hardware components that operate independently from the processor 120.
  • the MSA 320 and the MSE 340 may be software (eg, the program 140 of FIG. 1 ).
  • the MSA 320 and the MSE 340 in software form are stored in the form of instructions (or instructions) in a memory (eg, the memory 130 of FIG. 1 or 2), and the processor 120 By this, the operations of the MSA 320 and the MSE 330 may be executed.
  • the client application 310 may include a 3rd party application installed on the electronic device 101 by a user.
  • the client application 310 may be an application using a MEC service such as MEC or fog computing).
  • the client application 310 may include an application that uses a differentiated service such as a charge-free (eg, free of charge) service.
  • the client application 310 for MEC may refer to an application of the electronic device 101 that accesses the MEC application running in the MEC host.
  • the MEC application may refer to an application that is installed and executed in a MEC host adjacent to a user to communicate with the client application 310.
  • the client application 310 may receive authentication through the MSA 320 (eg, a service agent) serving as a separate authentication client.
  • the client application 310 accesses the network based on a specific PDU session (eg, MEC dedicated PDU session) through the network interface 340, or the MSE 330
  • the MEC application can be accessed through an existing PDU session (eg, a default PDU session) through the DNS proxy function of (eg, service enabler).
  • the client application 310 for a bill-free service may refer to an application of the electronic device 101 to which a data bill-free policy is applied.
  • a corresponding unique identifier (UID, unique identifier) through a client application routing policy (CARP) or a UE route selection policy (URSP)
  • CARP client application routing policy
  • URSP UE route selection policy
  • URSP represents an electronic device 101 (for example, a user terminal) path selection (or setting) policy defined in the 3GPP standard, and is included in a non-access stratum (NAS) message from the AMF to the electronic device ( 101) may be received through a modem (or a communication processor (CP)).
  • CARP is an electronic device 101 path selection (or setting) policy defined in various embodiments.
  • the MSA 320 (eg, service agent) is an authentication procedure (eg, authentication) related to the AA (Authentication/Authorization) server 380 (eg, authentication server) of the external server 300 and the MEC service. And authorization (AA, Authentication/Authorization) procedure) can be processed.
  • the MSA 320 may include a role of transferring the URSP rule and/or the MEC access token received as a result of AA to the MSE 330.
  • the MSA 320 may include a role of detecting an application event (eg, launch, termination) or delivering a specific event to the application.
  • the MSA 320 of the electronic device 101 may include an AA client 325.
  • the AA client 325 may be provided by a manufacturer (or manufacturer) or an operator (eg, service provider) that produces the electronic device 101.
  • the MSA 320 may perform AA (Authentication/Authorization) based on the AA client 325 based on subscriber identification information of the electronic device 101.
  • the subscriber identification information may include, for example, a subscriber identity module (SIM), universal SIM (USIM), 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 320 communicates with the AA server 380 based on the subscriber identification information, through which the MSE 330 performs authentication and authorization to use a service (eg, MSE service).
  • the MSE service may collectively refer to a service such as MEC, FOC, MMS, or URLLC (ultra-reliable and low latency communications) serviced through the MSE 330.
  • the MSE 330 uses an MSE application programming interface (MSE API) for the authorized service type. You can enable/disable (eg, enable/disable) the MSE service, register the UID and rules (eg, ApnSettings) of the client application 310 available for each service type, and route You can request (routing) setting.
  • MSE API may include an API provided by the electronic device 101 to a higher application layer for activation/deactivation for each MSE service type and for 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 310 may access a corresponding service (eg, MEC, FOC) through an authentication and authorization procedure with the MSA 320.
  • the MSA 320 when the MSA 320 is implemented by an operator (eg, service provider), for example, when the operator directly develops an MSA (eg, operator MSA) using MSE services, the MSA 320 ) Can directly perform the authentication and authorization procedure for using the MSE service through the AA server 380.
  • an authentication and authorization procedure between the MSA 320 and the electronic device 101 may be performed.
  • the MSA 320 when the MSA 320 is mounted on the electronic device 101 in advance, it may be authenticated with a platform key through signing of the MSA app APK.
  • the electronic device 101 includes (or supports) an authentication module
  • the MSE API is used through a separate authentication procedure from the authentication module in the electronic device 101 You can also have them gain authority.
  • the MSA 320 may call the MSE API based on the received policy to create/terminate a PDU session and set a routing rule.
  • the electronic device 101 when setting a data path of an application for MEC, includes various entities of the MSE 330 (eg, MEC enabling layer (MEL) 331, URSP).
  • MEL MEC enabling layer
  • a data path (e.g., path a, path) to pass through at least one entity of a handling layer (UHL, URSP handling layer) 333, or a domain name system (DNS) handling layer (335)) B, or the path c) can be set.
  • the electronic device 101 uses a default PDU session (e.g., path a) or a separate dedicated PDU session when setting a data path of an application for MEC. You can set the data path differently based on the use of (eg, path b or path c).
  • the data path of path b or path c may be determined according to whether the MEC discovery procedure is performed through the MEL 331 of the MSE 330.
  • the MSA 320 does not go through the MEL 331 of the MSE 330, but directly requests the UHL 333 of the MSE 330 to configure a dedicated PDU session (example : You can set the service path as path c).
  • the MSA 320 requests the UHL 333 to provide a dedicated PDU session for the corresponding service. It can be provided through.
  • the MSA 320 further generates additional information for identifying a service with the UHL 333. Alternatively, it can be provided by receiving it from an external server.
  • the electronic device 101 may include an MSE 330 (eg, a service enabler) in a lower layer of the MSA 320.
  • MSE 330 eg, a service enabler
  • the MSE 330 may provide an MSE API to the MSA 320 so that the client application 310 can use the MEC service (or MSE service) through the MSA 320, and accordingly A routing table for PDU sessions used for each application may be set.
  • the MSE 330 may set a routing table for a PDU session path to be used for each application ID or for each URI, and store it in a memory (eg, the memory 130 of FIG. 1 or 2 ).
  • the MSE 330 may set at least one of an application ID and a URI as a target for setting a PDU session path.
  • the URI may include a domain name or IP address form.
  • the PDU session path setting for each application ID may be set as “AppID 1: PDU session 1, AppID 2: PDU session 1, AppID 3: PDU session 2”.
  • the PDU session path for each URI may be set, for example, “URI 1: PDU session 1, URI 2: PDU session2”.
  • the PDU session path for each URI for each application ID may be configured 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 to use a MEC application (or a mobile edge (ME) application), a service provided through the MEC application, and an information related service provided to the MEC application.
  • the MSE 330 is for MEC service, MEC service discovery, location verification, route selection, performance verification, or mobility support. support) can be supported.
  • the MSE 330 may be configured as a dedicated PDU session or a basic PDU session in order to provide a specific service while being connected to at least one MEC host (or MEC application).
  • information required for the configuration of a dedicated PDU session or a basic PDU session is, for example, in a modem (or CP, Communication Processor) of the electronic device 101, from the AMF/PCF server 390 to the NAS ( It can be received through non-access stratum) information.
  • the MSE 330 may include the MEL 331, the UHL 333, and the DHL 335.
  • the MEL 331 may perform a task necessary for using the MEC service among MSE services.
  • the MEL 331 is MEC service registration, MEC service discovery, route selection (eg, DNN handling), performance pre-measurement, Operation of location services and/or mobility handling may be handled.
  • the MEC service registration is performed based on the USIM or account (eg, log-in) information of the electronic device 101, the MMP server 370 (or the LCM proxy server).
  • the MEC solution provider server authenticates whether to subscribe to the MEC service, receives a token (for example, a cookie) corresponding to the MEC service authority level, and receives a memory (for example, in FIG. 1 or FIG. 2 ). It can be stored in the memory 130. Subsequent MEC services can use the token to perform a service request while the token is valid.
  • MEC service discovery is performed by the MEL 331 , Receives at least one of a list of apps available in the region (e.g. MEC App (name) list) or domain name (e.g., domain name for each MEC application), and performs various functions according to user settings.
  • the MEL 331 may provide notification of available MEC applications, DNS proxying, and/or activation of MEC applications according to user settings.
  • the MEL 331 may provide a notification about available MEC applications. For example, currently available MEC applications may be displayed on a notification window or an application icon (eg, an app icon).
  • the electronic device 101 may notify installation of a client application corresponding to a corresponding MEC application.
  • the MEL 331 may provide DNS proxying. For example, when a DNS query occurs for a domain name in order for a client application to access a MEC application, at least one of the application name or DNS query matches the MEC app list ( In the case of matching), the MEL 331 transmits a corresponding DNS query to a DNS server for MEC to receive an access IP address for a corresponding MEC application, and may return it to the client application 310.
  • the corresponding IP address may be stored, for example, in a DNS cache for MEC in the electronic device 101 during a valid period.
  • the MEC DNS resolving for the domain name on the MEC app list may be performed by the MEL 331 independently from the DNS query of the client application and stored in the DNS cache for MEC.
  • the MEL 331 may provide MEC application activation. For example, when a MEC client application installed in the electronic device 101 is being used or is expected to be used, a request may be made to activate a MEC application (eg, instantiation) linked thereto. According to an embodiment, when the corresponding MEC application is not installed in the MEC host in the access area of the electronic device 101, an installation request (eg, including a package URI) may be requested.
  • a MEC application eg, instantiation
  • route selection is a routing rule for the UID of the client application when a basic PDU session is not used and a dedicated PDU session for MEC service or MEC application is desired. rule
  • the MSE 330 receives dedicated DNN information for MEC services or MEC applications from a predefined profile or AA server 380, and uses a UHL API (not shown) to receive MEC. You can request the creation of a dedicated PDU session.
  • the pre-measurement of performance may include, for example, the MEL 331 performing a preliminary performance test on a plurality of candidate MEC hosts.
  • the MEL 331 may select an optimal MEC host through a 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 331 may provide information on service availability (or location accuracy) at a corresponding location of the electronic device 101.
  • the information on service availability may include information such as, for example, a service available area (location confirmed), a corresponding service not found (location not found), or a service unavailable area (location spoofed).
  • mobility handling may provide handling for service continuity in an area where handover occurs, for example.
  • the MEL 331 may process a handover from a MEC host to another MEC host or a handover from a MEC host to a remote host.
  • the MEL 331 may identify the type of control and service for discovery of the MEC application of the MEC host through communication with the MMP server.
  • the MEL 331 may identify a service by calling a predefined MSE API.
  • the MEL 331 may identify a service according to a policy received from an operator server (eg, AA server 380) or MMP server 370.
  • the MEL 331 establishes a service path (eg, path a) through the DHL 335 as a result of service identification, for example, in the case of a service using a basic PDU session, and Accordingly, MEC services may be provided by MEL 331 and DHL 335. According to an embodiment, in the case of a data path a for an application for MEC, the MEL 331 may be configured to provide a service through a basic PDU session.
  • a service path eg, path a
  • the MEL 331 may be configured to provide a service through a basic PDU session.
  • the MEL 331 is a result of the identification of the service, for example, in the case of a service using a dedicated PDU session, the route of the service via the MEL 331, UHL 333, and DHL 335 (Example: route b) may be set, and the corresponding service may be provided by MEL 331, UHL 333, and DHL 335.
  • the MEL 331 may request the UHL 333 to provide a service through a dedicated PDU session.
  • the MSA 320 further provides separate information to the MEL 331 or the MEL 331 receives (or acquires) related information from the MMP server 370 You can do it.
  • the UHL 333 may request a dedicated PDU session for each service type according to an API call, and may bind to a dedicated PDU session set for a corresponding application.
  • the DHL 335 may support a DNS pre-resolving or DNS proxy function to a 3rd party application.
  • a DNS pre-resolving or DNS proxy function to a 3rd party application.
  • the DNS proxy intercepts the DNS query and queries the DNS server with the domain name for MEC.
  • the corresponding MEC domain IP address can be returned by forwarding or by looking up from the DNS cache.
  • the 3rd party application can provide the MEC service without a separate software modification and without an operator's separate traffic filtering (or steering) operation.
  • the AA server 380 may provide authentication and authorization for use of the MSE service.
  • the MSA 320 of the electronic device 101 may be granted authority for each service type according to authentication and subscriber information through the AA server 380.
  • the MSA 320 may authenticate an MSE service-enabled client application.
  • the authentication procedure between the AA server 380 and the MSA 320 of the electronic device 101 is not through a separate PDU session, but through a communication such as LTE or Wi-Fi, the current Internet ( Internet) connected to the basic PDU session can be used.
  • the MMP server 370 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 370 may exchange a request/response message based on, for example, hypertext transfer protocol (HTTP).
  • HTTP hypertext transfer protocol
  • the LCM proxy may not be required.
  • the authentication request message of the MSA 320 is forwarded to the AA server 380 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 320 and the MMP server 370 or the entitlement server may be omitted, and information required in the AA procedure (eg, authentication and authorization procedure) is Can be received.
  • the AMF (access and mobility function)/PCF (policy control function) server 390 is, for example, when MEC is supported in the 5G NR (new radio) standard, MMP information and URPS rules ( rule) is registered, and the corresponding information can be received from AMF through NAS signaling.
  • the MSA 320 communicates with the AA server 380 to perform authentication and request desired information (eg, authentication and authorization), and the requested information is sent to the AA server ( 380).
  • the MSE 330 may communicate with the MMP server 330 to request desired information, and may receive and obtain the requested information from the MMP server 330.
  • the MSE 330 may communicate with the MMP server 370 to obtain a list of MEC apps, or perform a MEC service discovery procedure, and establish a connection with at least one specific MEC host (or MEC application). .
  • the scenario of the first data path is 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.
  • a MEC application driving and connection request to a MEC host close to the electronic device 101 may be requested, and a URI of the corresponding MEC application may be received.
  • the client application 310 requests access to the corresponding MEC application, it may perform access to the MEC application IP address obtained through DNS resolving for the corresponding URI.
  • the UHL 333 controlling the URSP rule does not intervene. May not.
  • Scenario B of the second data path (eg path b) (eg MSE on Multiple PDU Sessions with MEL)
  • the scenario of the second data path is a scenario in which a client application creates a separate MEC dedicated PDU session in addition to the existing basic PDU session (or PDN connection) for the Internet and connects it to the MEC application. Can represent.
  • the creation of a MEC-only PDU session is in accordance with the policy of a business operator (eg, mobile network operator (MNO) or MMP server 370), and the MSA 320 or the authenticated client application 310 uses the MSE API.
  • MNO mobile network operator
  • MMP server 370 mobile network operator
  • the MEC-dedicated PDU session may always open one or more PDU sessions in addition to the basic PDU session, or may be dynamically created or released at a specific time at a request of the MEL 331 as needed.
  • a predefined rule eg, CARP or URSP rule
  • an external server eg, MMP server 370, AA server 380, or AMF/PCF server 390.
  • the UHL 333 of the MSE 330 may support routing of the traffic for the client application (or UID) or the access URI to the MEC-dedicated PDU session according to the received routing rule. .
  • the scenario of the third data path may represent a scenario in which only a dedicated PDU session is created and used for a specific service without the function of the MEL 331.
  • a separate dedicated PDU session is created using the MSE API in the MSA 320 or the authenticated client application 310, and an application (eg, UID) rule using the PDU session is registered, Traffic of the application can be routed to the PDU Session.
  • an application eg, UID
  • Traffic of the application can be routed to the PDU Session.
  • various types of services that require a dedicated PDU session as well as MEC e.g., FOC, MMS, or URLLC
  • the electronic device 101 includes a network interface 420 and a processor 120, and the processor 120 uses the network interface to An external server that acquires information on applications that can be provided by the at least one external server, and includes an application corresponding to a specified condition based on the information on the applications By selecting, data transmission with the selected external server may be performed.
  • the processor 120 transmits a request message for requesting information on the applications to the at least one external server, and transmits the information on the applications from the at least one external server.
  • the included response message may be received, and information on the applications may be obtained from the response message.
  • the processor 120 may designate a condition of the information on the applications in the request message and transmit it to the at least one external server.
  • the request message may include at least one of a 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 is capable of serving from a designated external server based on a discovery policy.
  • Obtain an app list of an application obtain information related to an application to be accessed and associated with a client application of the electronic device based on the app list, from the designated external server, and transmit data based on the obtained information. It is possible to determine a host for and perform data transmission with the host.
  • the processor 120 a service agent that communicates with the external server to perform an operation related to authentication and authorization, obtains an app list by communicating with the external server, and discovers It may include a service enabler that performs an operation related to (discovery).
  • the processor 120 activates the service enabler through an API between the service agent and the service enabler, and performs a discovery procedure with the external server through the service enabler. You can do it.
  • the processor 120 includes setting the discovery policy from the service agent to the service enabler, and the discovery policy is a client application name (clientAppName) and a discovery policy (discoveryPolicy).
  • the discovery policy includes at least one of whether to use a dynamic DNN (dynamicDnn), location information (locationInfo), device type (deviceType), service type (serviceType), or context type (contextType). I can.
  • the processor 120 activates the service enabler based on reception of the discovery policy from the service agent, and satisfies a condition designated according to the discovery policy through an always-on service enabler. You can make a request to the proxy server for the list of apps that you are doing.
  • 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 to a proxy server through the service enabler, and the app list When there is an application associated with the client application, the application name of the application may be included and transmitted to the proxy server.
  • 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 retrieves an IP address obtained as a DNS response corresponding to the DNS query. It can be stored in a local DNS cache.
  • the processor 120 is configured to select the host based on additional information when a candidate IP list for a plurality of hosts is received from the external server, and the The additional information may include information about a host location, a user's current location, a user speed, or host performance.
  • the electronic device 101 includes a network interface 420 and a processor 120, and the processor 120 is capable of serving from a designated external server based on a discovery policy.
  • Acquires an app list of an application acquires information related to the application to be accessed and associated with the client application from the designated external server, based on an event related to context creation by the client application, and based on the acquired information , Selecting a host for data transmission, and performing data transmission with the host.
  • the event related to the context creation may include at least one of execution of the client application, a request to create a context by the client application, or a DNS query generated by the client application.
  • the discovery policy includes a client application name (clientAppName) and a discovery policy, and the discovery policy is whether a dynamic DNN (dynamicDnn) is used, location information. It may include at least one of (locationInfo), device type, service type, or context type.
  • clientAppName client application name
  • discovery policy is whether a dynamic DNN (dynamicDnn) is used, location information. It may include at least one of (locationInfo), device type, service type, or context type.
  • the processor 120 may make a request to a proxy server for a list of apps that satisfy 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 a URI of the application from the proxy server, and associates with the client application in the app list. If there is an application to be used, the application name of the application is transmitted to the proxy server, and if the application is not in the proxy server, an application package URI for downloading or installing the application is obtained from the proxy server. You can do it.
  • the processor 120 performs a DNS query with a URI for the application, and stores the IP address obtained as a DNS response corresponding to the DNS query in a local DNS cache. Can be saved.
  • authentication and authorization eg., authentication/authorization (AA)
  • policy e.g., app routing policy, discovery policy, or monitoring policy
  • configuration of a route based on the received policy e.g., app routing policy, discovery policy, or monitoring policy
  • Operations performed by the electronic device 101 described below are at least one processor of the electronic device 101 (eg, at least one processor including a processing circuit, for example, the processor 120 of FIG. 1 ). )). According to an embodiment, operations performed by the electronic device 101 are stored in a memory (for example, the memory 130 of FIG. 1 ), and when executed, instructions for causing the processor 120 to operate. Can be implemented by
  • the electronic device 101 may perform wireless communication through an access node (not shown in the drawing) disposed between the MEC Management Proxy (MMP) server 430 and the electronic device 101.
  • MMP MEC Management Proxy
  • a service agent 320 eg, MSA, multi-access service agent
  • a service enabler in the electronic device 101 for edge computing services eg, MEC service
  • Network entities interworking with a MEC service module not shown in the drawing
  • 330 eg, MSE, multi-access service enabler
  • a control path (eg, MEC) interworking between the service agent (eg, MSA) 320 and the service enabler (eg, MSE) 330 and the MMP server 370 Control plane), authentication, authorization, and discovery procedures may be performed.
  • applications eg, a first App, a second App
  • MEC data service may be provided through a data path (eg, MEC user plane) between ME App-not shown in the drawing.
  • 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 MMP server 370 provides a user application interface (see: ETSI MEC 016) to an edge computing system (eg, MEC system) on a user equipment (UE) (eg, electronic device 101). Standard reference) can be provided.
  • the electronic device 101 may request information (eg, a list of available applications) on the application(s) that the MEC system can provide from the MMP server 370, and request the MEC system to execute a specific application (eg : context creation) and termination requests (eg context termination) can be delivered.
  • the MMP server 370 may manage life cycles of applications installed in the MEC system.
  • the MMP server 370 may receive a request from the electronic device 101 and transmit the received request to the MEC system to manage life cycles of applications installed in the MEC system.
  • the MEC service module may include a service agent (eg, MSA) 320 and a service enabler (eg, MSE) 330.
  • the MEC service module provides authentication and authorization (eg, AA (authentication/authorization)) and policies (eg, application routing policy, discovery policy) according to various embodiments.
  • AA authentication/authorization
  • policies eg, application routing policy, discovery policy
  • discovery policy or monitoring policy
  • the MEC service module receives authentication/authorization (AA) and a policy (eg, a list of information to be monitored) using a service agent (eg, MSA) 320, and a service enabler (eg: MSE) 330 may be used to set a route based on the received policy and perform a MEC discovery procedure.
  • AA authentication/authorization
  • MSA mobile phone address
  • MSE service enabler
  • At least one of an entity (eg, a service agent (MSA) 320 or a service enabler (MSE) 330) in the MEC service module is a MEC discovery condition. It may be operated to perform monitoring for, and may operate to transmit the result monitored by the corresponding entity to the service enabler (MSE) 330.
  • the MEC service module may obtain (or receive) an AA and a discovery-related policy through the service agent (MSA) 320.
  • the service agent 320 when the service agent 320 performs monitoring, the service agent 320 monitors the MEC discovery condition, and when the condition is satisfied, the service enabler (MSE) 330 The discovery request may be transmitted, and the MEC discovery procedure may be performed through the service enabler 330.
  • the service enabler 330 when the service enabler 330 performs monitoring, the service agent 320 transmits the policy to the service enabler 330, and the service enabler 330 transmits the policy.
  • the MEC discovery procedure can be performed when the condition is satisfied.
  • the service agent 320 may monitor context information of the electronic device 101.
  • the context information includes, for example, information on an application supporting MEC-based data transmission among applications installed in the electronic device 101, information related to mobility of the electronic device 101, life cycle information of the application, and the electronic device. It may mean at least one of information about the state of 101, information acquired by a sensor, or network performance.
  • Information related to the mobility of the electronic device 101 is, for example, information indicating the movement of the electronic device 101, information related to a change in a base station connected to the electronic device 101, or an area in which the electronic device 101 is designated. It may include at least one of information related to entering into.
  • the designated area is, for example, a local area data network (LADN), a tracking area (TA), a cell of a base station, an area in which handover between base stations occurs, or a location-based service (eg, cellular, It may mean at least one of a region determined by satellite or a location measurement technology based on Wi-Fi (wireless fidelity).
  • the life cycle information of the application may indicate, for example, a state (eg, life cycle) of an application having a series of cycles.
  • Information on the state of the electronic device 101 is, for example, an on/off state of a display (eg, the display device 160 of FIG. 1 ), and a battery (eg, the battery 189 of FIG. 1 ).
  • the information acquired by the sensor may mean, for example, information acquired by the sensor module 176 illustrated in FIG. 1.
  • Network performance may mean, for example, at least one of a frequency bandwidth or a latency of a network to which the electronic device 101 is connected.
  • the service enabler 330 may manage (or process) MEC-based data transmission of applications based on monitored context information.
  • the service enabler 330 detects an event related to the mobility of the electronic device 101
  • the load on the electronic device 101 may be reduced by requesting or receiving information related to applications (eg, MEC applications) that the MEC system can provide to the server 370.
  • applications eg, MEC applications
  • the service enabler 330 determines whether at least one application among MEC applications or applications included in the electronic device 101 satisfies a specified condition for performing MEC-based data transmission. And, at least one application that satisfies the specified condition may notify the corresponding application to perform MEC-based data transmission (notify). If at least one application that satisfies the specified condition is not installed on the electronic device 101, the service enabler 330 installs the application by the application layer 446 and/or a framework (eg, middleware). 144 and/or operating system 142). For example, in response to a request from the application layer 310, a new application may be installed on the electronic device 101. In various embodiments, the electronic device 101 may receive (or obtain) information on a new application (eg, URI or IP address, application name) from the MEC system.
  • a new application eg, URI or IP address, application name
  • the service enabler 330 when a specified condition related to life cycle synchronization (hereinafter, referred to as a second condition) is detected, the service enabler 330 performs life cycle synchronization to the MMP server 370 (for example, an LCM proxy server) or an edge server. By requesting (or MEC server), resource consumption of the edge server can be reduced. For example, the service enabler 330 may notify the MMP server 370 whether applications are used.
  • MEC applications perform an operation (e.g., data transmission) only when applications are in use, and applications are not in use (e.g., screen off, client application background state change, user movement speed is more than a certain level) When at least one of them is satisfied), MEC applications may stop operating (eg, data transmission).
  • the service enabler 330 notifies the MMP server 370 of whether applications are used as described above, so that resources of the MEC host (or edge server) can be efficiently managed.
  • resource consumption of the MEC host may be reduced by releasing resource allocation of the MEC application for an application that is not in use.
  • the service enabler 330 performs an authentication procedure for the electronic device 101 as the MMP server 370.
  • Network load can be reduced by performing integration with (or edge server).
  • FIG. 4 is a diagram illustrating an example of an authentication procedure according to various embodiments of the present disclosure.
  • the electronic device 101 includes an MSA (or service agent) 320 (eg, including an AA client 325) and an MSE (or service enabler) 330 (eg, MEL ( 331), including UHL 333).
  • MSA or service agent
  • MSE or service enabler
  • the MSA 320 of the electronic device 101 performs an authentication (eg, first authentication) request based on at least one designated authentication method (eg, first authentication).
  • a message for (eg, a first request message) may be transmitted to the AA server 380.
  • the MSA 320 may request authentication using the AA server 380 and the GPSI (generic public subscription identifier) based Application-layer AKA method, ID/password based Login method, or GBA method.
  • the MSA 320 may perform authentication with the AA server 380.
  • the MSA 320 may perform GPSI-based user authentication with the AA server 380.
  • the AA server 380 when receiving an authentication request from the electronic device 101, the AA server 380 performs authentication with the electronic device 101, and when the authentication is completed (for example, the authentication procedure is completed), the authentication result
  • the corresponding authentication information (eg, first authentication information) may be provided (or transmitted) to the electronic device 101 (eg, the MSA 320).
  • 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 server 370 is additionally (or optionally) required information in addition to the above information, for example, at least one of ID_token for authentication or CARP or URSP rules for MEC data service. May be provided by further including in authentication information.
  • MMP Info may include, for example, information related to access to the MMP server 370 (eg, an MMP access address).
  • MMP Info may include address information (eg, a uniform resource identifier (URI) or IP address) of the new MMP server 370 to be accessed, and information related to the valid time and/or location of the corresponding address information.
  • the Auth Code may include a code (eg, based on OAuth2.0) necessary to request an access token (eg, MAT, MEC access token) from the MMP server 370. have.
  • the CARP or URSP rule is, for example, related information (eg, DNN) for PDU session setup, information related to an available application (or application group) for each DNN, or later It may include information related to a configurable DNN list or the maximum number of configurable DNNs.
  • related information eg, DNN
  • information related to an available application (or application group) for each DNN or later It may include information related to a configurable DNN list or the maximum number of configurable DNNs.
  • the MSA 320 may perform a policy update with the MSE 330 (eg, PDU session setup).
  • the MSA 320 may perform PDU session establishment according to a CARP rule or a URSP rule (eg, DNN).
  • the MSA 320 may identify a policy on whether to perform PDU session establishment according to the CARP rule or URSP rule, and make a PDU session establishment request through the MSE API according to the CARP rule or URSP rule. Can be delivered to.
  • the MSE 330 may perform PDU session establishment in response to a PDU session establishment request from the MSA 320.
  • the MSA 320 may change a basic PDU session or additionally establish a new dedicated PDU session.
  • the policy update operation of the MSA 320 and the MSE 330 in operation 407 is, for example, when the MSA 320 is provided with a CARP or URSP rule from the AA server 380 Can be done.
  • the MSA 320 may not perform a policy update with the MSE 330 when CARP or URSP rules are not provided from the AA server 380.
  • the MSA 320 may not perform the policy update through the MSA 320's own determination or information exchange with the MSE 330. have.
  • the MSA 320 completes authentication (or after performing or omitting the policy update with the MSE 330), a message for an authorization (eg, second authentication) request (eg. : A second request message) may be transmitted to the MMP server 370.
  • the MSA 320 may request authentication from the MMP server 370 based on authentication information (eg, including an Auth Code or additional ID_token) obtained from the AA server 380.
  • the MSA 320 may perform authentication (eg, an authorization procedure) with the AA server 380 through the MMP server 370. According to an embodiment, the MSA 320 may perform service authorization based on the AA server 380 and the Auth Code.
  • authentication eg, an authorization procedure
  • the MSA 320 may perform service authorization based on the AA server 380 and the Auth Code.
  • the MMP server 370 in response to an authentication request (eg, a second request message) from the MSA 320, sends authentication information (eg, second authentication information) according to the authentication result to the electronic device 101 ( Example: It can be provided (or transmitted) to the MSA (320).
  • the authentication information may include, for example, an access token (eg, MAT, MEC access Token) and MMP Info.
  • the MMP server 370 may transmit a response including an access token to the MSA 320 during or after authentication by the MSA 320.
  • MSA 320 may activate MSE 330.
  • the MSA 320 receives authentication information (eg, access token (MAT)) according to the authentication result from the MMP server 370 during or after performing authentication with the AA server 380 , It is possible to activate the MSE 330 by passing the received authentication information (eg, access token (MAT)) to the MSE 330.
  • the MSA 320 is an access address (eg, URI or IP address) of a new MMP server 370 to access to perform the MEC discovery procedure together with authentication information (eg, access token (MAT)).
  • DNS server address, or at least one additional information such as a DNN to be used may be delivered to the MSE 330.
  • the MSA 320 may activate the MSE 330 based on the received access token (MAT) and/or other additional information (enable MEC).
  • the MSA 320 when the MSA 320 performs authentication (eg, authorization) with the MMP server 370, the MSA 320 receives an access token (eg, MAT) from the MMP server 370 as an authentication result. ), and, for example, by calling enableMecEnablingLayer(true, MMP Info, MAT) of the MSE API, MMP access information (MMP Info) and access token (MAT) can be delivered to the MSE 330.
  • the MSE 330 receives authentication information (eg, MAT) and/or other additional information (eg, MMP Info, DNS server address, or DNN to be used), and the authentication information and/or additional information At least based on the MEC discovery procedure can be performed.
  • the MSE 330 may perform a MEC discovery procedure after accessing the corresponding MMP server 370 using MMP Info and MAT.
  • the MSE 330 may perform authentication (eg, service authorization of operation 411) with the MMP server 370.
  • authentication eg, authorization
  • the MSA 320 which has completed authentication first, is sent from the MMP server 370, and the MMP Info and Auth Code and/or other additional information (e.g., identification token (ID_token)) can be received, for example, for MSE 330 activation, enableMecEnablingLayer (true, MMP Info, Auth Code, [ID-Token]) can be transferred to the MSE 330 by calling.
  • ID_token identification token
  • the MSE 330 may directly perform authorization with the MMP server 370 from the information received from the MSA 320 and receive (or acquire) a MAT as a result.
  • the subject performing the service authentication procedure for authorization may be classified into a case of the MSA 320 and the case of the MSE 330. have.
  • FIG. 5 is a diagram illustrating an example of an authentication procedure according to various embodiments of the present disclosure.
  • FIG. 5 may show 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. 5 shows an example of the MEC service authentication flow for scenario A among the authentication procedures according to various embodiments, and an operation (eg, operation 510) according to an embodiment of User Authentication (or Subscriber Authentication) and An operation according to an embodiment of MEC Service Authorization (eg, operation 520) may be included.
  • scenario A for MEC AA and policy update is an example of a scenario in which MEC Service Authorization (eg, operation 520) is performed after User Authentication (eg, operation 510), as shown in FIG. 5. Can be indicated.
  • the MSA 320 of the electronic device 101 may transmit a message for an authentication request to the entitlement server 500.
  • the entitlement server 500 may determine an authentication method.
  • the entitlement server 500 may determine an authentication method corresponding to the authentication request of the electronic device 101 from at least one designated authentication method.
  • at least one authentication method may include, for example, an application-layer AKA using GPSI or a login (eg, ID/password) type authentication.
  • the MSA 320 may request an authorization code while transmitting subscriber identification information (or terminal identification information) (eg, GPSI or IMSI) to the entitlement server 500.
  • the MSA 320 and the entitlement server 500 may perform user authentication using an application-layer AKA or a logging method, as in operation 510.
  • the MSA 320 performs an authentication (eg, MEC subscriber authentication) procedure between the AA servers 380 through the entitlement server 500 based on the Application-layer AKA method. Then, an authentication response including authentication information according to an authentication result may be obtained from the AA server 380.
  • the MSA 320 performs an authentication procedure based on the entitlement server 500 and the ID/password-based login method, and in operation 509, the entitlement server ( In 500), an authentication response including authentication information according to an authentication result may be obtained from the entitlement server 500 based on a login success.
  • the MSA 320 may receive an authentication response corresponding to the authentication request.
  • the MSA 320 receives authentication information (eg, MMP Info, Auth Code) from the AA server 380 through the entitlement server 500 or the entitlement server 500.
  • ID_token, CARP rule, or URSP rule can be obtained.
  • the MSA 320 may receive MMP-related information (e.g., MMP access address) to perform the MEC discovery procedure as a result of authentication, an authorization code (e.g., Auth code) and ID_token for authorization. have.
  • the MSA 320 may receive information related to a CARP or URSP rule for a MEC data service based on whether the AA server 380 supports it.
  • the MSA 320 may perform MEC Service Authorization as in operation 520 after user authentication as in operation 510.
  • the MSA 320 may transmit a message for an authorization request to the MMP server 370 after authentication is completed.
  • the MSA 320 may transmit the acquired authentication information (eg, including an Auth Code or additionally ID_token) to the MMP server 370 to request authorization from the MMP server 370.
  • the MSA 320 may access the MMP server 370 using the MMP access address to perform an authorization procedure.
  • the MMP server 370 may request an access token from the entitlement server 500, and in operation 517, obtain an access token from the entitlement server 500.
  • the MMP server 370 communicates with the entitlement server 500 or with the AA server 380 through the entitlement server 500 to determine whether the electronic device 101 is a MEC service subscriber. You can check whether or not.
  • the MMP server 370 confirms that it is a MEC service subscriber through the AA server 380, it issues an access token (eg, MAT) to the MSA 320 (eg, authorizes). I can.
  • an access token eg, MAT
  • the MMP server 370 transmits the MMP information and the authorization code to the entitlement server 500 (or AA server 380), and requests an access token for accessing user profile information. Can be obtained.
  • the MMP server 370 may transmit an authorization response corresponding to the authorization request to the MSA 320.
  • the MMP server 370 checks the user profile using the corresponding access token, and when it is confirmed that the MEC service is available based on the user profile, the MMP Info, MAT, or CARP Authorization response can be delivered including rules.
  • the MSA 320 may obtain an access token (eg, MAT) as a result of the authorization procedure.
  • an access token eg, MAT
  • the MSA 320 receives an access token as a result of the authorization procedure, and the MSE 330 through the MSE API MMP information and access token can be delivered to
  • the MSA 320 which has completed authentication first, receives MMP information and authorization code from the entitlement server 500 (Auth code) and optionally ID_token may be delivered to the MSE 330 through the MSE API.
  • the MSE 330 may perform a direct authorization procedure with the MMP server 370 based on the information transmitted from the MSA 320 and receive an access token as a result.
  • the MSA 320 may perform the MEC discovery procedure using the MMP Info and the access token through the MSE 330.
  • FIG. 6 is a diagram illustrating an example of an authentication procedure according to various embodiments of the present disclosure.
  • the electronic device 101 includes an MSA (or service agent) 320 (eg, including an AA client 325) and an MSE (or service enabler) 330 (eg, MEL ( 331), including UHL 333).
  • MSA or service agent
  • MSE or service enabler
  • the MSA 320 of the electronic device 101 receives a message (eg, an authorization request message) for an authorization request for service use based on at least one designated authentication method. ) May be transmitted to the MMP server 370.
  • the MSA 320 requests MMP server 370 to grant permission for service use, MNO (mobile network operator) (eg, entitlement server 500) information and Device ID (eg : At least one or all of IMSI, IMEI, GPSI, or a separately allocated unique identifier) may be provided (or transmitted) to the MMP server 370.
  • the Device ID may include an identifier that allows the MMP server 370 to uniquely identify the electronic device 101.
  • the MSA 320 may perform an authentication and authorization (eg, AA, authentication & authorization) procedure with the AA server 380 through the MMP server 370 or the MMP server 370.
  • an authentication and authorization eg, AA, authentication & authorization
  • the MSA 320 transmits an authorization request to the MMP server 370
  • the MSA 320, the MMP server 370, and the AA server 380 exchange messages between three parties. Can be done.
  • the MSA 320 may perform user authentication and service authorization (or authorization) with the MMP server 370.
  • the MSA 320 may perform a procedure of identifying whether the electronic device 101 is a registered user, and may perform a procedure of identifying whether a corresponding service can be provided.
  • the MMP server 370 may perform AA according to the MNO information by using an appropriate method according to the MNO information because the AA method may be different.
  • the MMP server 370 when receiving an authentication request from the electronic device 101, performs authentication with the electronic device 101, and when authentication is completed (for example, an authentication procedure is completed), the authentication result
  • the corresponding authentication information may be provided (or transmitted) to the electronic device 101 (eg, the MSA 320).
  • the authentication information may include, for example, MMP Info and an access token (eg, MAT).
  • the MMP server 370 adds additionally (or optionally) required information, for example, at least one of CARP or URSP rules for MEC data service to the authentication information. It can be provided including.
  • the MSA 320 may receive all of the authentication information (eg, MMP Info, MAT, and CARP or URSP rules) according to the authentication result from the MMP server 370.
  • the MSA 320 receives a part of the authentication information (eg, MMP Info, MAT for discovery) from the MMP server 370, and the CARP rule (or URSP rule) is user authentication. It may be received from the AA server 380 as a result of (user authentication).
  • MMP Info may include, for example, information related to access to the MMP server 370 (eg, an MMP access address).
  • MMP Info may include address information (eg, a uniform resource identifier (URI) or IP address) of the new MMP server 370 to be accessed, and information related to the valid time and/or location of the corresponding address information.
  • the access token eg, MAT
  • the CARP or URSP rule is, for example, information related to DNN configuration, information related to an application (or application group) available for each DNN, or a DNN list that can be set later or a settable It may include information related to the maximum number of DNNs.
  • the MSA 320 may perform a policy update with the MSE 330 (eg, PDU session setup).
  • the MSA 320 may perform initial PDU session setup according to CARP or URSP rules (eg, DNN). For example, when there is a URSP rule in the received information from the MMP server 370, the MSA 320 may update the URSP rule using the MSE API.
  • the policy update operation of the MSA 320 and the MSE 330 in operation 607 may be performed when, for example, the MSA 320 is provided with a CARP or URSP rule from the AA server 380. have.
  • the MSA 320 may not perform a policy update with the MSE 330 when CARP or URSP rules are not provided from the AA server 380.
  • the MSA 320 may not perform the policy update through the MSA 320's own determination or information exchange with the MSE 330. have.
  • MSA 320 may activate MSE 330.
  • the MSA 320 receives authentication information (eg, access token (MAT)) according to the authentication result from the MMP server 370 during or after performing authentication with the AA server 380 , By passing the received authentication information (eg, access token (MAT)) to the MSE (330) it is possible to activate the MES (330).
  • the MSA 320 is an access address (eg, URI or IP address) of a new MMP server 370 to access to perform the MEC discovery procedure together with authentication information (eg, access token (MAT)).
  • DNS server address, or at least one additional information such as a DNN to be used may be delivered to the MSE 330.
  • the MSA 320 may activate the MSE 330 based on the received access token (MAT) and/or other additional information (enable MEC).
  • the MSA 320 may receive an access token (eg, MAT) from the MMP server 370 as an authentication result.
  • MMP access information MMP Info
  • MAT access token
  • the MSE 330 receives authentication information (eg, MAT) and/or other additional information (eg, MMP Info, DNS server address, or DNN to be used), and the authentication information and/or additional information At least based on the MEC discovery procedure can be performed.
  • the MSE 330 may perform a MEC discovery procedure after accessing the corresponding MMP server 370 using MMP Info and MAT.
  • FIG. 7 is a diagram illustrating an example of an authentication procedure according to various embodiments of the present disclosure.
  • the electronic device 101 includes an MSA (or service agent) 320 (eg, including an AA client 325) and an MSE (or service enabler) 330 (eg, MEL ( 331), including UHL 333).
  • MSA or service agent
  • MSE or service enabler
  • MEL MEL
  • information required for MMP access may be managed by adding URSP in the PCF of the AMF/PCF server 390.
  • the MSE 330 of the electronic device 101 may perform a NAS signaling procedure with the AMF/PCF server 390 (eg, AMF).
  • the AMF/PCF server 390 may provide MMP Info and Auth Code to the electronic device 101, and additionally provide an ID_token and/or CARP or URSP rule.
  • the MSE 330 may receive a NAS signaling message received from the AMF 390 by the modem (or communication processor) of the electronic device 101 through the UHL 333 of the MSE 330. .
  • the modem of the electronic device 101 acquires at least one of MMP Info and Auth Code, ID_token, or CARP or URSP rule from a NAS signaling message received from AMF, and transmits the obtained information to the UHL 333 It can be delivered to the MSA (320) through.
  • MMP Info may include, for example, information related to access to the MMP server 370 (eg, an MMP access address).
  • MMP Info may include address information (eg, a uniform resource identifier (URI) or IP address) of the new MMP server 370 to be accessed, and information related to the valid time and/or location of the corresponding address information.
  • URI uniform resource identifier
  • the CARP or URSP rule is, for example, information related to DNN configuration, information related to an application (or application group) available for each DNN, or a DNN list that can be set later or a settable 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 390 may be obtained from the MSA 320 through the MSE 330.
  • the MSA 320 may perform a policy update with the MSE 330 (eg, PDU session establishment).
  • the MSA 320 may perform PDU session establishment according to CARP or URSP rules (eg, DNN). For example, when there is a URSP rule in the received information from the MMP server 370, the MSA 320 may update the URSP rule using the MSE API.
  • the MSA 320 may perform a policy update with the MSE 330 when a CARP or URSP rule is included in information acquired through a NAS signaling message.
  • the MSA 320 may not perform policy update with the MSE 330 when a CARP or URSP rule is not provided among information acquired through a NAS signaling message. According to another embodiment, even if the CARP or URSP rule is provided, the MSA 320 may not perform the policy update through the MSA 320's own determination or information exchange with the MSE 330. According to an embodiment, PDU session establishment may be performed when a policy is updated between the MSA 320 and the MSE 330.
  • the MSA 320 receives an authorization request (e.g., request for service use permission).
  • a message for (e.g, a permission request message) may be transmitted to the MMP server 370.
  • the MSA 320 may request authorization for service use from the MMP server 370 based on authentication information (eg, Auth Code or additionally including ID_token) obtained from the NAS signaling message.
  • the MSA 320 may perform authentication (eg, an authorization procedure) with the AA server 380 through the MMP server 370.
  • the MSA 320 provides (or transmits) at least one or both of the AA server 380 and the Auth Code or ID_token to the MMP server 370, and grants authorization for service use (service Authorization). Can be requested.
  • the MMP server 370 provides (or transmits) authentication information to the electronic device 101 (eg, MSA 320) in response to the MSA 320's authorization request (eg, a permission request message). )can do.
  • the authentication information may include, for example, an access token (eg, MAT) and MMP Info.
  • the MMP server 370 may transmit a response including an access token and MMP Info to the MSA 320 during or after authentication by the MSA 320.
  • MSA 320 may activate MSE 330.
  • the MSA 320 receives authentication information (eg, access token (MAT), MMP Info) from the MMP server 370, received authentication information (eg, access token (MAT), MMP Info) may be transmitted to the MSE 330 to activate the MSE 330.
  • the MSA 320 together with an access token (MAT), the access address (eg, URI or IP address) of the new MMP server 370 to access to perform the MEC discovery procedure, the DNS server address, or At least one additional information such as a DNN to be used may be delivered to the MSE 330.
  • authentication information eg, access token (MAT), MMP Info
  • received authentication information eg, access token (MAT), MMP Info
  • the MSA 320 together with an access token (MAT), the access address (eg, URI or IP address) of the new MMP server 370 to access to perform the MEC discovery procedure, the DNS server address, or At least one additional information such as a DNN to be used may be delivered
  • the MSA 320 may activate the MSE 330 based on the received access token (MAT) and/or other additional information (enable MEC).
  • the MSA 320 may receive an access token (eg, MAT) from the MMP server 370, For example, by calling enableMecEnablingLayer(true, MMP Info, MAT) of the MSE API, MMP access information (MMP Info) and access token (MAT) can be delivered to the MSE 330.
  • the MSE 330 receives authentication information (eg, MAT) and/or other additional information (eg, MMP Info, DNS server address, or a DNN to be used), and the authentication information and/or additional information At least based on the MEC discovery procedure can be performed.
  • the MSE 330 may perform a MEC discovery procedure after accessing the corresponding MMP server 370 using MMP Info and MAT.
  • FIG. 8 is a diagram illustrating an example of a policy update operation in the electronic device 101 according to various embodiments of the present disclosure.
  • FIG. 8 may show an example of PDU session establishment during policy update (eg, PDU session establishment), and PDU session establishment (or PDN connection establishment) In may show an example of an operation for dedicated DNN activation.
  • the PDU session setup is a new PDU session establishment, an existing PDU session release, and an existing PDU session update (e.g., PDU session-specific properties). Settings (eg, QoS information such as bandwidth or latency) may be changed), and FIG. 8 may show an example of PDU session creation.
  • the electronic device 101 may include an MSA (or service agent) 320, an MSE (or service enabler) 330, and a modem (or CP, Communication Processor) 800. have.
  • the MSA 320 provides a first message (eg, setUrspDNN) instructing to set the DNN to the MSE 330 when acquiring (or receiving) information on the DNN configuration ( Or deliver).
  • a first message eg, setUrspDNN
  • the MSE 330 may update DNN information (eg, update DNN Info) based on a first message (eg, setUrspDNN) provided from the MSA 320.
  • DNN information eg, update DNN Info
  • a first message eg, setUrspDNN
  • the MSA 320 may provide a second message (eg, requestPduSession) instructing to create a PDU session (or PDN connection) to the MSE 330.
  • a second message eg, requestPduSession
  • the MSE 330 when receiving a second message (eg, requestPduSession), the MSE 330 provides a third message (eg, setup data call) to the modem 800 instructing to set up a data call. can do.
  • a second message eg, requestPduSession
  • the MSE 330 provides a third message (eg, setup data call) to the modem 800 instructing to set up a data call. can do.
  • the modem 800 when receiving a third message (eg, setup data call) from the MSE 330, the modem 800 establishes a data call based on preconfigured information for processing a service (eg, MEC service), or , Alternatively, a data call may be set based on the indicated information, and a fourth message (eg, a response message) corresponding to the third message may be provided to the MSE 320.
  • a PDU session is generated based on the modem 800 requesting the core network (eg SMF-not shown in the figure) to create a PDU session by a third message (eg, setup data call). I can.
  • a fifth message notifying that a PDU session has been established (eg: onAvaible) may be provided to the MSA 320.
  • the MSA 320 when the URSP rule is received using any one of the methods described above, or is received through another method, the sixth message indicating the setting of the URSP rule (e.g. : setUrspRules) can be provided to the MSE 330.
  • the MSA 320 sets a seventh message (eg setMaServiceEnableMode(true)) instructing to execute (true) the MEC service activation mode (eg, MSE activation) as the MSE 330. Can provide.
  • the MSE 330 creates (or adds) a routing table based on the sixth message (eg, setUrspRules) and the seventh message (eg, setMaServiceEnableMode(true)) received from the MSA 320. (add)) You can.
  • the URSP rule may include PDU session information for each application or for each URI, and the electronic device 101 (for example, the MSE 330) does not generate a PDU session according to the URSP rule, A PDU session can be created through the setUrspDNN API.
  • the electronic device 101 when creating a PDU session, uses the setUrspRules API to set a data path for a corresponding application ID (AppID) or URI as a PDU session according to a URSP rule. Routing table can be set through.
  • AppID application ID
  • URI URI
  • FIG. 9 is a diagram illustrating an example of a PDU session establishment operation in the electronic device 101 according to various embodiments of the present disclosure.
  • FIG. 9 may represent an example of a PDU session release during policy update (eg, PDU session establishment), and release a PDU session (or PDN connection) ( It can show an example of operation for release).
  • the PDU session setup is a new PDU session establishment, an existing PDU session release, and an existing PDU session update (e.g., PDU session-specific properties).
  • Settings eg, QoS information such as bandwidth or latency
  • FIG. 8 may show an example of PDU session release.
  • the electronic device 101 may include an MSA (or service agent) 320, an MSE (or service enabler) 330, and a modem (or CP, Communication Processor) 800. have.
  • the MSA 320 when the MSA 320 needs to release the setting of the DNN setting information, the MSA 320 sends a first message (eg, setUrspDNN) to the MSE 330 instructing to release the corresponding DNN. Can provide (or deliver).
  • a first message eg, setUrspDNN
  • the MSE 330 instructs to release a data call based on a first message (eg, setUrspDNN) provided from the MSA 320 (eg, a release data call). May be provided to the modem 1300.
  • a first message eg, setUrspDNN
  • the MSA 320 eg, a release data call
  • the modem 800 when receiving a third message (eg, a release data call) from the MSE 330, the modem 800 releases the configuration set for processing a corresponding service (eg, a MEC service), and the MSE 330 ) May provide a fourth message (eg, a response message) corresponding to the third message.
  • the PDU session may be released based on the modem 800 requesting the core network (eg, SMF) to release the PDU session by a third message (eg, a release data call).
  • the MSA 320 may provide a fifth message (eg, setMaServiceEnableMode(false)) instructing to execute the MEC service deactivation mode (eg, MSE deactivation) to the MSE 330.
  • a fifth message eg, setMaServiceEnableMode(false)
  • MEC service deactivation mode eg, MSE deactivation
  • the MSE 330 stores (or generates) in a memory (eg, the memory 130 of FIG. 1 or 2) based on the fifth message (eg, setMaServiceEnableMode(false)) received from the MSA 320.
  • Deleted routing tables can be deleted from memory.
  • FIG. 10 is a diagram illustrating an example of a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 10 may show an example of an application state-based MEC discovery procedure.
  • the electronic device 101 includes a client application (or Client App) 310, an MSA (or service agent) 320, an MSE (or service enabler) 330 (e.g., MEL 331 ), including the UHL 333), and a DNS cache 1010.
  • client application or Client App
  • MSA or service agent
  • MSE or service enabler
  • the MSA 320 of the electronic device 101 may set a MEC discovery policy to the MSE 330.
  • the MEC discovery policy may be provided by including client application names (eg, clientAppNames) and discovery policy (eg, discoveryPolicy).
  • the discoveryPolicy may include whether to use a dynamic DNN (eg, dynamicDnn), and a location (eg, locationInfo), a device type (eg, deviceType), a service type (eg, serviceType), or a context type ( Example: contextType) can be provided by including at least one of information.
  • the MSA 320 includes a location (eg, locationInfo), a device type (eg, deviceType), and a service type (eg, serviceType) in a discoveryPolicy, and receives an app list by limiting only the list meeting the corresponding condition. You can do it.
  • the MSA 320 may include information about whether an application context is required by including a context type (eg, contextType) in the discoveryPolicy.
  • the MSA 320 may request to include the URI Request Flag in the discoveryPolicy 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 MEC is available
  • the location is a location-based app according to the current location of the electronic device 101 This may be information for requesting a list
  • the dynamic DNN (dynamicDnn) may be information for checking whether to use a dynamic DNN update.
  • the MSE 330 performs an acquisition procedure (eg, MEC Application Look-up) for obtaining an app list (eg, AppList) based on information received from the MSA 320 (eg, MEC discovery policy). Can be done.
  • an acquisition procedure eg, MEC Application Look-up
  • an acquisition procedure for acquiring an app list according to the MEC discovery policy setting between the MSA 320 and the MSE 330 may be started.
  • the MSE 330 may activate the MEC Application Look-up when receiving the MEC discovery policy from the MSA 320 through the MSE API, and a specific condition of the electronic device 101 (eg, electronic It can be executed (or started) when the access base station Cell ID change) is satisfied while the device 101 is moving.
  • the MSE 330 may request and receive an app list (eg, MEC AppList) related to a serviceable MEC application (eg, MEP App) from the MMP server 370 according to the MEC discovery policy.
  • the MSE 330 may request the MMP server 370 by writing the MEC discovery policy in the MEC AppList request message parameter as illustrated in ⁇ Table 1>, and the MMP server 370 By providing a list of serviceable apps to the MSE 330, it is possible to respond to the request of the MSE 330.
  • the client application 310 may provide (or deliver) an App Launch Detected or API (Context Create) call to the MSA 320.
  • the case of App Launch Detected may indicate the case that the client application 310 is executed.
  • an API (Context Create) call may indicate a case of requesting a URI for a MEC application name (eg, MEC App Name) to be accessed.
  • the MSA 320 when receiving an App Launch Detected or API (Context Create) call, the MSA 320 sends a notification message (eg, notifyClientAppState) for notifying the state of the client application 310 to the MSE 330 ) Can be provided.
  • the notification message eg, notifyClientAppState
  • the notification message 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)) can be provided.
  • the MSE 330 receives a notification message (eg, notifyClientAppState) from the MSA 320, and based on the received notification message, the MEC application (or the MEC host including the corresponding MEC application (eg, edge server or MEC server)), a procedure (eg, application context creation) for discovery (or discovery, confirmation) can be performed.
  • the MSE 330 may activate application context creation when receiving an event related to execution of the client application 310 from the MSA 320.
  • the MSE 330 performs an application context creation operation to find a MEC host including a desired MEC application through the MMP server 370 based on the information of the received notification message (eg, notifyClientAppState).
  • the application context creation may be activated (or executed) by calling the MSE API.
  • application context creation may be activated (or executed) when the client application 310 calls a context create API.
  • the MSE 330 may request and receive a URI for a MEC application name (eg, MEC App Name) to be accessed from the MMP server 370.
  • the MSE 330 may request and receive information on a dedicated DNN (dedicated DNN) from the MMP server 370 as necessary.
  • the MMP server 370 may transmit a MEC application package URI to the MSE 330 when there is no corresponding MEC application.
  • the MSE 330 may perform a host selection procedure (eg, MEC Host Selection) for selecting the DNS server 1020 and the MEC host.
  • a host selection procedure eg, MEC Host Selection
  • the MSE 330 when there are at least two MEC hosts acquired through the MMP server 370, the MSE 330 performs a host selection procedure for selecting the DNS server 1020 and any one MEC host (e.g., MEC Host Selection) can be performed.
  • the host selection procedure for selecting one MEC host is determined using preset information and/or information inquired with the DNS server 1020, or the DNS server 1020 ), and/or the user to select (or set) a specific MEC host.
  • preset information for setting a specific MEC host may include priority information.
  • the host selection procedure may include a DNS pre-resolving operation and a MEC host priority determination operation.
  • DNS pre-resolving is, for example, the MSE 330 itself, regardless of the DNS query of the client application 310 (fully qualified domain name (FQDN) for MEC) DNS It may include performing resolving.
  • DNS resolving may be performed using a URI or domain name received through the Get App List step of operation 1003 or the Find Cloudlet step of operation 1009.
  • MEC Host Prioritization may include setting an IP priority when a plurality of IP addresses are received in, for example, a DNS query response.
  • a host selection procedure eg, MEC Host Selection
  • the client application 310 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 310.
  • DNS resolving may include, for example, Client-driven normal DNS resolving or DNS proxying (hooking DNS query). DNS resolving according to various embodiments will be described in detail with reference to the accompanying drawings.
  • FIG. 11 is a diagram illustrating an example of a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 11 may show an example of a DNS Query-based MEC discovery procedure.
  • the electronic device 101 includes a client application (or Client App) 310, an MSA (or service agent) 320, an MSE (or service enabler) 330 (e.g., MEL 331 ), including the UHL 333), and a DNS cache 1010.
  • client application or Client App
  • MSA or service agent
  • MSE or service enabler
  • the MSA 320 of the electronic device 101 may set a MEC discovery policy to the MSE 330.
  • the MEC discovery policy may be provided by including client application names (eg, clientAppNames) and discovery policy (eg, discoveryPolicy).
  • the discoveryPolicy may include whether to use a dynamic DNN (eg, dynamicDnn), and a location (eg, locationInfo), a device type (eg, deviceType), a service type (eg, serviceType), or a context type ( Example: contextType) can be provided by including at least one of information.
  • the MSA 320 includes a location (eg, locationInfo), a device type (eg, deviceType), and a service type (eg, serviceType) in a discoveryPolicy, and receives an app list by limiting only the list meeting the corresponding condition. You can do it.
  • the MSA 320 may include information about whether an application context is required by including a context type (eg, contextType) in the discoveryPolicy.
  • the MSA 320 may request to include the URI Request Flag in the discoveryPolicy to include the URI in the app list when the URI of the MEC application is available.
  • the MSE 330 acquires an app list (eg, AppList) based on information received from the MSA 320 (eg, MEC discovery policy), an acquisition procedure (eg, MEC Application Look-up, Get App List) can be performed.
  • an acquisition procedure eg, MEC Application Look-up, Get App List
  • an acquisition procedure for acquiring an app list according to the MEC discovery policy setting between the MSA 320 and the MSE 330 may be started.
  • the MSE 330 may activate the MEC Application Look-up when receiving the MEC discovery policy from the MSA 320 through the MSE API, and a specific condition of the electronic device 101 (eg, electronic It can be executed (or started) when the access base station Cell ID change) is satisfied while the device 101 is moving.
  • the MSE 330 may request and receive an app list (eg, MEC AppList) related to a serviceable MEC application (eg, MEP App) from the MMP server 370 according to the MEC discovery policy.
  • an app list eg, MEC AppList
  • a serviceable MEC application eg, MEP App
  • the MSE 330 may request the MMP server 370 by writing the MEC discovery policy in the MEC AppList request message parameter, and the MMP server 370 may request a serviceable app list according to the MSE 330 By providing to, it is possible to respond to the request of the MSE (330).
  • the client application 310 may transmit a message (eg, a DNS query message) for a DNS query to the MSE 330.
  • a message eg, a DNS query message
  • the MSE 330 may perform a Find Cloudlet operation with the MMP server 370 in response to a DNS query from the client application 310.
  • a DNS query (with FQDN) message occurs in the client application 310
  • the MSE 330 detects an FQDN for MEC through FQDN filtering, and the corresponding MEC application You can perform a Find Cloudlet for.
  • the MSE 330 may request and receive a URI for a MEC application name (eg, MEC App Name) to be accessed from the MMP server 370.
  • the MSE 330 may request and receive information on a dedicated DNN (dedicated DNN) from the MMP server 370 as necessary.
  • the MMP server 370 may transmit a MEC application package URI to the MSE 330 when there is no corresponding MEC application.
  • the MSE 330 may perform a host selection procedure (eg, MEC Host Selection) for selecting the DNS server 1020 and the MEC host in response to a DNS query from the client application 310.
  • a host selection procedure eg, MEC Host Selection
  • the MSE 330 performs a host selection procedure for selecting the DNS server 1020 and any one MEC host (e.g., MEC Host Selection) can be performed.
  • the host selection procedure for selecting one MEC host includes preset information and/or information received by requesting from the DNS server 1020 (e.g., IP address, location per IP).
  • preset information for setting a specific MEC host may include priority information.
  • the priority information includes, for example, information whose host priority is prioritized for each URI, or when there are a plurality of IP addresses resulting from DNS resolving of one URI. It may include information on which the priority of each corresponding IP address is determined.
  • the host selection procedure may include a DNS resolving operation and a MEC host priority determination operation.
  • DNS resolving may include, for example, performing DNS resolving for an FQDN for MEC by the MSE 330 itself regardless of a DNS query of the client application 310.
  • MEC Host Prioritization may include setting an IP priority when a plurality of IP addresses are received in, for example, a DNS query response.
  • the priority may be predetermined for each URI or for each IP.
  • IP priority is dynamically given according to the result through a performance test for each received IP. You can also decide the ranking.
  • a host selection procedure eg, MEC Host Selection
  • the MSE 330 may provide the client application 310 with information obtained through the above procedures as a DNS response. According to an embodiment, the MSE 330 may transmit a DNS response corresponding to the DNS query to the client application 310 that provided the DNS query after selecting the MEC host (eg, DNS resolving).
  • the MEC host eg, DNS resolving
  • FIG. 12 is a diagram illustrating an operation example of obtaining an app list in a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 12 may show an example of an operation of 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 320 of the electronic device 101 may transmit a MEC discovery policy to the MSE 330.
  • the MEC service module 410 may obtain a MEC discovery policy using the MSA 320 and perform a discovery procedure based on the received MEC discovery policy using the MSE 330.
  • the MEC discovery policy is 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 by including at least one of a flag (eg, URI Request) or a dynamic DNN (eg, dynamicDnn).
  • the MSE 330 performs an acquisition procedure (eg, MEC Application Look-up) for obtaining an app list (eg, AppList) based on information received from the MSA 320 (eg, MEC discovery policy). Can be done.
  • the operation of obtaining the app list may be started according to the MEC discovery policy setting between the MSA 320 and the MSE 330.
  • the app list acquisition procedure may be activated when the MSA 320 calls the MEC discovery policy API, and requests and receives the MEC app list and/or URI conforming to the MEC discovery policy to the MMP server 370 can do.
  • the procedure for obtaining an app list may include operation 1210 and operation 1220.
  • the MSE 330 may transmit a request message (eg, HTTP Get AppList Request Parameters) for requesting an app list to the MMP server 370.
  • a request message eg, HTTP Get AppList Request Parameters
  • the MSE 330 may include (or write) the MEC discovery policy in a request message (eg, HTTP Get AppList Request Parameters) and provide it to the MMP server 370.
  • the MSE 330 may provide the MMP server 370 including the app list request parameter.
  • field information that can be supported for Request Parameter may be defined in MMP Info in Authorization Response in the authentication (AA) step.
  • a parameter (or information) related to an app list request eg, AppList Request Parameters
  • a parameter field of a request message eg, HTTP GET.
  • the app list request parameter is received from the MSA 320 (e.g., setMecDiscoveryPolicy (clientAppNames, discoveryPolicy) in operation 1201) application names (e.g., clientAppNames), access cell ID, tracking area (TA, Tracking Area) Location information related to the location of the electronic device 101 including at least one of ID, area information (eg, city, district, dong, building), or user-designated preferred location information , Device Type that can identify the type of electronic device 101 (eg, Smartphone, Tablet, Wearable, IoT, Car, Drone), Service Type that can identify the type of service ( Example: Game, V2X, AR/VR, LBO, Enterprise, Web), context type that can identify the need for context information (e.g., when MEC application is driven, the context information of the user or application is It may include at least one of a flag (eg, a URI Request Flag) requesting to include the corresponding URI in a response when the URI of the MEC application is available) or
  • the context type is information for identifying a service application type of the electronic device 101, for example, an application installed in the electronic device 101 (for example, a specific launcher or a designated application), or an execution application. It may include at least one of a name and 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 370.
  • application information eg, a specific launcher or a designated application
  • the electronic device 101 when there is a change (eg, update) of application information installed in the electronic device 101, in the procedure of requesting an app list from the MMP server 370, the electronic device 101 ), you can also deliver information about applications installed in
  • the MMP server 370 sends 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 330 330).
  • a response message eg, HTTP 200 OK AppList response Data
  • an app list eg, MEC AppList
  • the MMP server 370 may search for a MEC application based on the received client application name, and provide an app list including the searched MEC application in a response message to the MSE 330.
  • 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 MMP server 370 may provide a serviceable MEC App List based on at least one of all available MEC App Lists or Request Parameters.
  • a MEC App Name that can be accessed for each Client App may be included, and the MEC App Name may be used (or required) in a later Application Context Create operation.
  • the MMP server 370 may provide a notification by including a notification in an app list when an operator's location API (API) is available.
  • API operator's location API
  • the MMP server 370 when the URI Request Flag is true, and the corresponding MEC App is running on an available MEC host near the electronic device 101 (eg, user terminal), the corresponding MEC App URI can be provided by including it in the app list.
  • the MMP server 370 includes the URI of the MEC App in the app list when the MEC App is running on the MEC host even when there is no URI Request Flag in the request message. It can also be provided.
  • the MMP server 370 when receiving an app list request from the electronic device 101, drives the MEC App and then applies the corresponding URI when the MEC App can be directly driven according to the context type in the request message. It can be provided by including in the list.
  • the MMP server 370 may further include and provide valid time/valid place information of the URI in the app list.
  • the information on the valid time of the URI may be determined by the electronic device 101 or may be variably determined by the MMP server 370 according to the MEC App driving state.
  • the MMP server 370 may provide a corresponding rule when a dedicated DNN rule for each application exists.
  • the URI included in the app list may be distinguished by being hyperlinked and/or highlighted, and the electronic device 101 is configured to display a MEC App that does not include a URI and a hyperlink and/or highlight in the app list. It can be displayed separately based on the According to another embodiment, the electronic device 101 may display the MEC App including the URI and the MEC App not including the URI identically in the app list. According to an embodiment, the electronic device 101 may provide serviceable location and/or time information for each application in the app list.
  • the MMP server 370 may include DNN information for each application (or for each app) in the app list when DNN can be configured for each application.
  • the corresponding DNN server may be a DNN included in a DNN list received at an authentication (AA) stop.
  • the electronic device 101 in the procedure of requesting an app list from the MMP server 370 and receiving a response thereto, is a MEC host for the app list and the corresponding application(s) in the app list. : It is possible to obtain (or receive) information (eg, URI) on the edge server or MEC server. According to an embodiment, when the electronic device 101 does not receive information (eg, URI) on the MEC host, for example, by performing an Application Context Create procedure for the corresponding app, MEC host information (eg, URI) can be obtained from an external server. According to an embodiment, when the electronic device 101 receives information (e.g., URI) on the MEC host, for example, for the corresponding application, without performing an Application Context Create procedure, the corresponding MEC host ( E.g. using a URI).
  • information e.g., URI
  • the electronic device 101 in the procedure of requesting an app list from the MMP server 370 and receiving a response thereto, is configured to a designated networking path for the app list and the corresponding application(s) in the app list.
  • Information eg, DNN
  • the electronic device 101 may perform a procedure of setting a network and a designated networking path.
  • the electronic device 101 may configure a DNN path to communicate with a dedicated (or dedicated) DNN (dedicated DNN) only for applications that have received DNN information.
  • the electronic device 101 may set a designated DNN path for applications that have received DNN information in a procedure for requesting the MEC host to create a context (eg, Application Context Create).
  • FIG. 13 is a diagram for describing an example in which an app list is provided according to various embodiments of the present disclosure.
  • FIG. 13 may exemplify a location-based service area.
  • the MMP server 370 provides first information on available applications from a first server (Server 1) 1310 (or a first MEC host adjacent to a user). (Example: A(+URI), B, C) can be assumed to be acquired. According to an embodiment, the MMP server 370 provides second information about an application available from the second server (Server 2) 1320 (or a second MEC host adjacent to the user) (eg, A, C (+URI)). , D) can be assumed.
  • the MMP server 370 collects information about each application (eg, first information, second information) obtained from the first server 1310 and the second server 1320 , For example, information of A (+URI), B, C (+URI), and D may be generated (or acquired). According to an embodiment, the MMP server 370 generates an app list including A (+URI), B, C (+URI), and D generated from the first server 1310 and the second server 1320 Then, the generated app list may be provided to the user 1330 (eg, the electronic device 101).
  • information about each application eg, first information, second information obtained from the first server 1310 and the second server 1320 .
  • information of A (+URI), B, C (+URI), and D may be generated (or acquired).
  • the MMP server 370 generates an app list including A (+URI), B, C (+URI), and D generated from the first server 1310 and the second server 1320 Then, the generated app list may be provided to the user 1330 (eg, the electronic device 101).
  • FIG. 14 is a diagram illustrating an example of a context creation procedure in a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 14 may show an example of an operation regarding application context creation (eg, Application Context Create) in a MEC discovery procedure according to an embodiment.
  • the application context creation procedure is, for example, when the client application 310 is executed, the MSA 320 includes application start information along with information (eg, package name or UID) related to the corresponding client application. May be performed from passing the MSE 330 to the MSE 330 through the MSE API.
  • the application context creation may be performed by executing an application on the app list (first case), or by requesting a context creation through an MSE API (eg, calling context create API), or (Case 2), or when matching with the application name and/or URI (eg, FQDN) included in the pre-received app list when the application transmits a DNS query (Case 3).
  • MSE API eg, calling context create API
  • URI eg, FQDN
  • the application context creation is, for example, location information delivered through a MEC discovery policy (e.g., setDiscoveryPolicy (discoveryPolicy)) or an available location for each application included in the app list delivered through an application lookup response ( Example: uriLOC) may be performed even when the location of the current user (or electronic device 101) matches (eg, the fourth case).
  • a MEC discovery policy e.g., setDiscoveryPolicy (discoveryPolicy)
  • Example: uriLOC application lookup response
  • the application context generation may be performed. 14 shows an example of an operation of generating an application context according to the first case.
  • operation 1401 when a specific client application 310 is launched, the corresponding client application 310 provides information (eg, App Launched) notifying the execution of the application to the MSA 320 can do.
  • operation 1401 may not be performed.
  • the MSA 320 e.g., Framework level
  • the MSA 320 can detect the execution of the client application 310 by itself without an operation notifying the execution by the client application 310. I can.
  • a notification message for notifying the state of the client application 310 may be provided to the MSE 330.
  • the 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)) can be provided.
  • the MSE 330 may receive a notification message (eg, notifyClientAppState) from the MSA 320 and perform an application context creation procedure based on information of the received notification message.
  • a notification message eg, notifyClientAppState
  • the application context creation procedure may include operation 1410, operation 1420, and operation 1430.
  • the MSE 330 may transmit a request message (eg, HTTP POST AppContext Data) for requesting application context creation to the MMP server 370.
  • a request message eg, HTTP POST AppContext Data
  • the MSE 330 may transmit a request message for requesting a URI to the MMP server 370.
  • the MSE 330 may include a MEC application name in a request message and transmit the MMP server 370 to the MMP server 370.
  • the MSE 330 when there is no MEC application in the MMP server 370, the MSE 330 includes only a URI (for example, an application package download URI) capable of downloading a corresponding MEC application in the request message. It can be transmitted to the MMP server 370.
  • a URI for example, an application package download URI
  • the MMP server 370 provides a response message (eg, HTTP OK 200 Response AppContext Data) including the URI of the MEC application to the MSE 330 in response to the request message received from the MSE 330 can do.
  • the response message may include a URI (FQDN) of a corresponding application (eg, MEC application).
  • the response message may include information on the URI of the MEC application and the valid time and/or the valid location of the corresponding URI.
  • the MSE 330 may perform application context re-execution or handover triggering when the valid time exceeds or the valid location is changed.
  • the response message may include DNN information.
  • the MSE 330 may perform a policy update.
  • the MSE 330 may additionally (or optionally) include a policy update operation in the application context creation procedure (operation 1405).
  • the MSE 330 receives a URSP rule (e.g., DNN) when a dedicated PDU session is required (or when a new dedicated DNN rule is set), and according to the URSP rule, per application or URI Each PDU session can be set.
  • a URSP rule e.g., DNN
  • the URSP rule (or CARP rule) is the result of an authentication procedure (e.g., the MSA 320 receives it and delivers it to the MSE 330), or the MSE 330 is an application lookup (e.g., 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, a PDU session setup may be performed.
  • PDU session establishment eg, creation of a PDU session in FIG. 8, release of a PDU session in FIG. 9 is performed by the MSE 330 as described in the description with reference to FIG. 8 or 9.
  • the modem 800 may create/release by requesting the SMF of the 5G network (or core network).
  • the application context creation procedure is, for example, a MEC application to which the client application 310 is connected is already running, and an app list acquisition procedure (eg, MEC Application Look-up) If the URI is received from, it can be omitted.
  • an app list acquisition procedure eg, MEC Application Look-up
  • 15 is a diagram illustrating an example of a MEC host selection procedure in a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 15 may show a MEC host selection operation 1501 for the MSE 330 to select a DNS server 1020 and a MEC host.
  • the MEC host selection operation (operation 1501) includes a DNS (pre) resolving operation (eg, operation 1510), a MEC Host Prioritization operation (eg, operation 1520), and a DNS caching operation (eg, operation 1520). 1530) may be included.
  • the MSE 330 may perform DNS resolving or pre-resolving.
  • the DNS resolving may perform DNS resolving for the FQDN for MEC by itself, regardless of the DNS query of the client application 310, for example.
  • DNS resolving (operation 1510) may include operations 1511 and 1513.
  • the MSE 330 may perform a DNS resolving operation by the DHL 335. According to an embodiment, the MSE 330 may transmit a DNS query to the DNS server 1020 as a URI (FQDN) for the MEC application.
  • a DNS query to the DNS server 1020 as a URI (FQDN) for the MEC application.
  • the DNS server 1020 may receive a DNS query from the MSE 330 and transmit a DNS response to the MSE 330 as a response corresponding 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 330 may perform a MEC host prioritization operation.
  • MEC Host Prioritization may include, for example, setting an IP priority when a plurality of IP addresses are received as a DNS query response.
  • the MSE 330 may set priorities for the MEC host.
  • the MSE 330 may obtain (or receive) a candidate IP list for a plurality of MEC hosts from the MMP server 370, and additional information of the candidate IP list (eg: MEC host location from the user's current location, user speed, or MEC host performance (e.g., at least one of RTT (round trip time), throughput), and MEC host candidate IP and remote server (e.g. The remote server 306) may select an access IP from among IP addresses or designate a priority.
  • MEC host IP or an IP of a remote server may be selected.
  • the remote server IP may be selected without selecting the MEC host IP.
  • the MSE 330 eg, MEL 331 selects the optimal MEC host through preliminary performance measurement (or test) (eg, ping probing or bandwidth estimation) for a plurality of candidate MEC hosts. I can.
  • the DNS server 1020 may record location information of the MEC host together with the IP address of the MEC host in a DNS response message.
  • the MSE 330 when the MSE 330 includes the location information of the MEC host for the location record type (eg, LOC record type) among the DNS types in the DNS response message received after a DNS query during DNS resolving , It is also possible to select an adjacent MEC host using the corresponding location information.
  • the MSE 330 is the location information of the MEC host from the DNS server 1020 (eg, latitude, longitude, serving cell ID, city information, or ID) in a DNS query operation for obtaining the IP address of the MEC host. ) Can be obtained.
  • the location information of the MEC host may be included in the DNS type field.
  • the MSE 330 may perform DNS caching with the DNS cache 1010.
  • the MSE 330 when receiving a DNS response including address information from the DNS server 1020 in response to a DNS query from the DNS server 1020, the MSE 330 includes address information included in the DNS response (for example, a URI related to the MEC host).
  • the IP address corresponding to the FQDN) can be stored in the local DNS cache for MEC (eg, DNS Cache 2).
  • the MSE 330 may deliver the address information stored in the local DNS cache for MEC.
  • a method of including a local DNS cache for MEC (eg, DNS Cache 2) in the MSE 330 of 17 may be used.
  • the electronic device 101 includes a plurality of MEC applications in which a MEC application can operate in a communication procedure with the MMP server 370 (eg, discovery/application context creation) based on the MEC host selection operation.
  • MEC host information eg, URI or IP address
  • the electronic device 101 may select and communicate with any one of a plurality of received MEC hosts.
  • the electronic device 101 may select a plurality of MEC hosts on which the MEC application can operate according to priority.
  • the priority may be determined based at least on information on measuring a latency between the electronic device 101 and the MEC host or location information of the MEC host.
  • the electronic device 101 maintains and/or maintains DNS caching data for MEC client apps, separately from DNS caching data for general client apps. Describe the management operation.
  • 16 is a diagram illustrating an example of separately operating a local DNS cache for MEC in the electronic device 101 according to various embodiments of the present disclosure.
  • FIG. 16 may show an example in which a local DNS cache for MEC is separately configured from the MSE 330 of the electronic device 101.
  • the general client applications 1610 may perform DNS caching with the first DNS cache 1620, and the MEC Client Apps 310 may perform the second DNS cache.
  • DNS caching can be performed with (1630).
  • the general client application 1610 may use the first DNS cache 1620 and the MEC client application 310 may use the second DNS cache 1630.
  • the MSE 330 e.g., DHL 335
  • the OS of the electronic device 101 or a DNS processing module on the framework
  • queries the DNS for the request from the client application e.g., FQDN).
  • the DNS server 1020 receives a DNS response (eg, an IP address corresponding to the FQDN), cache it, and deliver it to the client application.
  • the MSE 330 may determine which DNS cache to use for each URI (FQDN) for each client application, and accordingly, a separate DNS processing module (eg, FIG. 16) or DHL of the MSE ( 17) may transfer the IP address to the client application with reference to the first DNS cache 1620 or the second DNS cache 1630.
  • the DNS processing module or DHL first refers to the DNS cache for the requested URI (FQDN), and if there is an IP corresponding to the URI, it forwards it, and if it is not in the cache, it queries the DNS server 1020 for DNS. You can do it.
  • 17 is a diagram illustrating an example of operating a local DNS cache for MEC in the MSE 330 in the electronic device 101 according to various embodiments of the present disclosure.
  • FIG. 17 may show an example of configuring a local DNS cache for MEC (eg, a second DNS cache 1630) in the MSE 330 of the electronic device 101.
  • the general client application 1610 may perform DNS caching with the first DNS cache 1620, and the MEC client application 310 may perform DNS caching with the second DNS cache 1630.
  • the general client application 1610 may use the first DNS cache 1620, and the MEC client application 310 may use the second DNS cache 1630.
  • the MSE 330 e.g., DHL 335
  • the OS of the electronic device 101 or a DNS processing module on the framework
  • queries the DNS for the request from the client application e.g., FQDN).
  • the DNS server 1020 receives a DNS response (eg, an IP address corresponding to the FQDN), cache it, and deliver it to the client application.
  • the MSE 330 may determine which DNS cache to use for each URI (FQDN) for each client application, and accordingly, a separate DNS processing module (eg, FIG. 16) or DHL of the MSE ( 17) may transfer the IP address to the client application with reference to the first DNS cache 1620 or the second DNS cache 1630.
  • the DNS processing module or DHL first refers to the DNS cache for the requested URI (FQDN), and if there is an IP corresponding to the URI, it forwards it, and if it is not in the cache, it queries the DNS server 1020 for DNS. You can do it.
  • the general client application 1610 and the MEC client application 310 are classified and described in detail with reference to a drawing (eg, FIG. 36) to be described later in connection with performing DNS caching.
  • FIG. 18 is a diagram illustrating an example of a DNS resolving operation in a discovery procedure according to various embodiments of the present disclosure.
  • FIG. 18 may represent a DNS resolving operation for a DNS query of the client application 310.
  • the DNS resolving operation includes an operation when the DNS server 1020 is in an inactive state (eg, operation 1810) and an operation when the DNS server 1020 is in an activated state (eg, operation 1830). ) Can be included.
  • the DNS resolving operation of operation 1810 represents an operation example in which the local DNS cache for MEC (eg, the second DNS cache 1630) is disabled in the DNS cache 1010, for example.
  • the client application 310 may transmit a DNS query for a URI to the DNS cache 1010 (operation 1811), and the DNS cache 1010 responds to the DNS query of the client application 310 (Example: DNS Cache Response) may be delivered to the client application 310 (operation 1813).
  • the DNS cache 1010 may store at least one of an application name of an MEC application, a domain name, or an IP address for a domain name.
  • the client application 310 may transmit a DNS query to the DNS server 1020 (operation 1815), and obtain an IP address from the DNS server 1020 based on a response 1817 corresponding to the DNS query.
  • the DNS resolving operation of operation 1830 may represent an operation example in which the local DNS cache for MEC (for example, the second DNS cache 1630 is activated in the DNS cache 1010).
  • the client application 310 may transmit a DNS query for a URI to the DNS cache 1010 through the MSE 330 (operations 1831 and 1833).
  • the DNS cache 1010 may transmit a DNS response to a DNS query to the MSE 330 (operation 1835).
  • the DNS cache 1010 when a DNS query for the URI of the client application 310 is performed.
  • the MSE 330 forwards a DNS query to the DNS server 1020 (operation 1837), and the DNS server 1020 A response corresponding to the query may be received (operation 1839), and the received response may be forwarded to the client application 310 (operation 1841).
  • a DNS query for a URI of the client application 310 exists, when there is an IP address of a MEC application of a corresponding URI in the DNS cache 1010, the MEC application may be accessed with the corresponding address.
  • a remote server eg, the remote server 306 of FIG. 3
  • a Client App-driven MEC application may be accessed through DNS resolving.
  • the DNS proxy may hook a DNS query of a client application to perform DNS resolving according to the MEC app list.
  • the MSE 330 may support a DNS pre-resolving or DNS proxy function for a 3rd party application.
  • the DNS proxy intercepts the DNS query and uses the DNS server as the domain name for MEC.
  • the corresponding MEC domain IP address may be returned by querying (1020) or by looking up from the DNS cache 1010.
  • the 3rd party application can provide the MEC service without a separate software modification and without an operator's separate traffic filtering (or steering) operation.
  • each of the signal flow charts described above may operate in connection with other signal flow charts as necessary.
  • the authentication operation eg, at least one of FIGS. 4 to 6
  • the operation of FIG. 7 in which NAS signaling is performed may be performed.
  • each of the signal flow charts described above may be used in place of some of the other signal flow charts as necessary.
  • the operations for authentication of FIGS. 4 to 6 may be implemented by replacing the operations used in other drawings.
  • the present disclosure may be used in the case of providing an edge computing service in a wireless communication system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 LTE와 같은 4G 통신 시스템 이후 보다 높은 데이터 전송률을 지원하기 제공될 5G 또는 pre-5G 통신 시스템에 관련된 것이다. 본 발명의 일 실시 예에 따른 방법은, 이동통신 시스템의 인증 서버에서 엣지 컴퓨팅 서비스를 제공받는 전자 장치의 인증 방법으로, 상기 전자 장치와 인증 및 키 합의(Authentication and Key Agreement, AKA) 방식으로 상기 전자 장치의 제1인증을 수행(403)하고, 제1인증 성공 시 제1인증 정보를 상기 전자 장치로 제공하는 단계; 및 상기 전자 장치의 엣지 컴퓨팅 서비스를 위한 제2인증을 수행(411)하고, 상기 제2인증 성공 시 상기 전자 장치로 상기 엣지 컴퓨팅 서비스의 인증을 위한 접속 토큰을 포함하는 제2인증 정보를 상기 전자 장치로 제공하는 단계;를 포함할 수 있다.

Description

엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
본 개시의 다양한 실시예들은 엣지 컴퓨팅 서비스(예: MEC(multi-access edge computing) 서비스)를 지원하기 위한 방법 그의 전자 장치에 관하여 개시한다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 시스템 이후 (Post LTE) 이후의 시스템이라 불리어지고 있다.
높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역(예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나(large scale antenna) 기술들이 논의되고 있다.
또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀(advanced small cell), 클라우드 무선 액세스 네트워크(cloud radio access network: cloud RAN), 초고밀도 네트워크(ultra-dense network), 기기 간 통신(Device to Device communication: D2D), 무선 백홀(wireless backhaul), 이동 네트워크(moving network), 협력 통신(cooperative communication), CoMP(Coordinated Multi-Points), 및 수신 간섭제거(interference cancellation) 등의 기술 개발이 이루어지고 있다.
이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM(Hybrid FSK and QAM Modulation) 및 SWSC(Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(non orthogonal multiple access), 및 SCMA(sparse code multiple access) 등이 개발되고 있다.
이러한 기술적인 추세에 따라 다양한 무선 통신 시스템 중 하나인 WiFi 무선 통신 시스템에서도 데이터의 고속 전송을 위해 채널 결합(Channel Bonding) 방식을 이용하는 기술이 대두되고 있다. WiFi 무선 통신 시스템에서 채널 결합 기술을 사용하는 방식은 기본 대역에 부가적인 대역을 결합(bonding)하여 데이터의 전송률을 증가시키는 방식을 사용한다. 이러한 기술들의 표준 규약을 예를 들어 살펴보면, IEEE 802.11ac 규격은 8개의 20MHz 채널을 결합하여 최대 160MHz 대역폭을 지원하고, IEEE 802.11ay 규격에서도 채널 결합 기술이 적용될 예정이다. 이처럼 채널 결합 기술을 사용하는 경우 전자장치에서의 소모 전력이 증가하는 것은 필연적이다.
최근 엣지 서버(edge server)를 이용하여 데이터는 전송하는 엣지 컴퓨팅(edger computing) 기술이 논의되고 있다. 엣지 컴퓨팅 기술은 예를 들어 MEC(multi-access edge computing) 또는, 포그 컴퓨팅(fog computing)을 포함할 수 있다. 엣지 컴퓨팅 기술은 전자 장치와 지리적으로 가까운 위치, 예를 들어 기지국 내부 또는 기지국 근처에 설치된 별도의 서버(이하, 엣지 서버 또는 MEC 서버)를 통해 전자 장치에게 데이터를 제공하는 기술을 의미할 수 있다. 예를 들어, 전자 장치에 설치된 적어도 하나의 어플리케이션 중 낮은 지연 시간(latency)을 요구하는 어플리케이션은 외부 데이터 네트워크(data network, DN)(예: 인터넷)에 위치한 서버를 통하지 않고, 지리적으로 가까운 위치에 설치된 엣지 서버를 통해 데이터를 송수신할 수 있다.
최근에는 엣지 컴퓨팅 기술을 이용한 서비스(이하, ‘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 서비스 모듈을 통해 어플리케이션들의 상태 및 전자 장치의 상태를 통합적으로 관리함으로써 안정적인 엣지 컴퓨팅 서비스를 제공할 수 있는 방법 및 장치에 관하여 개시한다.
본 개시의 일 실시예에 따른 방법은, 이동통신 시스템의 인증 서버에서 엣지 컴퓨팅 서비스를 제공받는 전자 장치의 인증 방법으로, 상기 전자 장치와 인증 및 키 합의(Authentication and Key Agreement, AKA) 방식으로 상기 전자 장치의 제1인증을 수행(403)하고, 제1인증 성공 시 제1인증 정보를 상기 전자 장치로 제공하는 단계; 및 상기 전자 장치의 엣지 컴퓨팅 서비스를 위한 제2인증을 수행(411)하고, 상기 제2인증 성공 시 상기 전자 장치로 상기 엣지 컴퓨팅 서비스의 인증을 위한 접속 토큰을 포함하는 제2인증 정보를 상기 전자 장치로 제공하는 단계;를 포함할 수 있다.
본 개시의 다른 실시예에 따른 방법은, 이동통신 시스템의 전자장치가 엣지 컴퓨팅 서비스를 제공하는 이동통신 시스템에서 에지 컴퓨팅 서비스를 위한 인증 방법으로, 상기 전자 장치가 상기 이동통신 시스템의 인증 서버와 키 합의(Authentication and Key Agreement, AKA) 방식으로 제1인증을 수행(403)하고 제1인증 정보를 수신하는 단계; 및 상기 전자 장치가 상기 인증 서버와 엣지 컴퓨팅 서비스를 위한 제2인증을 수행(411)하고, 상기 엣지 컴퓨팅 서비스의 인증을 위한 접속 토큰을 포함하는 제2인증 정보를 수신하는 단계;를 포함할 수 있다.
본 개시의 또 다른 실시예에 따른 방법은, 이동통신 시스템의 멀티 액세스 에지 컴퓨팅 관리 프록시(MMP) 서버에서 엣지 컴퓨팅 서비스를 제공받는 전자 장치로 엣지 컴퓨팅 서비스 정보를 제공하기 위한 방법으로, 상기 전자 장치로부터 상기 MMP에 대한 정규화된 도메인 이름(fully qualified domain name, FQDN)를 포함하는 적어도 하나의 엣지 컴퓨팅 서버의 질의(query) 메시지를 수신하는 단계; 및 상기 질의에 응답하는 응답 메시지를 상기 전자 장치로 송신하는 단계;를 포함하며, 상기 응답 메시지는, 상기 MMP를 통해 엣지 컴퓨팅 서비스를 제공할 수 있는 어플리케이션 리스트를 포함할 수 있다.
본 개시에 따른 또 다른 방법은, 멀티 액세스 에지 컴퓨팅 관리 프록시(MMP) 서버를 통해 엣지 컴퓨팅 서비스를 제공하는 이동통신 시스템에서 전자장치가 엣지 컴퓨팅 서비스 정보를 획득하기 위한 방법으로, 상기 MMP에 대한 정규화된 도메인 이름(fully qualified domain name, FQDN)를 포함하는 적어도 하나의 엣지 컴퓨팅 서버의 질의(query) 메시지를 상기 MMP로 송신하는 단계; 및 상기 MMP로부터 상기 질의에 응답하는 응답 메시지를 수신하는 단계;를 포함하며,
상기 응답 메시지는, 상기 MMP를 통해 엣지 컴퓨팅 서비스를 제공할 수 있는 어플리케이션 리스트를 포함할 수 있다.
본 발명의 일 실시 예에 따른 전자 장치는, 네트워크 인터페이스; 엣지 컴퓨팅 서비스(multi-access edge computing services, MEC)를 위한 적어도 하나의 어플리케이션; 상기 네트워크 인터페이스를 통해 상기 전자 장치의 인증, 상기 MEC의 인증, 상기 MEC의 정책, 상기 MEC의 데이터 경로 설정에 따른 제어를 수행하는 멀티 액세스 서비스 에지전트(MSA); 및 상기 네트워크 인터페이스를 통해 이동통신 시스템의 MEC 관리 프록시 서버(MMP)와 세션 설정 및 데이터 전송 시의 경로를 설정하고, 질의 정보의 송신 및 응답 신호를 수신하고, MMP를 통해 MEC 어플리케이션 서버의 탐색(discovery)을 수행하는 멀티 액세스 서비스 인에이블러(MSE);를 포함할 수 있다.
다양한 실시예들에 따른 전자 장치 및 그의 동작 방법에 따르면, 전자 장치에 대해 보다 최적의 MEC 호스트에 기반하여 MEC 어플리케이션을 실행하여 서비스를 제공할 수 있다. 다양한 실시예들에 따르면, 서비스 디스커버리 동작을 개별 어플리케이션이 아니라, 전자 장치(예: 서비스 인에이블러)에 의해 디스커버리를 수행할 수 있다. 다양한 실시예들에 따르면, MEC 디스커버리를 개별 어플리케이션이 담당하지 않고, 전자 장치(예: 서비스 인에이블러)가 수행함으로써, 보다 신속하고 효율적으로 디스커버리를 수행할 수 있고, 최적 품질을 제공받을 수 있는 MEC 호스트를 선택할 수 있다. 다양한 실시예들에 따르면, 전자 장치에 설치된 MEC 서비스 모듈을 통해 어플리케이션들의 상태 및 전자 장치의 상태를 통합적으로 관리함으로써 안정적인 엣지 컴퓨팅 서비스를 제공할 수 있다.
이 외에, 본 문서를 통해 직접적 또는 간접적으로 파악되는 다양한 효과들이 제공될 수 있다.
도 1은 다양한 실시예들에 따른 네트워크 환경(100) 내의 전자 장치(101)의 블록도이다.
도 2는 다양한 실시예들에 따른 레거시 네트워크 통신 및 5G 네트워크 통신을 지원하기 위한 전자 장치(101)의 블록도(200)이다.
도 3은 본 개시의 다양한 실시예들에 따른 네트워크 환경에서 MEC 기반 서비스를 지원하기 위한 전자 장치(101) 및 외부 서버(300)을 도시하는 도면이다.
도 4는 본 개시의 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 5는 본 개시의 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 6은 본 개시의 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 7은 본 개시에 따른 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 8은 본 개시의 다양한 실시예들에 따른 전자 장치(101)에서 정책 업데이트 동작 예를 도시하는 도면이다.
도 9는 본 개시의 다양한 실시예들에 따른 전자 장치(101)에서 PDU 세션 설정 동작 예를 도시하는 도면이다.
도 10은 본 개시의 다양한 실시예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 11은 본 개시의 다양한 실시예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 12는 본 개시의 다양한 실시예들에 따른 디스커버리 절차에서 앱 리스트를 획득하는 동작 예를 도시하는 도면이다.
도 13은 본 개시의 다양한 실시예들에 따른 앱 리스트가 제공되는 예를 설명하기 위한 도면이다.
도 14는 본 개시의 다양한 실시예들에 따른 디스커버리 절차에서 컨텍스트 생성 절차의 예를 도시하는 도면이다.
도 15는 본 개시의 다양한 실시예들에 따른 디스커버리 절차에서 MEC 호스트 선택 절차의 예를 도시하는 도면이다.
도 16은 본 개시의 다양한 실시예들에 따른 전자 장치(101)에서 MEC 용 로컬 DNS 캐시를 별도로 운용하는 예를 도시하는 도면이다.
도 17은 본 개시의 다양한 실시예들에 따른 전자 장치(101)에서 MSE(330) 내에 MEC 용 로컬 DNS 캐시를 운용하는 예를 도시하는 도면이다.
도 18은 본 개시의 다양한 실시예들에 따른 디스커버리 절차에서 DNS 리졸빙 동작의 예를 도시하는 도면이다.
도 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은 본 개시의 다양한 실시예들에 따른 네트워크 환경에서 MEC 기반 서비스를 지원하기 위한 전자 장치(101) 및 외부 서버(300)을 도시하는 도면이다.
도 3에 도시한 바와 같이, 도 3의 전자 장치(101)는 MEC AA(MEC Authentication/Authorization) 절차와 MEC 디스커버리(discovery) 절차를 위한 소프트웨어 구조(software architecture)의 일 예를 나타낼 수 있다.
일 실시예에 따라, 전자 장치(101)는 엣지 컴퓨팅 서비스(multi-access edge computing services)(이하, MEC 서비스라 한다)를 위한 어플리케이션(들)(이하, 클라이언트 어플리케이션(client App(application))이라 한다)(310), 서비스 에이전트(예: MSA)(320)(이하, MSA(320)이라 한다), 서비스 인에이블러(예: MSE)(330)(이하, MSE(330)이라 한다)를 포함할 수 있다. 일 실시예에 따라, 전자 장치(101)는 데이터 전송에 관련된 PDU(protocol data unit) 세션(session)의 설정(establishment)을 위한 네트워크 인터페이스(340)(예: 도 1 또는 도 2의 무선 통신 모듈(192))를 포함할 수 있고, 도시되지는 않았으나, 네트워크 인터페이스(340)의 구동을 제어하는 네트워크 드라이버(network driver)(예: 소프트웨어 드라이버)를 포함할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(310), MSA(320), 및 MSE(330)은 전자 장치(101)에 소프트웨어로 탑재되거나 물리적인 구성을 갖도록 구성될 수 있다. 일 실시예에 따르면, MSA(320)과 MSE(330)은 프로세서(예: 도 1의 프로세서(120))의 일부로서 구동될 수 있다. 일 실시예에 따르면, MSA(320)과 MSE(330)은 프로세서(120)와 독립적으로 운용되는 별도의 하드웨어 구성일 수 있다. 다른 실시예에 따르면, MSA(320)과 MSE(340)은 소프트웨어(예: 도 1의 프로그램(140))일 수 있다. 예를 들어, 소프트웨어 형태의 MSA(320)과 MSE(340)은 메모리(예: 도 1 또는 도 2의 메모리(130))에 명령어(또는 인스트럭션(instruction))들의 형태로 저장되고 프로세서(120)에 의해 MSA(320)과 MSE(330)의 동작들이 실행될 수 있다.
일 실시예에 따르면, 클라이언트 어플리케이션(310)은 사용자에 의해 전자 장치(101)에 설치되는 3rd 파티(party) 어플리케이션을 포함할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(310)은 MEC 또는 포그 컴퓨팅)와 같은 MEC 서비스를 사용하는 어플리케이션일 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(310)은 무과금(예: FOC, free of charge) 서비스와 같은 차별화된 서비스를 사용하는 어플리케이션을 포함할 수 있다.
일 실시예에 따라, MEC를 위한 클라이언트 어플리케이션(310)은, MEC 호스트에서 구동되는 MEC 어플리케이션에 접속하는 전자 장치(101)의 어플리케이션을 의미할 수 있다. 일 실시예에 따라, MEC 어플리케이션은 사용자에 인접한 MEC 호스트에 설치 및 실행되어 클라이언트 어플리케이션(310)과 통신하는 어플리케이션을 의미할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(310)은 별도의 인증 클라이언트 역할을 하는 MSA(320)(예: 서비스 에이전트)를 통해 인증(authentication)을 받을 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(310)은, 네트워크 인터페이스(340)을 통해, 특정 PDU 세션(예: MEC 전용 PDU 세션(dedicated PDU session))에 기반하여 네트워크에 접속하거나, 또는 MSE(330)(예: 서비스 인에이블러)의 DNS 프록시(proxy) 기능을 통해 기존 PDU 세션(예: default PDU session)으로 MEC 어플리케이션에 접속할 수 있다.
일 실시예에 따라, 무과금 서비스를 위한 클라이언트 어플리케이션(310)은, 데이터 무과금 정책을 적용하는 전자 장치(101)의 어플리케이션을 의미할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(310)은 무과금 인증 담당 MSA(320)을 통해 인증이 되면 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(320) 또는 MSE(330))를 통해 수신될 수 있다.
일 실시예에 따르면, MSA(320)(예: 서비스 에이전트)는 외부 서버(300)의 AA(Authentication/Authorization) 서버(380)(예: 인증 서버)와 MEC 서비스에 관련된 인증 절차(예: 인증 및 권한 부여(AA, Authentication/Authorization) 절차)를 처리할 수 있다. 예를 들어, MSA(320)은 AA의 결과로 수신한 URSP 규칙 및/또는 MEC 접속 토큰을 MSE(330)로 전달하는 역할을 포함할 수 있다. 일 실시예에 따르면, MSA(320)은 어플리케이션 이벤트(예: 실행(launch), 종료)를 감지하거나, 특정 이벤트를 어플리케이션으로 전달하는 역할을 포함할 수 있다. 다양한 실시예들에 따르면, 전자 장치(101)의 MSA(320)은 AA 클라이언트(325)를 포함할 수 있다. 일 실시예에 따르면, AA 클라이언트(325)는 전자 장치(101)를 생산하는 생산자(또는 제조사) 또는 오퍼레이터(operator)(예: 서비스 사업자)에 의해 제공될 수 있다. 일 실시예에 따르면, MSA(320)는, AA 클라이언트(325)에 기반하여, 전자 장치(101)의 가입자 식별 정보에 기반하여 AA(Authentication/Authorization)를 수행할 수 있다. 가입자 식별 정보는, 예를 들어, SIM(subscriber identity module), USIM(universal SIM), IMEI(international mobile equipment identity), 또는 GPSI(generic public subscription identifier)를 포함할 수 있다. 예를 들어, MSA(320)은 가입자 식별 정보에 기반하여 AA 서버(380)과 통신을 통해 MSE(330)에 의한 서비스(예: MSE 서비스)를 사용하기 위한 인증(Authentication) 및 권한(Authorization) 부여 기능을 제공하는 어플리케이션(또는 소프트웨어)일 수 있다. 일 실시예에 따라, MSE 서비스는, 예를 들어, MSE(330)을 통하여 서비스를 받는 MEC, FOC, MMS, 또는 URLLC(ultra-reliable and low latency communications)와 같은 서비스를 통칭할 수 있다.
일 실시예에 따르면, MSA(320)은 AA 서버(380)와 통신을 통해 MSE 서비스 인증 및 권한 부여를 받으면, 권한 부여된 서비스 타입에 대해 MSE API(application programming interface)를 사용하여 MSE(330)를 활성화/비활성화(enable/disable)(예: MSE 서비스를 활성화/비활성화) 할 수 있으며, 서비스 타입 별 사용 가능한 클라이언트 어플리케이션(310)의 UID 및 규칙(rule)(예: ApnSettings)을 등록하고, 라우팅(routing) 설정을 요청할 수 있다. 일 실시예에 따라, MSE API는 MSE 서비스 타입 별 활성화/비활성화 및 UID 별 라우팅 규칙 설정(routing rule setting)을 위해 전자 장치(101)에서 상위 어플리케이션 레이어로 제공하는 API를 포함할 수 있다. 일 실시예에 따르면, MSE API는 MEC 디스커버리 절차를 위한 정책 또는 컨텍스트(context) 모니터링 정책과 같은 적어도 하나의 정책을 설정하기 위한 API를 포함할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(310)은 MSA(320)과 인증 및 권한 부여 절차를 통해 해당 서비스(예: MEC, FOC)에 접근할 수 있다.
일 실시예에 따라, MSA(320)이 오퍼레이터(예: 서비스 사업자)에 의해 구현되는 경우, 예를 들어, 오퍼레이터가 MSE 서비스를 사용하는 MSA(예: operator MSA)를 직접 개발할 경우, MSA(320)은 AA 서버(380)을 통해 MSE 서비스 사용을 위한 인증 및 권한 부여 절차를 직접 수행할 수 있다. 일 실시예에 따라, MSA(320)은 인증 및 권한 부여 절차에서 AA 서버(380)로부터 어플리케이션 별 라우팅 규칙(routing rule)(예: 전용 PDU 세션 사용시 DNN(data network name(=APN in LTE)) 정보)을 수신할 수 있다. 일 실시예에 따라, MSA(320)이 MSE API 사용을 위해서는 MSA(320)과 전자 장치(101) 간 인증 및 권한 부여 절차를 수행할 수 있다. 예를 들어, 사전에 MSA(320)을 전자 장치(101)에 탑재 시, MSA app APK의 서명(signing)을 통해 플랫폼 키(platform key)로 인증할 수 있다. 일 실시예에 따라, 전자 장치(101)가 인증 모듈을 포함(또는 지원)할 시, MSA(320)의 설치 후 전자 장치(101) 내 인증 모듈과 별도의 인증 절차를 거쳐 MSE API에 대한 사용 권한을 획득하도록 할 수도 있다. 일 실시예에 따라, MSE 서비스 인증 절차가 완료되면, MSA(320)은 수신된 정책을 기반으로 MSE API를 호출하여 PDU 세션의 생성/종료와 라우팅 규칙 설정을 수행할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 MEC 용 어플리케이션의 데이터 경로(data path) 설정 시, MSE(330)의 다양한 엔티티(예: MEC 활성화 레이어(MEL, MEC enabling layer)(331), URSP 핸들링 레이어(UHL, URSP handling layer)(333), 또는 DNS(domain name system) 핸들링 레이어(DHL, DNS handling layer)(335)) 중 적어도 하나의 엔티티를 경유하도록 데이터 경로(예: 경로 ⓐ, 경로 ⓑ, 또는 경로 ⓒ)를 설정할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 용 어플리케이션의 데이터 경로 설정 시, 기본 PDU 세션(default PDU session)을 사용(예: 경로 ⓐ)하거나, 또는 별도의 전용 PDU 세션(dedicated PDU session)을 사용(예: 경로 ⓑ 또는 경로 ⓒ)하는 것에 기반하여 데이터 경로를 다르게 설정할 수 있다. 일 실시예에 따라, 별도의 전용 PDU 세션을 사용하는 경우, MSE(330)의 MEL(331)을 통해 MEC 디스커버리 절차를 수행하는지 여부에 따라 경로 ⓑ 또는 경로 ⓒ의 데이터 경로가 결정될 수 있다.
일 실시예에 따르면, MSA(320)은 MSE(330)의 MEL(331)을 경유하지 않고, MSE(330)의 UHL(333)에 직접 요청하여 전용 PDU 세션(dedicated PDU session)을 구성(예: 서비스의 경로를 경로 ⓒ로 설정)할 수 있다. 예를 들어, 전자 장치(101)에서 스폰서드(sponsored) 어플리케이션 실행 시, 미리 특정한 서버 또는 네트워크와 약속된 경우에, MSA(320)은 UHL(333)에 요청하여 해당하는 서비스를 전용 PDU 세션을 통하여 제공할 수 있다. 일 실시예에 따르면, MSA(320)은 UHL(333)로 서비스를 식별하기 위한 별도의 정보를 더 생성하거나. 또는 외부 서버로부터 수신하여 제공할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 MSA(320)의 하위 레이어에, MSE(330)(예: 서비스 인에이블러)를 포함할 수 있다.
일 실시예에 따르면, MSE(330)은 클라이언트 어플리케이션(310)이 MSA(320)을 통해 MEC 서비스(또는 MSE 서비스) 사용이 가능하도록, MSA(320)에 MSE API를 제공할 수 있으며, 이에 따라 어플리케이션 별 사용 PDU 세션에 대한 라우팅 테이블(routing table)이 설정될 수 있다. 일 실시예에 따르면, MSE(330)은 어플리케이션 ID 별 또는 URI 별 사용할 PDU 세션 경로에 대한 라우팅 테이블을 설정하여, 메모리(예: 도 1 또는 도 2의 메모리(130))에 저장할 수 있다. 일 실시예에 따르면, MSE(330)은 어플리케이션 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(330)은 MEC 서비스를 위해서, MEC 서비스 디스커버리(service discovery), 위치 확인(location verification), 라우트 선택(route selection), 성능 확인(performance verification), 또는 이동성 지원(mobility support)의 추가적인 기능을 지원할 수 있다.
다양한 실시예들에 따르면, MSE(330)은 적어도 하나의 MEC 호스트(또는 MEC 어플리케이션)와 연결된 상태에서, 특정한 서비스를 제공하기 위해 전용 PDU 세션으로 구성하도록 하거나, 또는 기본 PDU 세션으로 구성하도록 할 수 있다. 일 실시예에 따르면, 전용 PDU 세션 또는 기본 PDU 세션의 구성에 필요한 정보는, 예를 들어, 전자 장치(101)의 모뎀(또는 CP, communication processor)에서, AMF/PCF 서버(390)로부터 NAS(non-access stratum) 정보(information)를 통해 수신할 수 있다.
일 실시예에 따르면, MSE(330)은 MEL(331), UHL(333), 및 DHL(335)를 포함할 수 있다.
일 실시예에 따라, MEL(331)은 MSE 서비스 중 MEC 서비스 사용을 위해 필요한 작업을 수행할 수 있다. 예를 들면, MEL(331)은 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 서버(370)(또는 LCM 프록시 서버) 또는 MEC 솔루션 제공 서버(solution provider server)로부터 MEC 서비스 가입 여부를 인증 받고, MEC 서비스 권한 레벨(level)에 맞는 토큰(token)(예: Cookie)을 수신하여 메모리(예: 도 1 또는 도 2의 메모리(130))에 저장할 수 있다. 이후의 MEC 서비스는 토큰이 유효한 시간 동안 해당 토큰을 사용하여 서비스 요청을 수행할 수 있다.
일 실시예에 따라, MEC 서비스 디스커버리는, 전자 장치(101)가 MEC 서비스가 가능한 영역에 들어왔을 때(예: 특정 셀(cell) ID 접속 또는 LADN 영역 진입), MEL(331)이 이를 감지하여, 해당 지역에서 사용 가능한 앱 리스트(예: MEC App (name) list) 또는 도메인 이름(domain name)(예: MEC 어플리케이션 별 도메인 이름) 중 적어도 하나를 수신하고, 사용자 설정에 따라 다양한 기능을 수행할 수 있다. 예를 들어, MEL(331)은, 사용자 설정에 따라 가용 MEC 어플리케이션 알림, DNS 프록싱(proxying), 및/또는 MEC 어플리케이션 활성화를 제공할 수 있다. 일 실시예에 따라, MEL(331)은 가용 MEC 어플리케이션에 대해 알림을 제공할 수 있다. 예를 들어, 현재 사용 가능한 MEC 어플리케이션을 알림 창 또는 어플리케이션 아이콘(예: 앱 아이콘)에 표시할 수 있다. 일 실시예에 따라, 전자 장치(101) 상에 해당 MEC 어플리케이션에 대응되는 클라이언트 어플리케이션의 설치를 알림할 수도 있다.
일 실시예에 따라, MEL(331)은 DNS 프록싱(proxying)을 제공할 수 있다. 예를 들어, 클라이언트 어플리케이션이 MEC 어플리케이션에 접속하기 위하여 해당 도메인 이름(domain name)에 대한 DNS 쿼리(query) 발생 시, 해당 어플리케이션 이름(application name) 또는 DNS 쿼리 중 적어도 하나가 MEC 앱 리스트에 매칭(matching)이 될 경우, MEL(331)은 해당 DNS 쿼리를 MEC 용 DNS 서버에 전송하여, 해당 MEC 어플리케이션에 대한 접속 IP 주소를 받아오고, 이를 클라이언트 어플리케이션(310)에 리턴(return)할 수 있다. 일 실시예에 따라, 해당 IP 주소는, 예를 들어, 유효 기간 동안 전자 장치(101) 내 MEC 용 DNS 캐시에 저장할 수 있다. MEC 앱 리스트 상의 도메인 이름에 대한 MEC DNS 리졸빙(resolving)은 클라이언트 어플리케이션의 DNS 쿼리와 별도로 MEL(331)이 자체적으로 수행하여 MEC 용 DNS 캐시에 저장할 수 있다.
일 실시예에 따라, MEL(331)은 MEC 어플리케이션 활성화를 제공할 수 있다. 예를 들어, 전자 장치(101)에 설치된 MEC 클라이언트 어플리케이션이 사용 중이거나 또는 사용이 예상될 경우, 이와 연동하는 MEC 어플리케이션 활성화(예: 인스턴스 생성(instantiation))을 요청할 수 있다. 일 실시예에 따르면, 해당 MEC 어플리케이션이 전자 장치(101)의 접속 지역 MEC 호스트에 설치되어 있지 않을 경우, 설치를 요청(예: 패키지(package) URI 포함)할 수 있다.
일 실시예에 따라, 라우트 선택(예: DNN handling)은, 기본 PDU 세션을 사용하지 않고, MEC 서비스 또는 MEC 어플리케이션을 위한 전용 PDU 세션의 사용을 원할 경우, 클라이언트 어플리케이션의 UID에 대한 라우팅 규칙(routing rule)을 설정할 수 있다. 일 실시예에 따르면, MSE(330)이 MEC 서비스 또는 MEC 어플리케이션을 위한 전용 DNN 정보를 미리 정의된 프로필(predefined profile) 또는 AA 서버(380)로부터 수신하고, UHL API(미도시)를 사용하여 MEC 전용 PDU 세션의 생성을 요청할 수 있다.
일 실시예에 따라, 성능 사전 측정은, 예를 들어, MEL(331)이 복수의 후보(candidate) MEC 호스트들에 대해 사전 성능 테스트하는 것을 포함할 수 있다. 예를 들어, MEL(331)은 사전 성능(예: ping probing, bandwidth estimation) 테스트를 통해 최적 MEC 호스트를 선택할 수 있다.
일 실시예에 따라, 위치 서비스는, 예를 들어, 전자 장치(101)가 위치된 지역에 기반하여 서비스를 제공하는 것을 포함할 수 있다. 일 실시예에 따르면, MEL(331)은 전자 장치(101)의 해당 위치에서의 서비스 가용성(service availability)(또는 location accuracy)에 관한 정보를 제공할 수 있다. 일 예로, 서비스 가용성에 관한 정보는, 예를 들면, 서비스 가능 지역(location confirmed), 해당 서비스 없음(location not found), 또는 서비스 불가 지역(location spoofed)과 같은 정보를 포함할 수 있다.
일 실시예에 따라, 이동성 핸들링은, 예를 들어, 핸드오버가 발생하는 영역에서의 서비스 연속성(service continuity)을 위한 핸들링을 제공할 수 있다. 예를 들어, MEL(331)은 MEC 호스트에서 다른 MEC 호스트로 핸드오버 또는 MEC 호스트에서 리모트 호스트(remote host)로 핸드오버를 처리할 수 있다.
일 실시예에 따르면, MEL(331)은 MMP 서버와의 통신을 통해 MEC 호스트의 MEC 어플리케이션의 디스커버리(discovery)을 위한 제어 및 서비스의 종류를 식별할 수 있다. 예를 들어, MEL(331)은 미리 정의된 MSE API 호출에 의해 서비스를 식별할 수 있다. 다른 예를 들어, MEL(331)은 사업자 서버(예: AA 서버(380)) 또는 MMP 서버(370)로부터 수신한 정책에 따라 서비스를 식별할 수 있다.
일 실시예에 따르면, MEL(331)은 서비스의 식별 결과, 예를 들어, 기본 PDU 세션을 사용하는 서비스인 경우 DHL(335)를 경유하는 서비스의 경로(예: 경로 ⓐ)를 설정하고, 이에 따라 MEL(331) 및 DHL(335)에 의해 MEC 서비스를 제공할 수 있다. 일 실시예에 따르면, MEC 용 어플리케이션을 위한 데이터 경로 ⓐ의 경우, MEL(331)이 기본 PDU 세션을 통하여 서비스가 제공되도록 구성할 수 있다. 다른 실시예에 따르면, MEL(331)은 서비스의 식별 결과, 예를 들어, 전용 PDU 세션을 사용하는 서비스인 경우 MEL(331), UHL(333), 및 DHL(335)를 경유하는 서비스의 경로(예: 경로 ⓑ)를 설정하고, 해당 서비스를 MEL(331), UHL(333), 및 DHL(335)에 의해 제공할 수 있다. 일 실시예에 따르면, MEC 용 어플리케이션을 위한 데이터 경로 ⓑ의 경우 MEL(331)이 UHL(333)에 요청하여 전용 PDU 세션을 통하여 서비스가 제공되도록 구성할 수 있다. 일 실시예에 따르면, 전술한 다양한 서비스를 식별하기 위하여 MSA(320)이 MEL(331)로 별도의 정보를 더 제공하거나 MEL(331)이 MMP 서버(370)로부터 관련 정보를 수신(또는 획득)하도록 할 수 있다.
일 실시예에 따라, UHL(333)은 API 호출에 따라 서비스 타입 별 전용 PDU 세션을 요청하고, 해당 어플리케이션에 대해 설정된 전용 PDU 세션으로 바인딩(binding) 할 수 있다.
일 실시예에 따라, DHL(335)는 3rd 파티 어플리케이션에 DNS 사전 리졸빙(pre-resolving) 또는 DNS 프록시 기능을 지원할 수 있다. 예를 들어, 기존 기본 PDU 세션을 통해 데이터 연결이 된 상태에서 MEC 용 클라이언트 어플리케이션이 특정 서비스 접속을 위한 DNS 쿼리를 발생하면, DNS 프록시가 DNS 쿼리를 가로채서, MEC 용 도메인 이름으로 DNS 서버에 쿼리를 전달하거나, 또는 DNS 캐시에서 룩업(lookup)하여 해당 MEC 도메인 IP 주소를 반환할 수 있다. 이를 통해, 3rd 파티 어플리케이션이 별도의 소프트웨어 수정 없이, 그리고 오퍼레이터의 별도 트래픽 필터링(traffic filtering)(또는 steering) 작업 없이 MEC 서비스를 제공할 수 있다.
일 실시예에 따라, AA 서버(380)은 MSE 서비스 사용을 위한 인증 및 권한 부여를 제공할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 MSA(320)은 AA 서버(380)을 통해 인증 및 가입자 정보에 따라 서비스 타입 별 권한을 부여 받을 수 있다. 일 실시예에 따르면, MSA(320)은 MSE 서비스 사용 가능 클라이언트 어플리케이션을 인증할 수도 있다. 일 실시예에 따르면, AA 서버(380)과 전자 장치(101)의 MSA(320) 간의 인증 절차는 별도 PDU 세션을 통하지 않고, 예를 들어, LTE 또는 Wi-Fi와 같은 통신을 통해 현재 인터넷(internet)에 연결된 기본 PDU 세션을 사용할 수 있다.
일 실시예에 따라, MMP 서버(370)은 전자 장치(101)의 인증 또는 MEC 제어를 위해 전자 장치(101)와 통신하는 프록시 서버를 의미할 수 있다. 일 실시예에 따르면, MMP 서버(370)는, 예를 들어, HTTP(hypertext transfer protocol)에 기반하여 요청/응답(request/response) 메시지 교환을 수행할 수 있다. 일 실시예에 따라, 전자 장치(101)가 AA 서버(380) 또는 MEC 솔루션 제공 서버와 직접 통신 가능할 경우, LCM 프록시는 필요하지 않을 수 있다. 예를 들어, LCM 프록시가 제공하는 서버 API를 사용하는 경우, MSA(320)의 인증 요청 메시지는 AA 서버(380)로 포워딩(forwarding) 되어 인증을 수행하고, MEC 제어 메시지는 MEC 솔루션 제공 서버로 전달될 수 있다. 다양한 실시예들에서, MSA(320)과 MMP 서버(370) 또는 인타이틀먼트 서버(entitlement server) 간 연동 API는 생략할 수 있으며, AA 절차(예: 인증 및 권한 부여 절차)에서 필요한 정보는 미리 수신될 수 있다.
일 실시예에 따라, AMF(access and mobility function)/PCF(policy control function) 서버(390)는, 예를 들어, 5G NR(new radio) 표준에서 MEC 지원 시, PCF에 MMP 정보 및 URPS 규칙(rule)이 등록되고, NAS 시그널링(signaling)을 통해 AMF로부터 해당 정보를 수신할 수 있다.
이상에서와 같이, 다양한 실시예들에 따르면, MSA(320)은 AA 서버(380)과 통신하여 인증을 수행하고 원하는 정보(예: 인증 및 권한 부여)를 요청할 수 있고, 요청한 정보를 AA 서버(380)로부터 수신하여 획득할 수 있다. 다양한 실시예들에 따르면, MSE(330)은 MMP 서버(330)과 통신하여 원하는 정보를 요청할 수 있고, 요청한 정보를 MMP 서버(330)로부터 수신하여 획득할 수 있다. 예를 들어, MSE(330)은 MMP 서버(370)과 통신하여 MEC 앱 리스트를 획득하거나, 또는 MEC 서비스 디스커버리 절차를 수행하고, 특정한 적어도 하나의 MEC 호스트(또는 MEC 어플리케이션)과 연결을 설정할 수 있다.
다양한 실시예들에 따르면, 도 3을 참조한 설명 부분에서 설명한 바와 같이 MSA(320)과 MSE(330)을 포함하는 전자 장치(101)에 기반하여, MEC 용 어플리케이션의 데이터 경로 설정 시, 다음과 같이 다양한 서비스 시나리오를 제공할 수 있다.
1. 제1 데이터 경로(예: 경로 ⓐ)의 시나리오(예: MSE on Single PDU Session)
일 실시예에 따른 제1 데이터 경로(예: 경로 ⓐ)의 시나리오는, 클라이언트 어플리케이션이 기존 인터넷 데이터(internet data)를 위해 사용 중인 기본 PDU 세션(또는 PDN(public data network) 연결)을 사용하여 MEC 어플리케이션에 연결하는 시나리오를 나타낼 수 있다. 일 실시예에 따르면, MEL(331)에서 MEC 디스커버리 절차를 수행하여, 전자 장치(101)에 가까운 MEC 호스트에 MEC 어플리케이션 구동 및 연결을 요청하고, 해당 MEC 어플리케이션의 URI를 수신할 수 있다. 클라이언트 어플리케이션(310)이 해당 MEC 어플리케이션 접속 요청 시, 해당 URI에 대한 DNS 리졸빙(resolving)을 통해 획득한 MEC 어플리케이션 IP 주소로 접속을 수행할 수 있다. 일 실시예에 따라, 제1 데이터 경로의 시나리오(예: MSE on Single PDU Session)에서는 MEC 서비스를 위한 별도의 PDU 세션을 사용하지 않으므로, 동작 상에 URSP 규칙을 제어하는 UHL(333)은 개입하지 않을 수 있다.
2. 제2 데이터 경로(예: 경로 ⓑ)의 시나리오 B(예: MSE on Multiple PDU Sessions with MEL)
일 실시예에 따른 제2 데이터 경로(예: 경로 ⓑ)의 시나리오는, 클라이언트 어플리케이션이 기존 인터넷 용 기본 PDU 세션(또는 PDN 연결) 외에, 별도의 MEC 전용 PDU 세션을 생성하여 MEC 어플리케이션에 연결하는 시나리오를 나타낼 수 있다. 일 실시예에 따라, MEC 전용 PDU 세션 생성은 사업자(예: MNO(mobile network operator) 또는 MMP 서버(370)) 정책에 따르며, MSA(320) 또는 인증된 클라이언트 어플리케이션(310)이 MSE API를 사용하여 UHL(333)을 통해 생성할 수 있다. 일 실시예에 따라, MEC 전용 PDU 세션은 기본 PDU 세션 외에 하나 이상의 PDU 세션을 항상 열어둘 수도 있고, 특정 시점에 필요에 따라 MEL(331)의 요청에 의해 동적으로 생성하거나 해제할 수 있다. 일 실시예에 따르면, 사전에 정의된 규칙(rule)(예: CARP 또는 URSP 규칙) 또는 외부 서버(예: MMP 서버(370), AA 서버(380), 또는 AMF/PCF 서버(390))로부터 수신한 라우팅 규칙(routing rule)에 따라 해당 클라이언트 어플리케이션(또는 UID) 또는 접속 URI에 대한 트래픽(traffic)을 MEC 전용 PDU 세션으로 라우팅(routing) 되도록 MSE(330)의 UHL(333)에서 지원할 수 있다.
3. 제3 데이터 경로(예: 경로 ⓒ)의 시나리오(예: MSE on Multiple PDU Sessions without MEL)
일 실시예에 따른 제3 데이터 경로의 시나리오는, MEL(331)의 기능 없이, 특정 서비스에 대해 전용 PDU 세션만 생성하여 사용하는 시나리오를 나타낼 수 있다. 일 실시예에 따르면, MSA(320) 또는 인증된 클라이언트 어플리케이션(310)에 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(320)과 MSE(330)을 포함하는 전자 장치(101)에 기반하여 다양한 실시예들에 따른 인증 및 권한 부여(예: AA(authentication/authorization)) 및 정책(policy)(예: app routing policy, discovery policy, 또는 monitoring policy)을 수신하고, 수신된 정책에 기반한 라우트(route) 설정 및 MEC 디스커버리 절차를 수행하는 다양한 동작들에 대하여 설명한다.
이하에서 설명하는 전자 장치(101)에서 수행하는 동작들은, 전자 장치(101)의 적어도 하나의 프로세서(예: 프로세싱 회로를 포함하는 적어도 하나의 프로세서로서, 예를 들면, 도 1의 프로세서서(120))에 의해 실행될 수 있다. 일 실시예에 따라, 전자 장치(101)에서 수행하는 동작들은, 메모리(예: 도 1의 메모리(130)에 저장되고, 실행 시에, 프로세서(120)가 동작하도록 하는 인스트럭션들(instructions)에 의해 실행될 수 있다.
다양한 실시예에 따르면, 전자 장치(101)는 MMP(MEC Management Proxy) 서버(430) 와 전자 장치(101) 사이에 배치되는 액세스 노드(도면에 미도시)를 통해 무선 통신을 수행할 수 있다.
예를 들면, 엣지 컴퓨팅 서비스(예: MEC 서비스)를 위해 전자 장치(101) 내 서비스 에이전트(service agent)(320)(예: MSA, multi-access service agent)와 서비스 인에이블러(service enabler)(330)(예: MSE, multi-access service enabler)를 포함하는 MEC 서비스 모듈(도면에 미도시)과 연동하는 네트워크 엔티티들을 나타낼 수 있다.
다양한 실시예들에 따르면, 도 3의 예시에서 서비스 에이전트(예: MSA)(320) 및 서비스 인에이블러(예: MSE)(330)와 MMP 서버(370) 간에 연동하는 제어 경로(예: MEC 제어 평면)에서, 인증(authentication), 권한(authorization) 부여, 및 디스커버리(discovery) 절차를 수행할 수 있다. 일 실시예에 따르면, 디스커버리 절차 이후 전자 장치(101)의 어플리케이션들(예: 제1 App, 제2 App)과 MMP 서버(370)과 연결되는 MEC 어플리케이션들(예: 제1 MEC App, 제2 ME App - 도면에 미도시) 간에 데이터 경로(예: MEC 사용자 평면)를 통해 MEC 데이터 서비스가 제공될 수 있다. 도 3에서 도시되지는 않았으나, 전자 장치(101)는 DNS(domain name system) 쿼리/응답(query/response) 데이터 경로를 통해 DNS 서버와 데이터 통신을 수행할 수 있다.
일 실시예에 따르면, MMP 서버(370)는 사용자 단말(UE, user equipment)(예: 전자 장치(101))에 엣지 컴퓨팅 시스템(예: MEC 시스템)에 대한 사용자 어플리케이션 인터페이스(참조: ETSI MEC 016 표준 참고)를 제공할 수 있다. 예를 들어, 전자 장치(101)는 MMP 서버(370)에게 MEC 시스템이 제공 가능한 어플리케이션(들)에 관한 정보(예: 가용 어플리케이션 목록)를 요청할 수 있고, MEC 시스템에 특정 어플리케이션의 실행 요청(예: context creation) 및 중지 요청(예: context termination)을 전달할 수 있다. 다른 예를 들어, MMP 서버(370)는 MEC 시스템에 설치된 어플리케이션들의 라이프 사이클(life cycle)에 대한 관리를 수행할 수 있다. 예를 들어, MMP 서버(370)는 전자 장치(101)의 요청을 수신하고, 수신된 요청을 MEC 시스템으로 전달하여, MEC 시스템에 설치된 어플리케이션들의 라이프 사이클에 대한 관리를 수행할 수 있다.
일 실시예에 따르면, MEC 서비스 모듈은 서비스 에이전트(예: MSA)(320) 및 서비스 인에이블러(예: MSE)(330)을 포함할 수 있다. 다양한 실시예들에 따르면, MEC 서비스 모듈은 다양한 실시예들에 따른 인증 및 권한 부여(예: AA(authentication/authorization)) 및 정책(policy)(예: 어플리케이션 라우팅 정책(app routing policy), 디스커버리 정책(discovery policy)(또는 모니터링 정책(monitoring policy))(예: 모니터링할 정보 리스트))을 수신하여 처리할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈은 서비스 에이전트(예: MSA)(320)를 이용하여 AA(authentication/authorization) 및 정책(예: 모니터링할 정보 리스트)를 수신하고, 서비스 인에이블러(예: MSE)(330)를 이용하여 수신된 정책에 기반한 라우트(route) 설정 및 MEC 디스커버리 절차를 수행할 수 있다.
다양한 실시예들에 따르면, MEC 서비스 모듈은 MEC 서비스 모듈 내의 엔티티(entity)(예: 서비스 에이전트(MSA)(320) 또는 서비스 인에이블러(MSE)(330)) 중 적어도 어느 하나가 MEC 디스커버리 조건에 대한 모니터링을 수행하도록 동작할 수 있으며, 해당 엔티티에 의해 모니터링된 결과를 서비스 인에이블러(MSE)(330)에 전달하도록 동작할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈은 서비스 에이전트(MSA)(320)를 통해 AA 및 디스커버리 관련 정책을 획득(또는 수신)하도록 할 수 있다. 일 실시예에 따라, 서비스 에이전트(320)가 모니터링을 수행하는 경우, 서비스 에이전트(320)에 의해 MEC 디스커버리 조건을 모니터링 하여, 조건을 충족할 시, 서비스 인에이블러(MSE)(330)에 MEC 디스커버리 요청을 전달하고, 서비스 인에이블러(330)를 통해 MEC 디스커버리 절차를 수행할 수 있다. 다른 실시예에 따라, 서비스 인에이블러(330)가 모니터링을 수행하는 경우, 서비스 에이전트(320)가 서비스 인에이블러(330)로 정책을 전달하고, 서비스 인에이블러(330)는 전달된 정책에 따라 MEC 디스커버리 조건을 모니터링 하여, 조건을 충족할 시 MEC 디스커버리 절차를 수행할 수 있다.
일 실시예에 따르면, 서비스 에이전트(320)는 전자 장치(101)의 컨텍스트(context) 정보를 모니터링 할 수 있다. 컨텍스트 정보는, 예를 들어, 전자 장치(101)에 설치된 어플리케이션들 중 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)에 관하여 후술하는 도면들을 참조하여 상세히 설명된다.
일 실시 예에 따르면, 서비스 인에이블러(330)는 모니터링된 컨텍스트 정보에 기반하여 어플리케이션들의 MEC 기반 데이터 전송을 관리(또는 처리)할 수 있다.
예를 들어, 복수의 어플리케이션들이 개별적으로 MMP 서버(370)로 정보를 요청하지 않고, 다양한 실시예들에 따른 서비스 인에이블러(330)는 전자 장치(101)의 이동성과 관련된 이벤트가 감지되면 MMP 서버(370)에게 MEC 시스템이 제공 가능한 어플리케이션들(예: MEC 어플리케이션들과 관련된 정보를 요청하거나 수신함으로써 전자 장치(101)의 부하를 줄일 수 있다.
다른 예를 들어, 서비스 인에이블러(330)는 MEC 어플리케이션들 또는 전자 장치(101)에 포함된 어플리케이션들 중 적어도 하나의 어플리케이션이 MEC에 기반한 데이터 전송을 수행할 수 있는 지정된 조건을 만족하는 지를 결정하고, 지정된 조건을 만족하는 적어도 하나의 어플리케이션이 MEC 기반 데이터 전송을 수행하도록 해당 어플리케이션에 알려줄 수 있다(notify). 지정된 조건을 만족하는 적어도 하나의 어플리케이션이 전자 장치(101)에 설치되어 있지 않으면, 서비스 인에이블러(330)는 어플리케이션을 설치하도록 어플리케이션 레이어(446) 및/또는 프레임워크(framework)(예: 미들웨어(144) 및/또는 운영 체제(142))에 가이드 할 수 있다. 예를 들어, 어플리케이션 레이어(310)의 요청에 따라, 전자 장치(101)에 신규 어플리케이션을 설치하도록 할 수 있다. 다양한 실시예들에서, 전자 장치(101)는 신규 어플리케이션에 대한 정보(예: URI 또는 IP 주소, 어플리케이션 이름)를 MEC 시스템으로부터 수신(또는 획득)할 수 있다.
다른 예를 들어, 서비스 인에이블러(330)는 라이프 사이클 동기화와 관련된 지정된 조건(이하, 제2 조건)이 감지되면, 라이프 사이클 동기화를 MMP 서버(370)(예: LCM 프록시 서버) 또는 엣지 서버(또는 MEC 서버)에게 요청함으로써, 엣지 서버의 자원 소모를 줄일 수 있다. 예를 들어, 서비스 인에이블러(330)는 어플리케이션들의 사용 여부를 MMP 서버(370)로 통지할 수 있다. 일 실시예에 따라, 어플리케이션들이 사용 중일 때만 MEC 어플리케이션들이 동작(예: 데이터 전송)을 수행하고, 어플리케이션들이 미사용 중(예: screen off, 클라이언트 어플리케이션 백그라운드(background) 상태 변경, 사용자 이동 속도가 일정 이상 중 적어도 하나 만족)일 때에는 MEC 어플리케이션들이 동작(예: 데이터 전송)을 중지할 수 있다. 일 실시예에 따르면, 서비스 인에이블러(330)가 상기와 같이 어플리케이션들의 사용 여부를 MMP 서버(370)에 알려줌으로써, MEC 호스트(또는 엣지 서버)의 자원을 효율적으로 관리하도록 할 수 있다. 일 실시예에 따라, 미사용 중인 어플리케이션에 대해서는 MEC 어플리케이션의 자원 할당을 해제하여 MEC 호스트의 자원 소모를 줄일 수 있다.
다른 예를 들어, 복수의 어플리케이션들이 MEC에 기반한 데이터 전송을 위하여 개별적으로 인증 절차를 수행하는 방법과 달리, 서비스 인에이블러(330)는 전자 장치(101)에 대한 인증 절차를 MMP 서버(370)(또는 엣지 서버)와 통합적으로 수행함으로써 네트워크 부하를 줄일 수 있다.
도 4는 본 개시의 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 4에 도시한 바와 같이, 전자 장치(101)는 MSA(또는 서비스 에이전트)(320)(예: AA 클라이언트(325) 포함)와 MSE(또는 서비스 인에이블러)(330)(예: MEL(331), UHL(333) 포함)를 포함할 수 있다.
도 4을 참조하면, 동작 401에서, 전자 장치(101)의 MSA(320)은 지정된 적어도 하나의 인증 방식(예: 제1 인증)에 기반하여 인증(예: 제1 인증) 요청(authentication request)을 위한 메시지(예: 제1 요청 메시지)를 AA 서버(380)에 전송할 수 있다. 일 실시예에 따르면, MSA(320)은 AA 서버(380)과 GPSI(generic public subscription identifier) 기반 Application-layer AKA 방식, ID/password 기반 Login 방식, 또는 GBA 방식을 이용하여 인증을 요청할 수 있다.
동작 403에서, MSA(320)은 AA 서버(380)과 인증을 수행할 수 있다. 일 실시예에 따라, MSA(320)은 AA 서버(380)와 GPSI 기반 사용자 인증(user authentication)을 수행할 수 있다.
동작 405에서, AA 서버(380)은 전자 장치(101)로부터 인증 요청을 수신하는 경우, 전자 장치(101)와 인증을 수행하고, 인증을 완료(예: 인증 절차 완료)하는 경우, 인증 결과에 따른 인증 정보(예: 제1 인증 정보)를 전자 장치(101)(예: MSA(320))에 제공(또는 전송)할 수 있다. 일 실시예에 따르면, 인증 정보는, 예를 들어, MMP 관련 정보(이하, MMP Info라 한다) 및 권한 부여 코드(Authorization code)(이하, Auth Code라 한다)를 포함할 수 있다. 일 실시예에 따라, MMP 서버(370)은 상기의 정보 외에, 추가적으로(또는 선택적으로) 필요한 정보, 예를 들어, 인증을 위한 ID_token 또는 MEC 데이터 서비스를 위한 CARP 또는 URSP 규칙(rules) 중 적어도 하나를 인증 정보에 더 포함하여 제공할 수 있다.
일 실시예에 따라, MMP Info는, 예를 들어, MMP 서버(370) 접속에 관련된 정보(예: MMP 접속 주소)를 포함할 수 있다. 예를 들어, MMP Info는 접속할 새로운 MMP 서버(370)의 주소 정보(예: URI(uniform resource identifier) 또는 IP 주소)와 해당 주소 정보의 유효 시간 및/또는 장소에 관련된 정보를 포함할 수 있다. 일 실시예에 따라, Auth Code는, 예를 들어, MMP 서버(370)로부터 접속 토큰(예: MAT, MEC access token))을 요청하는 데 필요한 코드(예: OAuth2.0 기반)를 포함할 수 있다. 일 실시예에 따라, CARP 또는 URSP 규칙은, 예를 들어, PDU 세션 설정(PDU session setup)을 위한 관련 정보(예: DNN), DNN 별 사용 가능한 어플리케이션(또는 어플리케이션 그룹)에 관련된 정보, 또는 이후 설정 가능한 DNN 리스트(list) 또는 설정 가능한 DNN 최대 개수에 관련된 정보를 포함할 수 있다.
동작 407에서, MSA(320)은 AA 서버(380)과 인증 절차가 완료되면, MSE(330)과 정책 업데이트(policy update)를 수행(예: PDU 세션 설정(PDU session setup)) 할 수 있다. 일 실시예에 따라, MSA(320)은 CARP 규칙 또는 URSP 규칙(예: DNN)에 따라 PDU 세션 설정을 수행할 수 있다. 예를 들어, MSA(320)은 CARP 규칙 또는 URSP 규칙에 따라 PDU 세션 설정 수행 여부에 대한 정책을 식별할 수 있고, CARP 규칙 또는 URSP 규칙에 따라 MSE API를 통해 PDU 세션 설정 요청을 MSE(330)로 전달할 수 있다. MSE(330)은 MSA(320)의 PDU 세션 설정 요청에 대응하여, PDU 세션 설정을 수행할 수 있다. 일 실시예에 따르면, MSA(320)은 기본 PDU 세션을 변경하거나, 새로운 전용 PDU 세션을 추가로 형성(establishment)할 수 있다.
일 실시예에 따르면, 동작 407의 MSA(320)과 MSE(330)의 정책 업데이트 동작은, 예를 들어, MSA(320)이 AA 서버(380)로부터 CARP 또는 URSP 규칙(rule)이 제공되는 경우 수행할 수 있다. 일 실시예에 따르면, MSA(320)은 AA 서버(380)로부터 CARP 또는 URSP 규칙이 제공되지 않는 경우 MSE(330)과 정책 업데이트를 수행하지 않을 수도 있다. 다른 실시예에 따르면, MSA(320)은 AA 서버(380)로부터 CARP 또는 URSP 규칙이 제공되더라도 MSA(320)의 자체적인 판단 또는 MSE(330)과의 정보 교환을 통해 정책 업데이트를 수행하지 않을 수도 있다.
동작 409에서, MSA(320)은 인증 완료 후(또는 MSE(330)과 정책 업데이트 수행 또는 생략한 이후), 권한 부여(authorization)(예: 제2 인증) 요청(authorization request)을 위한 메시지(예: 제2 요청 메시지)를 MMP 서버(370)에 전송할 수 있다. 일 실시예에 따르면, MSA(320)은 AA 서버(380)로부터 획득된 인증 정보(예: Auth Code 또는 추가적으로 ID_token 포함)에 기반하여, MMP 서버(370)에 인증을 요청할 수 있다.
동작 411에서, MSA(320)은 MMP 서버(370)을 통해 AA 서버(380)과 인증(예: 권한 부여 절차)을 수행할 수 있다. 일 실시예에 따라, MSA(320)은 AA 서버(380)과 Auth Code에 기반하여 서비스 사용에 대한 권한 부여(service authorization)을 수행할 수 있다.
동작 413에서, MMP 서버(370)은 MSA(320)의 인증 요청(예: 제2 요청 메시지)에 대응하여, 인증 결과에 따른 인증 정보(예: 제2 인증 정보)를 전자 장치(101)(예: MSA(320))에 제공(또는 전송)할 수 있다. 일 실시예에 따르면, 인증 정보는, 예를 들어, 접속 토큰(예: MAT, MEC access Token)과 MMP Info를 포함할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 MSA(320)의 인증 수행 중 또는 수행 이후에 접속 토큰을 포함하는 응답을 MSA(320)에 전송할 수 있다.
동작 415에서, MSA(320)은 MSE(330)을 활성화 할 수 있다. 일 실시예에 따르면, MSA(320)은 AA 서버(380)과 인증 수행 중 또는 수행 후에, MMP 서버(370)로부터, 인증 결과에 따른 인증 정보(예: 접속 토큰(MAT))를 수신하는 경우, 수신된 인증 정보(예: 접속 토큰(MAT))를 MSE(330)에 전달하여 MSE(330)을 활성화 할 수 있다. 일 실시예에 따르면, MSA(320)은 인증 정보(예: 접속 토큰(MAT))와 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(370)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE(330)에 전달할 수 있다. 일 실시예에 따르면, MSA(320)은 수신된 접속 토큰(MAT) 및/또는 그 외의 다른 부가 정보에 기반하여 MSE(330)을 활성화(enable MEC)할 수 있다. 일 실시예에 따르면, MSA(320)이 MMP 서버(370)과 인증(예: 권한 부여)을 수행하는 경우, MSA(320)은 MMP 서버(370)로부터, 인증 결과로 접속 토큰(예: MAT)을 수신할 수 있으며, 예를 들어, MSE API의 enableMecEnablingLayer(true, MMP Info, MAT)를 호출함으로써, MSE(330)에 MMP 접속 정보(MMP Info) 및 접속 토큰(MAT)을 전달할 수 있다.
동작 417에서, MSE(330)은 인증 정보(예: MAT) 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)을 수신하고, 인증 정보 및/또는 부가 정보에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 MMP Info 및 MAT를 사용하여 해당 MMP 서버(370)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다.
도 4에서는 도시하지 않았으나, 다른 실시예에 따르면, MSE(330)이 MMP 서버(370)과 인증(예: 동작 411의 service authorization)을 수행할 수 있다. 일 실시예에 따르면, MSE(330)이 MMP 서버(380)과 인증(예: 권한 부여)을 수행하는 경우, 우선 인증을 완료한 MSA(320)이 MMP 서버(370)로부터, 인증 결과로 MMP Info와 Auth Code 및/또는 그 외의 다른 부가 정보(예: 식별 토큰(ID_token))을 수신할 수 있으며, 예를 들어, MSE(330) 활성화를 위해, MSE API의 enableMecEnablingLayer(true, MMP Info, Auth Code, [ID-Token])를 호출함으로써, MSE(330)에 전달할 수 있다. MSE(330)은 MSA(320)로부터 전달받은 정보로부터 MMP 서버(370)과 직접 권한 부여(Authorization)을 수행하고, 그 결과로 MAT를 수신(또는 획득)할 수 있다. 예를 들면, 도 4의 동작과 대비할 때, 전자 장치(101)의 내부 구성 중 권한 부여를 위한 서비스 인증 절차를 수행하는 주체가 MSA(320)인 경우와 MSE(330)인 경우로 구분될 수 있다.
도 5는 본 개시의 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 5에 도시한 바와 같이, 도 5은 다양한 실시예들에 따른 인증 절차(예: AA(authentication/authorization) 및 정책 업데이트(policy update)에 관한 시나리오 A)를 위한 신호 흐름의 예를 나타낼 수 있다. 예를 들어, 도 5은 다양한 실시예들에 따른 인증 절차 중 시나리오 A를 위한 MEC 서비스 인증 플로우의 예를 나타낸 것으로, User Authentication(또는 Subscriber Authentication)의 실시예에 따른 동작(예: 동작 510)과 MEC Service Authorization의 실시예에 따른 동작(예: 동작 520)을 포함할 수 있다. 일 실시예에 따르면, MEC AA 및 정책 업데이트를 위한 시나리오 A는, 도 5에 도시한 바와 같이, User Authentication(예: 동작 510) 이후에 MEC Service Authorization(예: 동작 520)을 수행하는 시나리오 예를 나타낼 수 있다.
도 5을 참조하면, 동작 501에서, 전자 장치(101)의 MSA(320)은 인증 요청을 위한 메시지를 인타이틀먼트(entitlement) 서버(500)로 전송할 수 있다.
동작 503에서, 인타이틀먼트 서버(500)은 인증 방식(authentication method)을 결정할 수 있다. 일 실시예에 따르면, 인타이틀먼트 서버(500)은 지정된 적어도 하나의 인증 방식에서 전자 장치(101)의 인증 요청에 대응하는 인증 방식을 결정할 수 있다. 일 실시예에 따라, 적어도 하나의 인증 방식은, 예를 들어, GPSI를 이용한 Application-layer AKA 또는 Login(예: ID/password) 방식의 인증(authentication)을 포함할 수 있다. 일 실시예에 따르면, MSA(320)이 가입자 식별 정보(또는 단말 식별 정보)(예: GPSI 또는 IMSI)를 인타이틀먼트 서버(500)에 전달하면서 권한 코드를 요청할 수 있다. 일 실시예에 따라, MSA(320)과 인타이틀먼트 서버(500)는, 동작 510에서와 같이, Application-layer AKA 또는 Loging 방식으로 사용자 인증(user authentication)을 수행할 수 있다.
일 실시예에 따르면, 동작 505에서, MSA(320)은 인타이틀먼트 서버(500)을 통해 AA 서버(380) 간에 Application-layer AKA 방식에 기반하여 인증(authentication)(예: MEC 가입자 인증) 절차를 수행하고, AA 서버(380)로부터 인증 결과에 따른 인증 정보를 포함하는 인증 응답(authentication response)을 획득할 수 있다. 다른 실시예에 따르면, 동작 507에서, MSA(320)은 인타이틀먼트 서버(500)과 ID/password 기반 Login 방식에 기반하여 인증(authentication) 절차를 수행하고, 동작 509에서, 인타이틀먼트 서버(500)에 로그인 성공(Login Success)에 기반하여 인타이틀먼트 서버(500)로부터 인증 결과에 따른 인증 정보를 포함하는 인증 응답을 획득할 수 있다.
동작 511에서, MSA(320)은 인증 요청에 대응하는 인증 응답(authentication response)을 수신할 수 있다. 예를 들어, 동작 511에서, MSA(320)은 인타이틀먼트 서버(500) 또는 인타이틀먼트 서버(500)을 통해 AA 서버(380)로부터 인증 결과에 따른 인증 정보(예: MMP Info, Auth Code, ID_token, CARP 규칙, 또는 URSP 규칙)를 획득할 수 있다. 예를 들어, MSA(320)은 인증 결과로 MEC 디스커버리 절차를 수행할 MMP 관련 정보(예: MMP 접속 주소)와 권한 부여(authorization)를 위한 권한 코드(예: Auth code) 및 ID_token을 수신할 수 있다. 일 실시예에 따르면, MSA(320)는, AA 서버(380)의 지원 여부에 기반하여, MEC 데이터 서비스를 위한 CARP 또는 URSP 규칙에 관련된 정보를 수신할 수도 있다.
일 실시예에 따르면, MSA(320)는, 동작 510에서와 같은 User Authentication 이후, 동작 520에서와 같이 MEC Service Authorization을 수행할 수 있다.
일 실시예에 따르면, 동작 513에서, MSA(320)은 인증 완료 후, 권한 부여(authorization) 요청(authorization request)을 위한 메시지를 MMP 서버(370)로 전송할 수 있다. 예를 들어, MSA(320)은 획득된 인증 정보(예: Auth Code 또는 추가적으로 ID_token 포함)를 MMP 서버(370)로 전달하여 MMP 서버(370)에 권한 부여를 요청할 수 있다. 예를 들어, MSA(320)은 인증 완료 후, MMP 접속 주소를 이용하여 MMP 서버(370)에 접속하여 권한 부여(authorization) 절차를 수행할 수 있다.
동작 515에서, MMP 서버(370)은 인타이틀먼트 서버(500)에 접속 토큰(access token)을 요청할 수 있고, 동작 517에서, 인타이틀먼트 서버(500)로부터 접속 토큰을 획득할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 인타이틀먼트 서버(500)과 통신 또는 인타이틀먼트 서버(500)을 통해 AA 서버(380)과 통신하여, 전자 장치(101)가 MEC 서비스 가입자인지 여부를 확인할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 AA 서버(380)을 통해 MEC 서비스 가입자임을 확인하면, MSA(320)에 접속 토큰(예: MAT)을 발행(예: 권한 부여(authorization))할 수 있다.
동작 519에서, MMP 서버(370)은 MMP 정보와 권한 코드를 인타이틀먼트 서버(500)(또는 AA 서버(380))에 전달하며, 사용자 프로필(user profile) 정보 접근을 위한 접속 토큰을 요청하여 획득할 수 있다.
동작 521에서, MMP 서버(370)은 권한 부여 요청에 대응하는 권한 부여 응답(authorization response)을 MSA(320)로 전송할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 해당 접속 토큰을 이용하여 사용자 프로필을 확인하고, 사용자 프로필에 기반하여 MEC 서비스가 가용하다는 것이 확인된 경우 MSA(320)에 MMP Info, MAT, 또는 CARP 규칙을 포함하여 Authorization response를 전달할 수 있다.
일 실시예에 따르면, 동작 521에서, MSA(320)은 권한 부여 절차의 결과로 접속 토큰(예: MAT)을 획득할 수 있다. 일 실시예에 따라, MSA(320)이 MMP 서버(370)과 권한 부여 절차를 수행하는 경우, MSA(320)은 권한 부여 절차의 결과로 접속 토큰을 수신하며, MSE API를 통해 MSE(330)로 MMP 정보 및 접속 토큰을 전달할 수 있다. 다른 실시예에 따라, MSE(330)이 MMP 서버(370)과 권한 부여 절차를 수행하는 경우, 우선 인증을 완료한 MSA(320)이 인타이틀먼트 서버(500)로부터 수신한 MMP 정보 및 권한 코드(Auth code)와, 선택적으로 ID_token을 MSE API를 통해 MSE(330)로 전달할 수 있다. MSE(330)은 MSA(320)로부터 전달된 정보에 기반하여 MMP 서버(370)과 직접 권한 부여 절차를 수행하고 그 결과로 접속 토큰을 수신할 수 있다.
동작 523에서, MSA(320)은 MSE(330)을 통해, MMP Info 및 접속 토큰을 이용하여 MEC 디스커버리 절차를 수행할 수 있다.
도 6은 본 개시의 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 6에 도시한 바와 같이, 전자 장치(101)는 MSA(또는 서비스 에이전트)(320)(예: AA 클라이언트(325) 포함)와 MSE(또는 서비스 인에이블러)(330)(예: MEL(331), UHL(333) 포함)를 포함할 수 있다.
도 6을 참조하면, 동작 601에서, 전자 장치(101)의 MSA(320)은 지정된 적어도 하나의 인증 방식에 기반하여 서비스 사용을 위한 권한 부여 요청(authorization request)을 위한 메시지(예: 권한 요청 메시지)를 MMP 서버(370)로 전송할 수 있다. 일 실시예에 따르면, MSA(320)은 MMP 서버(370)에 서비스 사용에 대한 권한 부여를 요청할 때, MNO(mobile network operator)(예: 인타이틀먼트 서버(500)) 정보와 Device ID(예: IMSI, IMEI, GPSI, 또는 별도 할당된 고유 식별자) 중 적어도 하나 또는 모두를 MMP 서버(370)로 제공(또는 전송)할 수 있다. 일 실시예에 따라, Device ID는 MMP 서버(370)이 전자 장치(101)를 고유하게(unique)하게 식별 가능한 식별자를 포함할 수 있다.
동작 603에서, MSA(320)은 MMP 서버(370) 또는 MMP 서버(370)을 통해 AA 서버(380)과 인증 및 권한 부여(예: AA, authentication & authorization) 절차를 수행할 수 있다. 예를 들어, MSA(320)은 MMP 서버(370)로 권한 부여 요청(authorization request)을 전달하면, MSA(320), MMP 서버(370), 및 AA 서버(380)의 3자 간 메시지 교환을 수행할 수 있다. 일 실시예에 따라, MSA(320)은 MMP 서버(370)과 사용자 인증(user authentication)과 서비스 인증(service authorization)(또는 권한 부여)을 수행할 수 있다. 예를 들어, MSA(320)은 전자 장치(101)가 등록되어 있는 사용자인지를 식별하는 절차를 수행하고, 해당하는 서비스를 제공받을 수 있는지를 식별하는 절차를 수행할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 MNO 정보에 따라 AA 방식이 다를 수 있으므로, MNO 정보에 따라 그에 맞는 방식을 사용하여 AA를 수행할 수 있다.
동작 605에서, MMP 서버(370)은 전자 장치(101)로부터 인증 요청을 수신하는 경우, 전자 장치(101)와 인증을 수행하고, 인증을 완료(예: 인증 절차 완료)하는 경우, 인증 결과에 따른 인증 정보를 전자 장치(101)(예: MSA(320))에 제공(또는 전송)할 수 있다. 일 실시예에 따르면, 인증 정보는, 예를 들어, MMP Info와 접속 토큰(예: MAT)을 포함할 수 있다. 일 실시예에 따라, MMP 서버(370)은 상기의 정보 외에, 추가적으로(또는 선택적으로) 필요한 정보, 예를 들어, MEC 데이터 서비스를 위한 CARP 또는 URSP 규칙(rules) 중 적어도 하나를 인증 정보에 더 포함하여 제공할 수 있다. 일 실시예에 따르면, 동작 605에서, MSA(320)은 인증 결과에 따른 인증 정보(예: MMP Info, MAT, 및 CARP 또는 URSP 규칙) 모두를 MMP 서버(370)로부터 수신할 수 있다. 다른 실시예에 따르면, 동작 605에서, MSA(320)은 인증 정보의 일부(예: 디스커버리를 위한 MMP Info, MAT)는 MMP 서버(370)로부터 수신하고, CARP 규칙(또는 URSP 규칙)은 사용자 인증(user authentication) 결과로서 AA 서버(380)로부터 수신할 수도 있다.
일 실시예에 따라, MMP Info는, 예를 들어, MMP 서버(370) 접속에 관련된 정보(예: MMP 접속 주소)를 포함할 수 있다. 예를 들어, MMP Info는 접속할 새로운 MMP 서버(370)의 주소 정보(예: URI(uniform resource identifier) 또는 IP 주소)와 해당 주소 정보의 유효 시간 및/또는 장소에 관련된 정보를 포함할 수 있다. 일 실시예에 따라, 접속 토큰(예: MAT)은, 예를 들어, MEC 디스커버리 권한 확인용 접속 토큰을 포함할 수 있다. 일 실시예에 따라, CARP 또는 URSP 규칙은, 예를 들어, DNN 구성(configuration) 관련 정보, DNN 별 사용 가능한 어플리케이션(또는 어플리케이션 그룹)에 관련된 정보, 또는 이후 설정 가능한 DNN 리스트(list) 또는 설정 가능한 DNN 최대 개수에 관련된 정보를 포함할 수 있다.
동작 607에서, MSA(320)은 인증 절차가 완료되면, MSE(330)과 정책 업데이트(policy update)를 수행(예: PDU 세션 설정(setup))할 수 있다. 일 실시예에 따라, MSA(320)은 CARP 또는 URSP 규칙(예: DNN)에 따라 초기 PDU 세션 설정을 수행할 수 있다. 예를 들어, MSA(320)은 MMP 서버(370)로부터 수신 정보에 URSP 규칙이 있는 경우, MSE API를 이용하여 URSP 규칙을 업데이트 할 수 있다.
일 실시예에 따르면, 동작 607의 MSA(320)과 MSE(330)의 정책 업데이트 동작은, 예를 들어, MSA(320)이 AA 서버(380)로부터 CARP 또는 URSP 규칙이 제공되는 경우 수행할 수 있다. 일 실시예에 따르면, MSA(320)은 AA 서버(380)로부터 CARP 또는 URSP 규칙이 제공되지 않는 경우 MSE(330)과 정책 업데이트를 수행하지 않을 수도 있다. 다른 실시예에 따르면, MSA(320)은 AA 서버(380)로부터 CARP 또는 URSP 규칙이 제공되더라도 MSA(320)의 자체적인 판단 또는 MSE(330)과의 정보 교환을 통해 정책 업데이트를 수행하지 않을 수도 있다.
동작 609에서, MSA(320)은 MSE(330)을 활성화 할 수 있다. 일 실시예에 따르면, MSA(320)은 AA 서버(380)과 인증 수행 중 또는 수행 후에, MMP 서버(370)로부터, 인증 결과에 따른 인증 정보(예: 접속 토큰(MAT))를 수신하는 경우, 수신된 인증 정보(예: 접속 토큰(MAT))를 MSE(330)에 전달하여 MES(330)을 활성화 할 수 있다. 일 실시예에 따르면, MSA(320)은 인증 정보(예: 접속 토큰(MAT))와 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(370)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE(330)에 전달할 수 있다. 일 실시예에 따르면, MSA(320)은 수신된 접속 토큰(MAT) 및/또는 그 외의 다른 부가 정보에 기반하여 MSE(330)을 활성화(enable MEC)할 수 있다. 일 실시예에 따르면, MSA(320)이 MMP 서버(370)과 인증을 수행하는 경우, MSA(320)은 MMP 서버(370)로부터, 인증 결과로 접속 토큰(예: MAT)을 수신할 수 있으며, 예를 들어, MSE API의 enableMecEnablingLayer(true, MMP Info, MAT)를 호출함으로써, MSE(330)에 MMP 접속 정보(MMP Info) 및 접속 토큰(MAT)을 전달할 수 있다.
동작 611에서, MSE(330)은 인증 정보(예: MAT) 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)을 수신하고, 인증 정보 및/또는 부가 정보에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 MMP Info 및 MAT를 사용하여 해당 MMP 서버(370)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다.
도 7은 본 개시에 따른 다양한 실시예들에 따른 인증 절차의 예를 도시하는 도면이다.
도 7에 도시한 바와 같이, 전자 장치(101)는 MSA(또는 서비스 에이전트)(320)(예: AA 클라이언트(325) 포함)와 MSE(또는 서비스 인에이블러)(330)(예: MEL(331), UHL(333) 포함)를 포함할 수 있다. 일 실시예에 따르면, AMF/PCF 서버(390)의 PCF에서 URSP를 추가하여 MMP 접속에 필요한 정보(예: MMP Info, Auth Code, 또는 ID_token)를 관리할 수 있다.
도 7를 참조하면, 동작 701에서, 전자 장치(101)의 MSE(330)은 AMF/PCF 서버(390)(예: AMF)와 NAS 시그널링(signaling) 절차를 수행할 수 있다. 일 실시예에 따라, AMF/PCF 서버(390)은 전자 장치(101)로 MMP Info, Auth Code를 제공할 수 있고, 추가적으로 ID_token 및/또는 CARP 또는 URSP 규칙을 제공할 수 있다. 일 실시예에 따르면, MSE(330)은 전자 장치(101)의 모뎀(또는 커뮤니케이션 프로세서)이 AMF(390)로부터 수신하는 NAS 시그널링 메시지를 MSE(330)의 UHL(333)을 통해 수신할 수 있다. 예를 들어, 전자 장치(101)의 모뎀은 AMF로부터 수신하는 NAS 시그널링 메시지로부터 MMP Info 및 Auth Code, ID_token, 또는 CARP 또는 URSP 규칙 중 적어도 하나의 정보를 획득하고, 획득된 정보를 UHL(333)을 통해 MSA(320)에 전달할 수 있다.
동작 703에서, MSE(330)은 NAS 시그널링 메시지로부터 MMP Info, Auth Code 및/또는 ID_token의 적어도 하나의 정보를 획득할 수 있고, 획득된 정보를 MSA(320)에 전달할 수 있다. 일 실시예에 따라, MMP Info는, 예를 들어, MMP 서버(370) 접속에 관련된 정보(예: MMP 접속 주소)를 포함할 수 있다. 예를 들어, MMP Info는 접속할 새로운 MMP 서버(370)의 주소 정보(예: URI(uniform resource identifier) 또는 IP 주소)와 해당 주소 정보의 유효 시간 및/또는 장소에 관련된 정보를 포함할 수 있다. 일 실시예에 따라, CARP 또는 URSP 규칙은, 예를 들어, DNN 구성(configuration) 관련 정보, DNN 별 사용 가능한 어플리케이션(또는 어플리케이션 그룹)에 관련된 정보, 또는 이후 설정 가능한 DNN 리스트(list) 또는 설정 가능한 DNN 최대 개수에 관련된 정보를 포함할 수 있다.
일 실시예에 따르면, AMF/PCF 서버(390)로부터 제공된 MMP Info, Auth Code, ID_token, 또는 CARP 또는 URSP 규칙 중 적어도 하나의 정보는 MSE(330)을 통해 MSA(320)에서 획득할 수도 있다.
동작 705에서, MSA(320)은 MSE(330)과 정책 업데이트(policy update)를 수행(예: PDU 세션 설정)할 수 있다. 일 실시예에 따라, MSA(320)은 CARP 또는 URSP 규칙(예: DNN)에 따라 PDU 세션 설정을 수행할 수 있다. 예를 들어, MSA(320)은 MMP 서버(370)로부터 수신 정보에 URSP 규칙이 있는 경우, MSE API를 이용하여 URSP 규칙을 업데이트 할 수 있다. 일 실시예에 따르면, MSA(320)은 NAS 시그널링 메시지를 통해 획득한 정보 중에 CARP 또는 URSP 규칙이 포함되어 있는 경우 MSE(330)과 정책 업데이트를 수행할 수 있다. 일 실시예에 따르면, MSA(320)은 NAS 시그널링 메시지를 통해 획득한 정보 중에 CARP 또는 URSP 규칙이 제공되지 않는 경우 MSE(330)과 정책 업데이트를 수행하지 않을 수도 있다. 다른 실시예에 따르면, MSA(320)은 CARP 또는 URSP 규칙이 제공되더라도 MSA(320)의 자체적인 판단 또는 MSE(330)과의 정보 교환을 통해 정책 업데이트를 수행하지 않을 수도 있다. 일 실시예에 따르면, MSA(320)과 MSE(330) 간 정책 업데이트 시에 PDU 세션 설정을 수행할 수 있다.
동작 707에서, MSA(320)은 NAS 시그널링 메시지를 수신한 후(또는 MSE(330)과 정책 업데이트 수행 또는 생략한 이후), 권한 부여(authorization) 요청(authorization request)(예: 서비스 사용 권한 요청)을 위한 메시지(예: 권한 요청 메시지)를 MMP 서버(370)에 전송할 수 있다. 일 실시예에 따르면, MSA(320)은 NAS 시그널링 메시지로부터 획득된 인증 정보(예: Auth Code 또는 추가적으로 ID_token 포함)에 기반하여, MMP 서버(370)에 서비스 사용에 대한 권한 부여를 요청할 수 있다.
동작 709에서, MSA(320)은 MMP 서버(370)을 통해 AA 서버(380)과 인증(예: 권한 부여 절차)을 수행할 수 있다. 일 실시예에 따라, MSA(320)은 AA 서버(380)과 Auth Code 또는 ID_token 중 적어도 하나 또는 모두를 MMP 서버(370)로 제공(또는 전송)하여, 서비스 사용에 대한 권한 부여(service Authorization)를 요청할 수 있다.
동작 711에서, MMP 서버(370)은 MSA(320)의 권한 부여 요청(예: 권한 요청 메시지)에 대응하여, 인증 정보를 전자 장치(101)(예: MSA(320))에 제공(또는 전송)할 수 있다. 일 실시예에 따르면, 인증 정보는, 예를 들어, 접속 토큰(예: MAT) 및 MMP Info를 포함할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 MSA(320)의 인증 수행 중 또는 수행 이후에 접속 토큰 및 MMP Info을 포함하는 응답을 MSA(320)에 전송할 수 있다.
동작 713에서, MSA(320)은 MSE(330)을 활성화 할 수 있다. 일 실시예에 따르면, MSA(320)은 MMP 서버(370)로부터, 인증 정보(예: 접속 토큰(MAT), MMP Info)를 수신하는 경우, 수신된 인증 정보(예: 접속 토큰(MAT), MMP Info)를 MSE(330)에 전달하여 MSE(330)을 활성화 할 수 있다. 일 실시예에 따르면, MSA(320)은 접속 토큰(MAT)과 함께, MEC 디스커버리 절차를 수행하기 위해 접속할 새로운 MMP 서버(370)의 접속 주소(예: URI 또는 IP 주소), DNS 서버 주소, 또는 사용할 DNN과 같은 적어도 하나의 부가 정보를 MSE(330)에 전달할 수 있다. 일 실시예에 따르면, MSA(320)은 수신된 접속 토큰(MAT) 및/또는 그 외의 다른 부가 정보에 기반하여 MSE(330)을 활성화(enable MEC)할 수 있다. 일 실시예에 따르면, MSA(320)이 MMP 서버(370)과 권한 부여 절차를 수행하는 경우, MSA(320)은 MMP 서버(370)로부터, 접속 토큰(예: MAT)을 수신할 수 있으며, 예를 들어, MSE API의 enableMecEnablingLayer(true, MMP Info, MAT)를 호출함으로써, MSE(330)에 MMP 접속 정보(MMP Info) 및 접속 토큰(MAT)을 전달할 수 있다.
동작 715에서, MSE(330)은 인증 정보(예: MAT) 및/또는 그 외의 다른 부가 정보(예: MMP Info, DNS 서버 주소, 또는 사용할 DNN)을 수신하고, 인증 정보 및/또는 부가 정보에 적어도 기반하여 MEC 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 MMP Info 및 MAT를 사용하여 해당 MMP 서버(370)에 접속 후 MEC 디스커버리 절차를 수행할 수 있다.
도 8은 본 개시의 다양한 실시예들에 따른 전자 장치(101)에서 정책 업데이트 동작 예를 도시하는 도면이다.
도 8에 도시한 바와 같이, 도 8은, 정책 업데이트(예: 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 정보) 변경)를 포함할 수 있으며, 도 8에서는 PDU 세션 생성 예를 나타낼 수 있다. 일 실시예에 따라, 전자 장치(101)는 MSA(또는 서비스 에이전트)(320), MSE(또는 서비스 인에이블러)(330), 및 모뎀(또는 CP, communication processor)(800)을 포함할 수 있다.
도 8을 참조하면, 동작 801에서, MSA(320)은 DNN 설정에 대한 정보를 획득(또는 수신)하는 경우 DNN을 설정하도록 지시하는 제1 메시지(예: setUrspDNN)를 MSE(330)로 제공(또는 전달)할 수 있다.
동작 803에서, MSE(330)은 MSA(320)로부터 제공된 제1 메시지(예: setUrspDNN)에 기반하여 DNN 정보를 업데이트(예: update DNN Info)할 수 있다.
동작 805에서, MSA(320)은 PDU 세션(또는 PDN 연결)을 생성하도록 지시하는 제2 메시지(예: requestPduSession)를 MSE(330)로 제공할 수 있다.
동작 807에서, MSE(330)은 제2 메시지(예: requestPduSession)를 수신하는 경우, 데이터 호(data call)를 설정하도록 지시하는 제3 메시지(예: setup data call)를 모뎀(800)로 제공할 수 있다.
동작 809에서, 모뎀(800)은 MSE(330)로부터 제3 메시지(예: setup data call)를 수신하면, 서비스(예: MEC 서비스)의 처리를 위한 미리 구성된 정보에 기반하여 데이터 호를 설정하거나, 또는 지시된 정보에 기반하여 데이터 호를 설정하고, MSE(320)로 제3 메시지에 대응하는 제4 메시지(예: 응답(Response) 메시지)를 제공할 수 있다. 일 실시예에 따르면, 모뎀(800)이 제3 메시지(예: setup data call)에 의해 코어 망(예: SMF - 도면에 미도시)에 PDU 세션 생성을 요청하는 것에 기반하여 PDU 세션이 생성될 수 있다.
동작 811에서, MSE(330)은 모뎀(800)로부터 제4 메시지(예: 데이터 호 설정 요청에 대응하는 응답)을 수신하는 경우, PDU 세션이 생성(establishment) 되었음을 통지하는 제5 메시지(예: onAvaible)를 MSA(320)로 제공할 수 있다.
동작 813에서, MSA(320)은 URSP 규칙이 앞서 설명한 방식들 중 어느 하나의 방식을 이용하여 수신되거나, 또는 그 밖의 다른 방식을 통해 수신되는 경우, URSP 규칙의 설정을 지시하는 제6 메시지(예: setUrspRules)를 MSE(330)로 제공할 수 있다. 일 실시예에 따르면, 동작 815에서, MSA(320)은 MEC 서비스 활성화 모드(예: MSE 활성화)를 실행(true)하도록 지시하는 제7 메시지(예: setMaServiceEnableMode(true))를 MSE(330)로 제공할 수 있다.
동작 817에서, MSE(330)은 MSA(320)로부터 수신된 제6 메시지(예: setUrspRules)와 제7 메시지(예: setMaServiceEnableMode(true))에 기반하여 라우팅 테이블(routing table)을 생성(또는 추가(add))할 수 있다. 일 실시예에 따르면, URSP 규칙에는 어플리케이션 별 또는 URI 별 사용 PDU 세션 정보를 포함할 수 있으며, 전자 장치(101)(예: MSE(330))는 URSP 규칙 상의 PDU 세션이 생성되어 있지 않은 경우, setUrspDNN API를 통해 PDU 세션을 생성할 수 있다. 일 실시예에 따라, 전자 장치(101)(예: MSE(330))는 PDU 세션 생성 시에, 해당 어플리케이션 ID(AppID) 또는 URI에 대한 데이터 경로를 URSP 규칙 상의 PDU 세션으로 설정되도록 setUrspRules API를 통해 라우팅 테이블을 설정할 수 있다.
도 9는 본 개시의 다양한 실시예들에 따른 전자 장치(101)에서 PDU 세션 설정 동작 예를 도시하는 도면이다.
도 9에 도시한 바와 같이, 도 9는, 정책 업데이트(예: PDU 세션 설정) 중 PDU 세션 해제(release)의 일 예를 나타낼 수 있으며, PDU 세션(또는 PDN 연결(PDN connection))을 해제(release)하기 위한 동작 예를 나타낼 수 있다. 일 실시예에 따르면, PDU 세션 설정(session setup)은 새로운 PDU 세션 생성(session establishment), 기존 PDU 세션 해제(session release), 및 기존 PDU 세션 업데이트(session update)(예: PDU 세션 별 특성에 대한 설정(예: bandwidth 또는 latency와 같은 QoS 정보) 변경)를 포함할 수 있으며, 도 8에서는 PDU 세션 해제 예를 나타낼 수 있다. 일 실시예에 따라, 전자 장치(101)는 MSA(또는 서비스 에이전트)(320), MSE(또는 서비스 인에이블러)(330), 및 모뎀(또는 CP, communication processor)(800)을 포함할 수 있다.
도 9를 참조하면, 동작 901에서, MSA(320)은 DNN 설정에 대한 정보의 설정을 해제해야 하는 경우, 해당하는 DNN을 해제하도록 지시하는 제1 메시지(예: setUrspDNN)를 MSE(330)로 제공(또는 전달)할 수 있다.
동작 903에서, MSE(330)은 MSA(320)로부터 제공된 제1 메시지(예: setUrspDNN)에 기반하여 데이터 호(data call)를 해제(release)하도록 지시하는 제2 메시지(예: Release data call)를 모뎀(1300)로 제공할 수 있다.
동작 905에서, 모뎀(800)은 MSE(330)로부터 제3 메시지(예: Release data call)를 수신하면, 해당하는 서비스(예: MEC 서비스)의 처리를 위해 설정된 구성을 해제하고, MSE(330)로 제3 메시지에 대응하는 제4 메시지(예: 응답(Response) 메시지)를 제공할 수 있다. 일 실시예에 따르면, 모뎀(800)이 제3 메시지(예: Release data call)에 의해 코어 망(예: SMF)에 PDU 세션 해제를 요청하는 것에 기반하여 PDU 세션이 해제될 수 있다.
동작 907에서, MSA(320)은 MEC 서비스 비활성화 모드(예: MSE 비활성화)를 실행(false)하도록 지시하는 제5 메시지(예: setMaServiceEnableMode(false))를 MSE(330)로 제공할 수 있다.
동작 909에서, MSE(330)은 MSA(320)로부터 수신된 제5 메시지(예: setMaServiceEnableMode(false))에 기반하여 메모리(예: 도 1 또는 도 2의 메모리(130))에 저장(또는 생성)된 라우팅 테이블을 메모리에서 삭제(delete)할 수 있다.
도 10은 본 개시의 다양한 실시예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 10에 도시한 바와 같이, 도 10은 어플리케이션 상태 기반(App state-based)의 MEC 디스커버리 절차의 예를 나타낼 수 있다. 일 실시예에 따르면, 전자 장치(101)는 클라이언트 어플리케이션(또는 Client App)(310), MSA(또는 서비스 에이전트)(320), MSE(또는 서비스 인에이블러)(330)(예: MEL(331), UHL(333) 포함), 및 DNS 캐시(cache)(1010)을 포함할 수 있다.
도 10을 참조하면, 동작 1001에서, 전자 장치(101)의 MSA(320)은 MSE(330)로 MEC 디스커버리 정책(discovery policy)을 설정할 수 있다. 일 실시예에 따르면, MEC 디스커버리 정책은 클라이언트 어플리케이션 이름(예: clientAppNames)과 디스커버리 정책(예: discoveryPolicy)을 포함하여 제공할 수 있다. 일 실시예에 따라, discoveryPolicy에는 동적 DNN(예: dynamicDnn)의 사용 여부가 포함될 수 있고, 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType), 또는 컨텍스트 타입(예: contextType)과 같은 정보 중 적어도 하나를 포함하여 제공할 수 있다. 일 실시예에 따르면, MSA(320)은 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType)을 discoveryPolicy에 포함하여 앱 리스트를 해당 조건에 맞는 리스트만 한정하여 수신하도록 할 수도 있다. 일 실시예에 따르면, MSA(320)은 컨텍스트 타입(예: contextType)을 discoveryPolicy에 포함하여 어플리케이션 컨텍스트(application context)가 필요한지 여부에 대한 정보를 포함할 수 있다. 일 실시예에 따르면, MSA(320)은 URI Request Flag를 discoveryPolicy에 포함하여 MEC 어플리케이션의 URI가 가용한 경우 앱 리스트에 URI 포함하도록 요청할 수도 있다. 일 실시예에 따라, 클라이언트 어플리케이션 이름(clientAppNames)은 MEC 사용 가능 여부를 확인하기 위한 앱 리스트를 요청하기 위한 정보일 수 있고, 위치(locationInfo)는 전자 장치(101)의 현재 위치에 따른 위치 기반 앱 리스트를 요청하기 위한 정보일 수 있고, 동적 DNN(dynamicDnn)은 동적 DNN 업데이트(dynamic DNN update) 사용 여부를 확인하기 위한 정보일 수 있다.
동작 1003에서, MSE(330)은 MSA(320)로부터 수신된 정보(예: MEC 디스커버리 정책)에 기반하여 앱 리스트(예: AppList)를 획득하기 위한 획득 절차(예: MEC Application Look-up)를 수행할 수 있다. 일 실시예에 따르면, MSA(320)과 MSE(330) 간에 MEC 디스커버리 정책 설정에 따라 앱 리스트를 획득하기 위한 획득 절차(예: MEC Application Look-up)가 시작될 수 있다. 일 실시예에 따르면, MSE(330)은 MSA(320)로부터 MSE API를 통해 MEC 디스커버리 정책을 수신하는 경우 MEC Application Look-up을 활성화 할 수 있고, 전자 장치(101)의 특정 조건(예: 전자 장치(101)가 움직이는 중 접속 기지국 Cell ID 변경) 만족 시 수행(또는 시작)할 수 있다. 일 실시예에 따르면, MSE(330)은 MEC 디스커버리 정책에 따라 서비스 가능한 MEC 어플리케이션(예: MEP App)에 관련된 앱 리스트(예: MEC AppList)를 MMP 서버(370)로 요청하여 수신할 수 있다. 일 실시예에 따르면, MSE(330)은 MEC 디스커버리 정책을 <표 1>에 예시한 바와 같은 MEC AppList request message Parameter에 기입하여 MMP 서버(370)에 요청할 수 있고, MMP 서버(370)은 그에 맞는 서비스 가능 앱 리스트를 MSE(330)로 제공하여, MSE(330)의 요청에 응답할 수 있다.
동작 1005에서, 클라이언트 어플리케이션(310)은 MSA(320)로 App Launch Detected 또는 API(Context Create) call을 제공(또는 전달)할 수 있다. 일 실시예에 따르면, App Launch Detected의 경우는 클라이언트 어플리케이션(310)이 실행되는 경우를 나타낼 수 있다. 일 실시예에 따르면, API(Context Create) call은 접속하고자 하는 MEC 어플리케이션 이름(예: MEC App Name)에 대한 URI를 요청하는 경우를 나타낼 수 있다.
동작 1007에서, MSA(320)은 App Launch Detected 또는 API(Context Create) call를 수신하면, 클라이언트 어플리케이션(310)의 상태(state)를 통지(notify)하는 통지 메시지(예: notifyClientAppState)를 MSE(330)로 제공할 수 있다. 일 실시예에 따라, 통지 메시지(예: notifyClientAppState)는, 예를 들어, 클라이언트 어플리케이션의 상태(예: START)와 클라이언트 어플리케이션의 이름(예: clientAppName)(및/또는 UID)을 포함(예: notifyClientAppState(START, clientAppName))하여 제공할 수 있다.
동작 1009에서, MSE(330)은 MSA(320)로부터 통지 메시지(예: notifyClientAppState)를 수신하고, 수신된 통지 메시지에 기반하여 MEC 어플리케이션(또는 해당 MEC 어플리케이션을 포함하는 MEC 호스트(예: 엣지 서버 또는 MEC 서버))을 발견(또는 탐색, 확인)하기 위한 절차(예: 어플리케이션 컨텍스트 생성(application context create))를 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 MSA(320)로부터 클라이언트 어플리케이션(310)의 실행과 관련된 이벤트(event)를 수신하는 경우 어플리케이션 컨텍스트 생성을 활성화 할 수 있다. 일 실시예에 따르면, MSE(330)은 수신된 통지 메시지(예: notifyClientAppState)의 정보에 기반하여 MMP 서버(370)을 통해 원하는 MEC 어플리케이션을 포함하는 MEC 호스트를 찾기 위한 어플리케이션 컨텍스트 생성 동작을 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, MSA(320)이 클라이언트 어플리케이션(310) 실행을 감지하는 경우 MSE API 호출에 의하여 활성화(또는 수행)될 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, 클라이언트 어플리케이션(310)이 컨텍스트 생성(context create) API 호출 시에 활성화(또는 수행)될 수 있다. 일 실시예에 따르면, MSE(330)은 접속하고자 하는 MEC 어플리케이션 이름(예: MEC App Name)에 대한 URI를 MMP 서버(370)로 요청 및 수신할 수 있다. 일 실시예에 따라, MSE(330)은 필요에 따라 전용 DNN(dedicated DNN)에 대한 정보를 MMP 서버(370)에 요청 및 수신할 수도 있다. 일 실시예에 따르면, MMP 서버(370)은 해당 MEC 어플리케이션이 없는 경우에는 MEC 어플리케이션 패키지(package) URI를 MSE(330)로 전달할 수도 있다. 다양한 실시예들에 따른 어플리케이션 컨텍스트 생성 절차에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 1011에서, MSE(330)은 DNS 서버(1020)과 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 MMP 서버(370)을 통해 획득한 MEC 호스트가 적어도 둘 이상인 경우, DNS 서버(1020)과 어느 하나의 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, MEC 호스트가 둘 이상인 경우 하나의 MEC 호스트를 선택하기 위한 호스트 선택 절차는 미리 설정된 정보 및/또는 DNS 서버(1020)로 문의한 정보를 이용하여 결정하거나, 또는 DNS 서버(1020)로 문의한 정보 및/또는 사용자에게 문의하여 특정한 MEC 호스트를 선택(또는 설정)하도록 할 수 있다. 일 실시예에 따르면, MSE(330)가, MEC 호스트가 둘 이상인 경우 특정한 MEC 호스트를 설정하기 위한 미리 설정된 정보는 우선순위 정보를 포함할 수 있다. 일 실시예에 따르면, 호스트 선택 절차는 DNS 프리 리졸빙(Pre-resolving) 동작과 MEC 호스트 우선순위 결정(MEC Host Prioritization) 동작을 포함할 수 있다. 일 실시예에 따라, DNS Pre-resolving는, 예를 들어, 클라이언트 어플리케이션(310)의 DNS 쿼리(query)와 상관 없이 MSE(330) 자체적으로 MEC용 FQDN((fully qualified domain name))에 대해 DNS 리졸빙을 수행하는 것을 포함할 수 있다. 일 실시예에 따라, DNS 리졸빙은, 동작 1003의 Get App List 단계 또는 동작 1009의 Find Cloudlet 단계를 통해 수신한 URI 또는 도메인 이름(domain name)이 사용하여 수행될 수 있다. 일 실시예에 따라, MEC Host Prioritization는, 예를 들어, DNS 쿼리 응답(query response)으로 복수 개의 IP 주소가 수신되는 경우 IP 우선순위를 설정하는 것을 포함할 수 있다. 다양한 실시예들에 따른 호스트 선택 절차(예: MEC Host Selection)에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 1013에서, 클라이언트 어플리케이션(310)은 이상의 동작을 통해 획득한 정보를 이용하여 DNS 리졸빙(Resolving) 동작을 수행할 수 있다. 일 실시예에 따르면, DNS 리졸빙은, 예를 들어, 클라이언트 어플리케이션(310)의 DNS 쿼리 발생 시 수행할 수 있다. 일 실시예에 따르면, DNS 리졸빙은, 예를 들어, Client-driven normal DNS resolving 또는 DNS proxying (hooking DNS query)를 포함할 수 있다. 다양한 실시예들에 따른 DNS 리졸빙에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
도 11은 본 개시의 다양한 실시예들에 따른 디스커버리 절차의 예를 도시하는 도면이다.
도 11에 도시한 바와 같이, 도 11은 DNS 쿼리 기반(DNS Query-based)의 MEC 디스커버리 절차의 예를 나타낼 수 있다. 일 실시예에 따르면, 전자 장치(101)는 클라이언트 어플리케이션(또는 Client App)(310), MSA(또는 서비스 에이전트)(320), MSE(또는 서비스 인에이블러)(330)(예: MEL(331), UHL(333) 포함), 및 DNS 캐시(cache)(1010)을 포함할 수 있다.
도 11을 참조하면, 동작 1101에서, 전자 장치(101)의 MSA(320)은 MSE(330)로 MEC 디스커버리 정책(discovery policy)을 설정할 수 있다. 일 실시예에 따르면, MEC 디스커버리 정책은 클라이언트 어플리케이션 이름(예: clientAppNames)과 디스커버리 정책(예: discoveryPolicy)을 포함하여 제공할 수 있다. 일 실시예에 따라, discoveryPolicy에는 동적 DNN(예: dynamicDnn)의 사용 여부가 포함될 수 있고, 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType), 또는 컨텍스트 타입(예: contextType)과 같은 정보 중 적어도 하나를 포함하여 제공할 수 있다. 일 실시예에 따르면, MSA(320)은 위치(예: locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType)을 discoveryPolicy에 포함하여 앱 리스트를 해당 조건에 맞는 리스트만 한정하여 수신하도록 할 수도 있다. 일 실시예에 따르면, MSA(320)은 컨텍스트 타입(예: contextType)을 discoveryPolicy에 포함하여 어플리케이션 컨텍스트(application context)가 필요한지 여부에 대한 정보를 포함할 수 있다. 일 실시예에 따르면, MSA(320)은 URI Request Flag를 discoveryPolicy에 포함하여 MEC 어플리케이션의 URI가 가용한 경우 앱 리스트에 URI 포함하도록 요청할 수도 있다.
동작 1103에서, MSE(330)은 MSA(320)로부터 수신된 정보(예: MEC 디스커버리 정책)에 기반하여 앱 리스트(예: AppList)를 획득하기 위한 획득 절차(예: MEC Application Look-up, Get App List)를 수행할 수 있다. 일 실시예에 따르면, MSA(320)과 MSE(330) 간에 MEC 디스커버리 정책 설정에 따라 앱 리스트를 획득하기 위한 획득 절차(예: MEC Application Look-up, Get App List)가 시작될 수 있다. 일 실시예에 따르면, MSE(330)은 MSA(320)로부터 MSE API를 통해 MEC 디스커버리 정책을 수신하는 경우 MEC Application Look-up을 활성화 할 수 있고, 전자 장치(101)의 특정 조건(예: 전자 장치(101)가 움직이는 중 접속 기지국 Cell ID 변경) 만족 시 수행(또는 시작)할 수 있다. 일 실시예에 따르면, MSE(330)은 MEC 디스커버리 정책에 따라 서비스 가능한 MEC 어플리케이션(예: MEP App)에 관련된 앱 리스트(예: MEC AppList)를 MMP 서버(370)로 요청하여 수신할 수 있다. 일 실시예에 따르면, MSE(330)은 MEC 디스커버리 정책을 MEC AppList request message Parameter에 기입하여 MMP 서버(370)에 요청할 수 있고, MMP 서버(370)은 그에 맞는 서비스 가능 앱 리스트를 MSE(330)로 제공하여, MSE(330)의 요청에 응답할 수 있다.
동작 1105에서, 클라이언트 어플리케이션(310)은 MSE(330)로 DNS 쿼리(query)를 위한 메시지(예: DNS query 메시지)를 전달할 수 있다.
동작 1107에서, MSE(330)은 클라이언트 어플리케이션(310)로부터의 DNS 쿼리에 응답하여 MMP 서버(370)과 Find Cloudlet 동작을 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 클라이언트 어플리케이션(310)에서 DNS query (with FQDN) 메시지 발생 시, FQDN 필터링(filtering)을 통해 MEC 용 FQDN 탐지 시, 해당 MEC 어플리케이션(예: MEC App)에 대한 Find Cloudlet를 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 접속하고자 하는 MEC 어플리케이션 이름(예: MEC App Name)에 대한 URI를 MMP 서버(370)로 요청 및 수신할 수 있다. 일 실시예에 따라, MSE(330)은 필요에 따라 전용 DNN(dedicated DNN)에 대한 정보를 MMP 서버(370)에 요청 및 수신할 수도 있다. 일 실시예에 따르면, MMP 서버(370)은 해당 MEC 어플리케이션이 없는 경우에는 MEC 어플리케이션 패키지(package) URI를 MSE(330)로 전달할 수도 있다.
동작 1109에서, MSE(330)은 클라이언트 어플리케이션(310)로부터의 DNS 쿼리에 응답하여 DNS 서버(1020)과 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 MMP 서버(370)을 통해 획득한 MEC 호스트가 적어도 둘 이상인 경우, DNS 서버(1020)과 어느 하나의 MEC 호스트를 선택하기 위한 호스트 선택 절차(예: MEC Host Selection)를 수행할 수 있다. 일 실시예에 따르면, MEC 호스트가 둘 이상인 경우 하나의 MEC 호스트를 선택하기 위한 호스트 선택 절차는 미리 설정된 정보 및/또는 DNS 서버(1020)로 요청하여 수신한 정보(예: IP 주소, IP 별 location 정보)를 이용하여 결정하거나, 또는 DNS 서버(1020)로 요청하여 수신한 정보 및/또는 사용자에게 UI(user interface)(예: 선택 버튼)를 통하여 특정한 MEC 호스트를 선택(또는 설정)하도록 할 수 있다. 일 실시예에 따르면, MSE(330)가, MEC 호스트가 둘 이상인 경우 특정한 MEC 호스트를 설정하기 위한 미리 설정된 정보는 우선순위 정보를 포함할 수 있다. 일 실시예에 따르면, 우선순위 정보는, 예를 들어, 호스트 우선순위가 URI 별로 우선순위가 결정된 정보를 포함하거나, 또는 하나의 URI를 DNS 리졸빙(resolving)한 결과인 IP 주소가 복수 개일 경우 해당 IP 주소 별 우선순위가 결정된 정보를 포함할 수 있다. 일 실시예에 따르면, 호스트 선택 절차는 DNS 리졸빙(resolving) 동작과 MEC 호스트 우선순위 결정(MEC Host Prioritization) 동작을 포함할 수 있다. 일 실시예에 따라, DNS resolving는, 예를 들어, 클라이언트 어플리케이션(310)의 DNS 쿼리(query)와 상관 없이 MSE(330) 자체적으로 MEC용 FQDN에 대해 DNS 리졸빙을 수행하는 것을 포함할 수 있다. 일 실시예에 따라, MEC Host Prioritization는, 예를 들어, DNS 쿼리 응답(query response)으로 복수 개의 IP 주소가 수신되는 경우 IP 우선순위를 설정하는 것을 포함할 수 있다. 일 실시예에 따라, 우선순위가 URI 별 또는 IP 별 미리 정해져 있을 수 있으며, 복수 개의 IP 주소가 수신되는 경우에는 수신된 복수의 IP 별 성능(performance) 테스트를 통해 그 결과에 따라 동적으로 IP 우선순위를 결정할 수도 있다. 다양한 실시예들에 따른 호스트 선택 절차(예: MEC Host Selection)에 대하여 후술하는 도면을 참조하여 상세히 설명된다.
동작 1111에서, MSE(330)은 이상의 절차들이 완료되면, 클라이언트 어플리케이션(310)로 이상의 절차들을 통해 획득한 정보를 DNS 응답(Response)으로 제공할 수 있다. 일 실시예에 따르면, MSE(330)은 MEC 호스트 선택((예: DNS 리졸빙) 후, DNS 쿼리를 제공한 클라이언트 어플리케이션(310)으로, DNS 쿼리에 대응하는 DNS 응답(response)을 전달할 수 있다. 다양한 실시예들에 따른 DNS 응답에 대하여 후술하는 도면을 참조하여 설명된다.
도 12는 본 개시의 다양한 실시예들에 따른 디스커버리 절차에서 앱 리스트를 획득하는 동작 예를 도시하는 도면이다.
도 12에 도시한 바와 같이, 도 12는 일 실시예에 따른 MEC 디스커버리 절차에서 앱 리스트 생성 및 획득(예: MEC Application Look-up)에 관한 동작 예를 나타낼 수 있다.
도 12를 참조하면, 동작 1201에서, 전자 장치(101)의 MSA(320)은 MSE(330)로 MEC 디스커버리 정책(discovery policy)을 전달할 수 있다. 일 실시예에 따르면, MEC 서비스 모듈(410)은 MSA(320)을 이용하여 MEC 디스커버리 정책을 획득하고, MSE(330)을 이용하여 수신된 MEC 디스커버리 정책에 기반한 디스커버리 절차를 수행할 수 있다. 일 실시예에 따르면, MEC 디스커버리 정책은 클라이언트 어플리케이션 이름(예: clientAppNames), 위치(locationInfo), 디바이스 타입(예: deviceType), 서비스 타입(예: serviceType), 컨텍스트 타입(예: contextType), URI 요청 플래그(예: URI Request), 또는 동적 DNN(예: dynamicDnn) 중 적어도 하나를 포함하여 제공할 수 있다.
동작 1203에서, MSE(330)은 MSA(320)로부터 수신된 정보(예: MEC 디스커버리 정책)에 기반하여 앱 리스트(예: AppList)를 획득하기 위한 획득 절차(예: MEC Application Look-up)를 수행할 수 있다. 일 실시예에 따르면, 앱 리스트를 획득하는 동작은 MSA(320)과 MSE(330) 간에 MEC 디스커버리 정책 설정에 따라 시작될 수 있다. 일 실시예에 따르면, 앱 리스트 획득 절차는 MSA(320)에서 MEC 디스커버리 정책 API 호출 시 활성화될 수 있고, MEC 디스커버리 정책에 부합하는 MEC 앱 리스트 및/또는 URI를 MMP 서버(370)로 요청하여 수신할 수 있다. 일 실시예에 따르면, 앱 리스트 획득 절차는, 동작 1210, 동작 1220을 포함할 수 있다.
동작 1210에서, MSE(330)은 앱 리스트를 요청하는 요청 메시지(예: HTTP Get AppList Request Parameters)를 MMP 서버(370)로 전송할 수 있다. 일 실시예에 따르면, MSE(330)은 MEC 디스커버리 정책을 요청 메시지(예: HTTP Get AppList Request Parameters)에 포함(또는 기입)하여 MMP 서버(370)로 제공할 수 있다. 예를 들어, MSE(330)은 앱 리스트 요청 파라미터를 포함하여 MMP 서버(370)로 제공할 수 있다.
일 실시예에 따르면, Request Parameter에 지원 가능한 필드(field) 정보는 인증(AA) 단계에서 Authorization Response 내 MMP Info에 정의할 수 있다. 일 실시예에 따르면, 앱 리스트 요청과 관련된 파라미터(또는 정보)(예: AppList Request Parameters)는 요청 메시지(예: HTTP GET)의 파라미터 필드(parameter field)에 포함될 수 있다. 일 실시예에 따르면, 앱 리스트 요청 파라미터는, MSA(320)로부터 전달 받은(예: 동작 1201의 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 서버(370)로 전달할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 전자 장치(101)에 설치된 어플리케이션 정보의 변경(예: 업데이트)이 있는 경우, MMP 서버(370)에 앱 리스트를 요청하는 절차에서, 전자 장치(101)에 설치된 어플리케이션 정보를 전달할 수도 있다.
동작 1220에서, MMP 서버(370)은 MSE(330)로부터 수신된 요청 메시지에 대응하는 응답으로 앱 리스트(예: MEC AppList)를 포함하는 응답 메시지(예: HTTP 200 OK AppList response Data)를 MSE(330)로 제공할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 수신된 클라이언트 어플리케이션 이름에 기반하여 MEC 어플리케이션을 검색하고, 검색된 MEC 어플리케이션을 포함하는 앱 리스트를 응답 메시지에 포함하여 MSE(330)로 제공할 수 있다.
일 실시예에 따르면, 앱 리스트 응답과 관련된 데이터(또는 정보)(예: AppList Response Data)는 응답 메시지(예: HTTP 200 OK)의 메시지 바디(message body)에 포함될 수 있다.
일 실시예에 따르면, MMP 서버(370)은 앱 리스트를 제공할 때, 가용한 전체 MEC App List 또는 Request Parameters 중 적어도 하나에 기반하여 서비스 가능한 MEC App List를 제공할 수 있다. 일 실시예에 따르면, 클라이언트 어플리케이션(Client App) 별 접속 가능한 MEC App Name을 포함할 수 있으며, MEC App Name은 이후 Application Context Create 동작에서 사용(또는 필요)할 수 있다.
일 실시예에 따르면, MMP 서버(370)은 오퍼레이터의 위치 API(Operator’s Location API)가 가용한 경우 알림을 앱 리스트에 포함하여 제공할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 요청 메시지에서, URI Request Flag가 true이고, 전자 장치(101)(예: 사용자 단말) 근처의 가용 MEC 호스트에 해당 MEC App이 실행 중일 경우, 해당 MEC App의 URI를 앱 리스트에 포함하여 제공할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 요청 메시지에서, URI 요청 플래그(URI Request Flag)가 없는 경우에서도, MEC 호스트에 해당 MEC App이 실행 중일 경우, 해당 MEC App의 URI를 앱 리스트에 포함하여 제공할 수도 있다. 일 실시예에 따르면, MMP 서버(370)은 전자 장치(101)로부터 앱 리스트 요청 수신 시, 요청 메시지에서, 컨텍스트 타입에 따라 MEC App이 바로 구동이 가능한 경우 MEC App을 구동한 후 해당 URI를 앱 리스트에 포함하여 제공할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 URI의 유효시간/유효 장소 정보를 앱 리스트에 더 포함하여 제공할 수 있다. 일 실시예에 다르면, URI의 유효시간에 대한 정보는 전자 장치(101)가 결정할 수도 있고, 또는 MMP 서버(370)에서 MEC App 구동 상태에 따라 가변적으로 결정할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 어플리케이션 별 전용 DNN 규칙이 존재하는 경우, 해당 규칙을 제공할 수도 있다.
일 실시예에 따르면, 앱 리스트에 포함된 URI는 하이퍼링크 및/또는 하이라이트 되어 구분될 수 있고, 전자 장치(101)는 앱 리스트에서, URI를 포함하지 않는 MEC App과 하이퍼링크 및/또는 하이라이트에 기반하여 구분하여 표시할 수 있다. 다른 실시예에 따르면, 전자 장치(101)는 앱 리스트에서, URI를 포함하는 MEC App과 URI를 포함하지 않은 MEC App을 구분하지 않고 동일하게 표시할 수도 있다. 일 실시예에 따르면, 전자 장치(101)는 앱 리스트에서, 어플리케이션 별 서비스 가능한 위치 및/또는 시간 정보를 포함하여 제공할 수도 있다.
일 실시예에 따르면, MMP 서버(370)은 앱 리스트를 응답하는 절차에서, 어플리케이션 단위로 DNN 설정이 가능한 경우, 앱 리스트에 어플리케이션 별(또는 앱 별) 사용 DNN 정보를 포함할 수 있다. 일 실시예에 따라, 해당 DNN 서버는, 인증(AA) 정차에서 수신된 DNN 리스트에 포함된 DNN일 수 있다.
일 실시예에 따르면, 전자 장치(101)는 MMP 서버(370)에 앱 리스트를 요청하고, 그에 대한 응답을 수신하는 절차에서, 앱 리스트 및 앱 리스트의 해당 어플리케이션(들)에 대한 MEC 호스트(예: 엣지 서버 또는 MEC 서버)에 대한 정보(예: URI)를 획득(또는 수신)할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 호스트에 대한 정보(예: URI)를 수신하지 않은 경우, 예를 들어, 해당 앱에 대해, Application Context Create 절차를 더 수행하여, 해당 어플리케이션에 대한 MEC 호스트의 정보(예: URI)를 외부 서버로부터 획득할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 호스트에 대한 정보(예: URI)를 수신한 경우, 예를 들어, 해당 어플리케이션에 대해, Application Context Create 절차를 수행하지 않고, 바로 해당 MEC 호스트(예: URI를 사용하여)로 접속을 수행할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 MMP 서버(370)에 앱 리스트를 요청하고, 그에 대한 응답을 수신하는 절차에서, 앱 리스트 및 앱 리스트의 해당 어플리케이션(들)에 대한 지정된 네트워킹 경로에 대한 정보(예: DNN)를 수신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 지정된 네트워킹 경로에 대한 정보(예: DNN)를 수신한 경우, 네트워크와 지정된 네트워킹 경로를 설정하는 절차를 수행할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 DNN 정보를 수신한 어플리케이션들에 대해서만 지정된(또는 전용) DNN(dedicated DNN)으로 통신하도록 DNN 경로를 설정할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 MEC 호스트에 컨텍스트를 생성 요청하는 절차(예: Application Context Create)에서, DNN 정보를 수신한 어플리케이션들에 대해 지정된 DNN 경로를 설정할 수 있다.
도 13은 본 개시의 다양한 실시예들에 따른 앱 리스트가 제공되는 예를 설명하기 위한 도면이다.
도 13에 도시한 바와 같이, 도 13은 위치 기반 서비스 영역(Location-based Service Area)을 예시할 수 있다.
도 13을 참조하면, 일 실시예에 따라, MMP 서버(370)은 제1 서버(Server 1)(1310)(또는 사용자 인접의 제1 MEC 호스트)로부터 가능한 어플리케이션(Available Apps)에 대한 제1 정보(예: A(+URI), B, C)를 획득하는 것을 가정할 수 있다. 일 실시예에 따라, MMP 서버(370)은 제2 서버(Server 2)(1320)(또는 사용자 인접의 제2 MEC 호스트)로부터 가능한 어플리케이션에 대한 제2 정보(예: A, C(+URI), D)를 획득하는 것을 가정할 수 있다.
다양한 실시예들에 따르면, MMP 서버(370)은 제1 서버(1310)과 제2 서버(1320)로부터 획득한 각각의 어플리케이션에 대한 정보들(예: 제1 정보, 제2 정보)을 취합하여, 예를 들어, A(+URI), B, C(+URI), D의 정보를 생성(또는 획득)할 수 있다. 일 실시예에 따르면, MMP 서버(370)은 제1 서버(1310)과 제2 서버(1320)로부터 생성된 A(+URI), B, C(+URI), D를 포함하여 앱 리스트를 생성하고, 생성된 앱 리스트를 사용자(1330)(예: 전자 장치(101))에 제공할 수 있다.
도 14는 본 개시의 다양한 실시예들에 따른 디스커버리 절차에서 컨텍스트 생성 절차의 예를 도시하는 도면이다.
도 14에 도시한 바와 같이, 도 14는 일 실시예에 따른 MEC 디스커버리 절차에서 어플리케이션 컨텍스트 생성(예: Application Context Create)에 관한 동작 예를 나타낼 수 있다. 일 실시예에 따라, 어플리케이션 컨텍스트 생성 절차는, 예를 들면, 클라이언트 어플리케이션(310)이 실행되는 경우, MSA(320)이 해당 클라이언트 어플리케이션에 관련된 정보(예: 패키지 이름 또는 UID)와 함께 어플리케이션 시작 정보를 MSE API를 통해 MSE(330)에 전달하는 것으로부터 수행될 수 있다. 다양한 실시예들에 따르면, 어플리케이션 컨텍스트 생성은, 앱 리스트 상의 어플리케이션이 실행(launch)되거나(제1 케이스), 어플리케이션이 MSE API를 통해 컨텍스트 생성(contextcreate)을 요청(예: context create API 호출)하거나(제2 케이스), 또는 어플리케이션에서 DNS 쿼리 전송 시 미리 수신한 앱 리스트에 포함된 어플리케이션 이름 및/또는 URI(예: FQDN)와 매칭이 되는 경우(제3 케이스)에 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성은, 예를 들어, MEC 디스커버리 정책(예: setDiscoveryPolicy(discoveryPolicy))을 통해 전달된 위치 정보 또는 어플리케이션 룩업 응답을 통해 전달된 앱 리스트에 포함된 어플리케이션 별 가용 위치(예: uriLOC)가 현재 사용자(또는 전자 장치(101))의 위치와 매칭되는 경우(예: 제4 케이스)에도 수행할 수 있다. 다양한 실시예들에 따르면, 제1 케이스, 제2 케이스, 제3 케이스, 또는 제4 케이스에 따른 조건 중 적어도 하나가 만족할 때 어플리케이션 컨텍스트 생성을 수행할 수 있다. 도 14에서는 제1 케이스에 따라 어플리케이션 컨텍스트 생성을 수행하는 동작 예를 나타낼 수 있다.
도 14을 참조하면, 동작 1401에서, 특정 클라이언트 어플리케이션(310)이 실행되는(launched) 경우, 해당 클라이언트 어플리케이션(310)은 어플리케이션의 실행을 알리는 정보(예: App Launched)를 MSA(320)로 제공할 수 있다. 일 실시예에 따르면, 동작 1401은 수행하지 않을 수도 있다. 예를 들어, 클라이언트 어플리케이션(310)이 실행되는 경우, 클라이언트 어플리케이션(310)에 의한 실행을 알리는 동작 없이, MSA(320)(예: Framework level)에서 자체적으로 클라이언트 어플리케이션(310)의 실행을 감지할 수 있다.
동작 1403에서, MSA(320)은 클라이언트 어플리케이션(310)의 실행을 알리는 정보(예: App Launched)를 수신하면, 클라이언트 어플리케이션(310)의 상태(state)를 통지(notify)하는 통지 메시지(예: notifyClientAppState)를 MSE(330)로 제공할 수 있다. 일 실시예에 따라, 통지 메시지(예: notifyClientAppState)는, 예를 들어, 클라이언트 어플리케이션의 상태(예: START)와 클라이언트 어플리케이션의 이름(예: clientAppName)(및/또는 UID)을 포함(예: notifyClientAppState(START, clientAppName))하여 제공할 수 있다.
동작 1405에서, MSE(330)은 MSA(320)로부터 통지 메시지(예: notifyClientAppState)를 수신하고, 수신된 통지 메시지의 정보에 기반하여 어플리케이션 컨텍스트 생성 절차를 수행할 수 있다. 일 실시예에 따르면, 어플리케이션 컨텍스트 생성 절차(동작 1405)는, 동작 1410, 동작 1420, 동작 1430을 포함할 수 있다.
동작 1410에서, MSE(330)은 어플리케이션 컨텍스트 생성을 요청하는 요청 메시지(예: HTTP POST AppContext Data)를 MMP 서버(370)로 전송할 수 있다. 일 실시예에 따르면, MSE(330)은 MEC 어플리케이션 컨텍스트 생성이 필요한 경우(예: 앱 리스트에 URI가 없는 경우), URI를 요청하는 요청 메시지를 MMP 서버(370)로 전송할 수 있다. 일 실시예에 따르면, MSE(330)은 MMP 서버(370)에 MEC 어플리케이션이 있을 경우 MEC 어플리케이션 이름(MEC App Name)을 요청 메시지에 포함하여 MMP 서버(370)로 전송할 수 있다. 다른 실시예에 따르면, MSE(330)은 MMP 서버(370)에 MEC 어플리케이션이 없을 경우 해당 MEC 어플리케이션을 다운로드 할 수 있는 URI(예: 어플리케이션 패키지 다운로드 URI(App package download URI)만을 요청 메시지에 포함하여 MMP 서버(370)로 전송할 수 있다.
동작 1420에서, MMP 서버(370)은 MSE(330)로부터 수신된 요청 메시지에 대응하는 응답으로 MEC 어플리케이션의 URI를 포함하는 응답 메시지(예: HTTP OK 200 Response AppContext Data)를 MSE(330)로 제공할 수 있다. 일 실시예에 따르면, 응답 메시지는 해당하는 어플리케이션(예: MEC 어플리케이션)의 URI(FQDN)를 포함할 수 있다. 일 실시예에 따르면, 응답 메시지는 MEC 어플리케이션의 URI 및 해당 URI의 유효 시간 및/또는 유효 위치에 관한 정보를 포함할 수 있다. 일 실시예에 따르면, MSE(330)은 유효 시간 초과 또는 유효 위치 변경 시, 어플리케이션 컨텍스트 재수행 또는 핸드오버 트리거링(handover triggering)이 수행될 수 있다. 일 실시예에 따르면, 응답 메시지는 DNN 정보를 포함할 수 있다.
동작 1430에서, MSE(330)은 정책 업데이트를 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 어플리케이션 컨텍스트 생성 절차(동작 1405)에서, 추가적으로(또는 선택적으로) 정책 업데이트 동작을 포함할 수 있다. 일 실시예에 따르면, MSE(330)은 전용 PDU 세션(dedicated PDU session) 필요 시(또는 새로운 전용 DNN 규칙이 설정된 경우) URSP 규칙(예: DNN)을 수신하고, URSP 규칙에 따라 어플리케이션 별 또는 URI 별 PDU 세션을 설정할 수 있다. 예를 들어, URSP 규칙(또는 CARP 규칙)은 인증 절차의 결과(예: MSA(320)이 수신하여 MSE(330)에 전달), 또는 MSE(330)이 어플리케이션 룩업(예: App lookup) 결과, 또는 컨텍스트 생성(Context Create) 결과로 수신할 수 있으며, URSP 규칙에 새로운 DNN 규칙이 설정되어 있는 경우, PDU 세션 설정(setup)을 수행할 수 있다. 일 실시예에 따르면, PDU 세션 설정(예: 도 8의 PDU 세션 생성, 도 9의 PDU 세션 해제)은 전술한 도 8 또는 도 9를 참조한 설명 부분에서 설명한 바와 같이 MSE(330)이 모뎀(800)에 요청하면, 모뎀(800)에서 5G 망(또는 코어 망)의 SMF에 요청하여 생성/해제할 수 있다.
다양한 실시예들에 따르면, 어플리케이션 컨텍스트 생성 절차(동작 1405)는, 예를 들어, 클라이언트 어플리케이션(310)이 접속해야 할 MEC 어플리케이션이 이미 구동 중이고, 앱 리스트 획득 절차(예: MEC Application Look-up)에서 URI가 수신된 경우에는 생략할 수도 있다.
도 15는 본 개시의 다양한 실시예들에 따른 디스커버리 절차에서 MEC 호스트 선택 절차의 예를 도시하는 도면이다.
도 15에 도시한 바와 같이, 도 15는 MSE(330)이 DNS 서버(1020)과 MEC 호스트를 선택하기 위한 MEC 호스트 선택 동작(MEC Host selection)(1501)을 나타낼 수 있다. 일 실시예에 따르면, MEC 호스트 선택 동작(동작 1501)은, DNS (pre)resolving 동작(예: 동작 1510), MEC Host Prioritization 동작(예: 동작 1520), DNS 캐싱(caching) 동작(예: 동작 1530)을 포함할 수 있다.
도 15을 참조하면, 동작 1510에서, MSE(330)은 DNS 리졸빙(resolving 또는 pre-resolving)을 수행할 수 있다. 일 실시예에 따르면, DNS 리졸빙은, 예를 들어, 클라이언트 어플리케이션(310)의 DNS 쿼리(query)와 상관 없이 MSE(330) 자체적으로 MEC용 FQDN에 대해 DNS 리졸빙 할 수 있다. 일 실시예에 따라, DNS 리졸빙(동작 1510)은, 동작 1511과 동작 1513을 포함할 수 있다.
일 실시예에 따라, 동작 1511에서, MSE(330)은 DHL(335)에 의한 DNS 리졸빙 동작을 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 MEC 어플리케이션에 대한 URI(FQDN)로 DNS 쿼리를 DNS 서버(1020)에 전송할 수 있다.
일 실시예에 따라, 동작 1513에서, DNS 서버(1020)은 MSE(330)로부터 DNS 쿼리를 수신하고, DNS 쿼리에 대응하는 응답으로, DNS 응답을 MSE(330)에 전송할 수 있다. 일 실시예에 따르면, DNS 응답은 MEC 호스트에 관련된 적어도 하나의 주소 정보(예: URI 또는 IP 주소)를 포함할 수 있다.
동작 1520에서, MSE(330)은 MEC 호스트 우선순위 결정(MEC Host Prioritization) 동작을 수행할 수 있다. 일 실시예에 따르면, MEC Host Prioritization는, 예를 들어, DNS 쿼리 응답(query response)으로 복수 개의 IP 주소가 수신되는 경우 IP 우선 순위(prioritization)를 설정하는 것을 포함할 수 있다. 예를 들면, MSE(330)은 MEC 호스트에 대한 우선 순위를 설정할 수 있다.
일 실시예에 따르면, MSE(330)은 MMP 서버(370)로부터 복수 개의 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(330)(예: MEL(331))는 복수의 후보 MEC 호스트에 대해 사전 성능 측정(또는 테스트)(예: ping probing 또는 bandwidth estimation)을 통해 최적의 MEC 호스트를 선택할 수 있다. 일 실시예에 따르면, DNS 서버(1020)은 DNS 응답(DNS response) 메시지에 MEC 호스트의 IP 주소와 함께, 해당 MEC 호스트의 위치 정보(location information)를 기록(record)할 수 있다. 예를 들어, MSE(330)은 DNS 리졸빙 시 DNS 쿼리(query) 후 수신한 DNS 응답 메시지 내 DNS 타입 중 위치 기록 타입(예: LOC record type)에 대해 MEC 호스트의 위치 정보가 포함되어 있을 경우, 해당 위치 정보를 이용하여 인접 MEC 호스트를 선택할 수도 있다. 일 실시예에 따르면, MSE(330)은 MEC 호스트의 IP 주소를 획득하는 DNS 쿼리 동작에서 DNS 서버(1020)로부터 MEC 호스트의 위치 정보(예: 위도, 경도, 서빙 셀 ID, 도시 정보, 또는 ID)를 획득할 수 있다. 예를 들어, DNS 타입 필드에 MEC 호스트의 위치 정보가 포함될 수 있다.
동작 1530에서, MSE(330)은 DNS 캐시(1010)로 DNS 캐싱(caching)을 수행할 수 있다. 일 실시예에 따르면, MSE(330)은 DNS 서버(1020)로부터 DNS 쿼리에 대응하여 주소 정보를 포함하는 DNS 응답을 수신하는 경우, DNS 응답에 포함된 주소 정보(예: MEC 호스트에 관련된 URI(FQDN)에 대응되는 IP 주소)를 MEC 용 로컬 DNS 캐시(Local DNS Cache)(예: DNS Cache 2)에 저장할 수 있다. 일 실시예에 따르면, MSE(330)은 클라이언트 어플리케이션(310)로부터 MEC 어플리케이션에 대한 주소 정보(예: URI 또는 IP 주소)가 요청되는 경우, MEC 용 로컬 DNS 캐시에 저장된 주소 정보를 전달할 수 있다. 다양한 실시예들에 따르면, MEC 용 로컬 DNS 캐시(예: DNS Cache 2)의 운영과 관련하여, 후술하는 도 16의 MEC 용 로컬 DNS 캐시(예: DNS Cache 2)를 별도 운용하는 방안, 또는 도 17의 MSE(330) 내에 MEC 용 로컬 DNS 캐시(예: DNS Cache 2)를 포함하여 운용하는 방안이 이용될 수 있다. 일 실시예에 따른 MEC 용 로컬 DNS 캐시를 운용하는 동작과 관련하여 후술하는 도면을 참조하여 상세히 설명된다.
다양한 실시예들에 따르면, 전자 장치(101)는 MEC 호스트 선택 동작에 기반하여, MMP 서버(370)과의 통신 절차(예: 디스커버리/어플리케이션 컨텍스트 생성)에서, MEC 어플리케이션이 동작할 수 있는 복수 개의 MEC 호스트 정보(예: URI 또는 IP 주소)를 수신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 수시된 복수 개의 MEC 호스트 중 어느 하나의 MEC 호스트를 선택하여 통신할 수 있다. 다양한 실시예들에 따르면, 전자 장치(101)는 MEC 어플리케이션이 동작할 수 있는 복수 개의 MEC 호스트에 대하여, 우선 순위에 따라 선택할 수 있다. 일 실시예에 따르면, 우선 순위는 전자 장치(101)와 MEC 호스트 간의 지연 시간(latency) 측정 정보 또는 MEC 호스트의 위치 정보에 적어도 기반하여 결정될 수 있다.
이하에서, 다양한 실시예들에 따라, 전자 장치(101)에서 일반 클라이언트 어플리케이션(general client Apps)에 대한 DNS 캐싱 데이터와 별도로, MEC 클라이언트 어플리케이션(MEC client Apps)에 대한 DNS 캐싱 데이터를 유지 및/또는 관리하는 동작을 설명한다.
도 16은 본 개시의 다양한 실시예들에 따른 전자 장치(101)에서 MEC 용 로컬 DNS 캐시를 별도로 운용하는 예를 도시하는 도면이다.
도 16을 참조하면, 도 16은 MEC 용 로컬 DNS 캐시를 전자 장치(101)의 MSE(330)과 별도로 구분하여 구성하는 예를 나타낼 수 있다. 일 실시예에 따르면, 일반 클라이언트 어플리케이션(general client Apps)(1610)은 제1 DNS 캐시(1620)로 DNS 캐싱을 수행할 수 있고, MEC 클라이언트 어플리케이션(MEC Client Apps)(310)은 제2 DNS 캐시(1630)로 DNS 캐싱을 수행할 수 있다. 예를 들어, 일반 클라이언트 어플리케이션(1610)은 제1 DNS 캐시(1620)을 이용할 수 있고, MEC 클라이언트 어플리케이션(310)은 제2 DNS 캐시(1630)을 이용할 수 있다.
일 실시예에 따르면, 클라이언트 애플리케이션의 접근하고자 하는 URI에 대해 DNS 리졸빙 API를 사용하여 요청만 수행하고 그에 대한 IP 주소를 수신할 수 있다. 예를 들어, MSE(330)(예: DHL(335))(또는 전자 장치(101)의 OS, 또는 프레임워크(framework) 상의 DNS 처리 모듈)는 클라이언트 어플리케이션의 해당 요청을 DNS 쿼리(예: FQDN) 메시지로 변경하여 DNS 서버(1020)로 요청하고, DNS 응답(예: FQDN에 대응하는 IP 주소)를 수신하여 이를 캐싱하고, 클라이언트 어플리케이션에 전달할 수 있다. 일 실시예에 따르면, MSE(330)은 클라이언트 어플리케이션 별 똔 URI(FQDN) 별로 어떠한 DNS 캐시를 사용할 지에 대한 결정을 할 수 있으며, 그에 따라 별도 DNS 처리 모듈(예: 도 16) 또는 MSE의 DHL(도 17)이 제1 DNS 캐시(1620) 또는 제2 DNS 캐시(1630)을 참조하여 IP 주소를 클라이언트 어플리케이션에 전달할 수 있다. 일 실시예에 따라, DNS 처리 모듈 또는 DHL은 요청받은 URI(FQDN)에 대해 DNS 캐시를 먼저 참조하여 해당 URI에 대응되는 IP가 있으면 이를 전달하고, 캐시에 없을 경우 DNS 서버(1020)로 DNS 쿼리를 수행할 수 있다.
도 17은 본 개시의 다양한 실시예들에 따른 전자 장치(101)에서 MSE(330) 내에 MEC 용 로컬 DNS 캐시를 운용하는 예를 도시하는 도면이다.
도 17을 참조하면, 도 17은 MEC 용 로컬 DNS 캐시(예: 제2 DNS 캐시(1630)을 전자 장치(101)의 MSE(330) 내에 구성하는 예를 나타낼 수 있다. 일 실시예에 따르면, 일반 클라이언트 어플리케이션(1610)은 제1 DNS 캐시(1620)로 DNS 캐싱을 수행할 수 있고, MEC 클라이언트 어플리케이션(310)은 제2 DNS 캐시(1630)로 DNS 캐싱을 수행할 수 있다. 예를 들어, 일반 클라이언트 어플리케이션(1610)은 제1 DNS 캐시(1620)을 이용할 수 있고, MEC 클라이언트 어플리케이션(310)은 제2 DNS 캐시(1630)을 이용할 수 있다.
일 실시예에 따르면, 클라이언트 애플리케이션의 접근하고자 하는 URI에 대해 DNS 리졸빙 API를 사용하여 요청만 수행하고 그에 대한 IP 주소를 수신할 수 있다. 예를 들어, MSE(330)(예: DHL(335))(또는 전자 장치(101)의 OS, 또는 프레임워크(framework) 상의 DNS 처리 모듈)는 클라이언트 어플리케이션의 해당 요청을 DNS 쿼리(예: FQDN) 메시지로 변경하여 DNS 서버(1020)로 요청하고, DNS 응답(예: FQDN에 대응하는 IP 주소)를 수신하여 이를 캐싱하고, 클라이언트 어플리케이션에 전달할 수 있다. 일 실시예에 따르면, MSE(330)은 클라이언트 어플리케이션 별 똔 URI(FQDN) 별로 어떠한 DNS 캐시를 사용할 지에 대한 결정을 할 수 있으며, 그에 따라 별도 DNS 처리 모듈(예: 도 16) 또는 MSE의 DHL(도 17)이 제1 DNS 캐시(1620) 또는 제2 DNS 캐시(1630)을 참조하여 IP 주소를 클라이언트 어플리케이션에 전달할 수 있다. 일 실시예에 따라, DNS 처리 모듈 또는 DHL은 요청받은 URI(FQDN)에 대해 DNS 캐시를 먼저 참조하여 해당 URI에 대응되는 IP가 있으면 이를 전달하고, 캐시에 없을 경우 DNS 서버(1020)로 DNS 쿼리를 수행할 수 있다.
다양한 실시예들에 따라, 일반 클라이언트 어플리케이션(1610)과 MEC 클라이언트 어플리케이션(310)을 구분하여, DNS 캐싱을 수행하는 것과 관련하여, 후술하는 도면(예: 도 36)을 참조하여 상세히 설명된다.
도 18은 본 개시의 다양한 실시예들에 따른 디스커버리 절차에서 DNS 리졸빙 동작의 예를 도시하는 도면이다.
도 18에 도시한 바와 같이, 도 18은 클라이언트 어플리케이션(310)의 DNS 쿼리에 대한 DNS 리졸빙 동작을 나타낼 수 있다. 일 실시예에 따르면, DNS 리졸빙 동작은, DNS 서버(1020)이 비활성화된 상태인 경우의 동작(예: 동작 1810)과 DNS 서버(1020)이 활성화된 상태인 경우의 동작(예: 동작 1830)을 포함할 수 있다.
일 실시예에 따르면, 동작 1810의 DNS 리졸빙 동작은, 예를 들어, DNS 캐시(1010)에서 MEC용 로컬 DNS 캐시(예: 제2 DNS 캐시(1630))가 비활성화된 상태의 동작 예를 나타낼 수 있다. 도 18을 참조하면, 클라이언트 어플리케이션(310)은 URI에 대한 DNS 쿼리를 DNS 캐시(1010)로 전달(동작 1811)할 수 있고, DNS 캐시(1010)은 클라이언트 어플리케이션(310)의 DNS 쿼리에 대한 응답(예: DNS Cache Response)을 클라이언트 어플리케이션(310)에 전달(동작 1813)할 수 있다. 일 실시예에 따라, DNS 캐시(1010)은 MEC 어플리케이션의 어플리케이션 이름, 도메인 이름, 또는 도메인 이름에 대한 IP 주소 중 적어도 하나를 저장할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(310)의 URI에 대한 DNS 쿼리 시 DNS 캐시(1010)에 해당 URI의 MEC 어플리케이션의 IP 주소가 존재하지 않는 경우(예: DNS 캐시 미스(cache miss)), 클라이언트 어플리케이션(310)은 DNS 서버(1020)로 DNS 쿼리를 전달(동작 1815)하고, DNS 서버(1020)로부터 DNS 쿼리에 대응하는 응답(1817)에 기반하여, IP 주소를 획득할 수 있다.
일 실시예에 따르면, 동작 1830의 DNS 리졸빙 동작은, 예를 들어, DNS 캐시(1010)에서 MEC용 로컬 DNS 캐시(예: 제2 DNS 캐시(1630)이 활성화된 상태의 동작 예를 나타낼 수 있다. 도 18을 참조하면, 클라이언트 어플리케이션(310)은 URI에 대한 DNS 쿼리를 MSE(330)을 통해 DNS 캐시(1010)로 전달(동작 1831, 동작 1833)할 수 있다. 일 실시예에 따라, DNS 캐시(1010)은 MSE(330)로 DNS 쿼리에 대한 DNS 응답을 전달(동작 1835)할 수 있다. 일 실시예에 따라, 클라이언트 어플리케이션(310)의 URI에 대한 DNS 쿼리 시 DNS 캐시(1010)에 해당 URI의 MEC 어플리케이션의 IP 주소가 존재하지 않는 경우(예: DNS 캐시 미스), MSE(330)은 DNS 서버(1020)로 DNS 쿼리를 전달(동작 1837)하고, DNS 서버(1020)로부터 DNS 쿼리에 대응하는 응답을 수신(동작 1839)하고, 수신된 응답을 클라이언트 어플리케이션(310)에 포워딩(동작 1841) 할 수 있다.
일 실시예에 따르면, 클라이언트 어플리케이션(310)의 URI에 대한 DNS 쿼리 시 DNS 캐시(1010)에 해당 URI의 MEC 어플리케이션의 IP 주소가 있을 경우, 해당 주소로 MEC 어플리케이션에 접속할 수 있다. 일 실시예에 따르면, DNS 리졸빙에서, DNS 캐시 미스 시, DNS 리졸빙을 통해 리모트(remote) 서버(예: 도 3의 리모트 서버(306)) 또는 Client App-driven MEC 어플리케이션에 접속할 수 있다. 일 실시예에 따르면, DNS 리졸빙에서, DNS 프록시(proxy)가 있을 경우, DNS 프록시가 클라이언트 어플리케이션의 DNS 쿼리를 후킹(hooking)하여 MEC 앱 리스트에 따라 DNS 리졸빙을 수행할 수 있다.
일 실시예에 따르면, MSE(330)에서는 3rd 파티 어플리케이션(party application)에 DNS Pre-resolving 또는 DNS 프록시 기능을 지원할 수 있다. 예를 들어, 기존 기본 PDU 세션을 통해 데이터 연결이 된 상태에서 MEC 용 클라이언트 어플리케이션(310)이 특정 서비스 접속을 위한 DNS 쿼리를 하면, DNS 프록시가 DNS 쿼리를 가로채서, MEC 용 도메인 이름으로 DNS 서버(1020)에 쿼리를 하거나, 또는 DNS 캐시(1010)에서 룩업(lookup)하여 해당 MEC 도메인 IP 주소를 반환할 수 있다. 이를 통해, 3rd 파티 어플리케이션이 별도의 소프트웨어 수정 없이, 그리고 오퍼레이터의 별도 트래픽 필터링(traffic filtering)(또는 steering) 작업 없이 MEC 서비스를 제공할 수 있다.
한편, 이상에서 설명된 각 신호 흐름도들은 필요에 따라서 다른 신호 흐름도와 연결되어 동작할 수 있다. 예컨대, 인증 동작(예: 도 4 내지 도 6 중 적어도 하나) 이후 NAS 시그널링이 이루어지는 도 7의 동작이 수행될 수 있다.
또한 이상에서 설명된 각 신호 흐름도들은 필요에 따라서 다른 신호 흐름도의 일부에 대체하여 사용될 수 있다. 예컨대, 도 4 내지 도 6의 인증을 위한 동작들은 다른 도면에서 사용되고 있는 동작으로 대체하여 구현할 수 있다.
본 명세서와 도면에 개시된 본 개시의 다양한 실시예들은 본 개시의 기술 내용을 쉽게 설명하고 본 개시의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 개시의 범위를 한정하고자 하는 것은 아니다. 따라서 본 개시의 범위는 여기에 개시된 실시예들 이외에도 본 개시의 기술적 사상을 바탕으로 도출되는 모든 변경 또는 변형된 형태가 본 개시의 범위에 포함되는 것으로 해석되어야 한다.
본 개시는 무선 통신 시스템에서 엣지 컴퓨팅 서비스를 제공하기 위한 경우에 사용될 수 있다.

Claims (15)

  1. 이동통신 시스템의 인증 서버에서 엣지 컴퓨팅 서비스를 제공받는 전자 장치의 인증 방법에 있어서,
    상기 전자 장치와 인증 및 키 합의(Authentication and Key Agreement, AKA) 방식으로 상기 전자 장치의 제1인증을 수행(403)하고, 제1인증 성공 시 제1인증 정보를 상기 전자 장치로 제공하는 단계; 및
    상기 전자 장치의 엣지 컴퓨팅 서비스를 위한 제2인증을 수행(411)하고, 상기 제2인증 성공 시 상기 전자 장치로 상기 엣지 컴퓨팅 서비스의 인증을 위한 접속 토큰을 포함하는 제2인증 정보를 상기 전자 장치로 제공하는 단계;를 포함하는, 엣지 컴퓨팅 서비스를 위한 방법.
  2. 제1항에 있어서, 상기 제1인증은,
    일반 공개 구독 식별자(generic public subscription identifier)를 이용하여 상기 전자 장치의 사용자를 인증(user authentication)하는, 엣지 컴퓨팅 서비스를 위한 방법.
  3. 제1항에 있어서,
    상기 제1인증에 성공하면, 상기 전자 장치로 엣지 컴퓨팅 서비스를 제공받기 위한 멀티 액세스 에지 컴퓨팅 관리 프록시(MMP) 정보 및 권한 부여 코드(Authorization code)를 포함하는 제1정보를 제공하는, 엣지 컴퓨팅 서비스를 위한 방법.
  4. 이동통신 시스템의 전자장치가 엣지 컴퓨팅 서비스를 제공하는 이동통신 시스템에서 에지 컴퓨팅 서비스를 위한 인증 방법에 있어서,
    상기 전자 장치가 상기 이동통신 시스템의 인증 서버와 키 합의(Authentication and Key Agreement, AKA) 방식으로 제1인증을 수행(403)하고 제1인증 정보를 수신하는 단계; 및
    상기 전자 장치가 상기 인증 서버와 엣지 컴퓨팅 서비스를 위한 제2인증을 수행(411)하고, 상기 엣지 컴퓨팅 서비스의 인증을 위한 접속 토큰을 포함하는 제2인증 정보를 수신하는 단계;를 포함하는, 엣지 컴퓨팅 서비스를 위한 방법.
  5. 제4항에 있어서, 상기 제1인증은,
    상기 전자 장치의 일반 공개 구독 식별자(generic public subscription identifier)를 이용하여 상기 전자 장치의 사용자를 인증(user authentication)하는, 엣지 컴퓨팅 서비스를 위한 방법.
  6. 제4항에 있어서,
    상기 전자 장치는, 상기 제1인증에 성공 시 엣지 컴퓨팅 서비스를 제공받기 위한 멀티 액세스 에지 컴퓨팅 관리 프록시(MMP) 정보 및 권한 부여 코드(Authorization code)를 포함하는 제1정보를 수신하는, 엣지 컴퓨팅 서비스를 위한 방법.
  7. 제4항에 있어서,
    상기 전자 장치는 제1인증 정보 및 상기 제2인증 정보에 기반하여 상기 엣지 컴퓨팅 서비스(MEC)를 위한 디스커버리 절차를 수행하는 단계;를 더 포함하는, 엣지 컴퓨팅 서비스를 위한 방법.
  8. 이동통신 시스템의 멀티 액세스 에지 컴퓨팅 관리 프록시(MMP) 서버에서 엣지 컴퓨팅 서비스를 제공받는 전자 장치로 엣지 컴퓨팅 서비스 정보를 제공하기 위한 방법에 있어서,
    상기 전자 장치로부터 상기 MMP에 대한 정규화된 도메인 이름(fully qualified domain name, FQDN)를 포함하는 적어도 하나의 엣지 컴퓨팅 서버의 질의(query) 메시지를 수신하는 단계; 및
    상기 질의에 응답하는 응답 메시지를 상기 전자 장치로 송신하는 단계;를 포함하며,
    상기 응답 메시지는, 상기 MMP를 통해 엣지 컴퓨팅 서비스를 제공할 수 있는 어플리케이션 리스트를 포함하는, 엣지 컴퓨팅 서비스를 위한 방법.
  9. 제8항에 있어서,
    상기 전자 장치로부터 상기 응답 메시지에 포함된 제1 MEC 어플리케이션 이름에 대한 주소가 요청될 시 상기 제1 MEC 어플리케이션의 주소 정보를 제공하는 단계;를 더 포함하는, 엣지 컴퓨팅 서비스를 위한 방법.
  10. 제9항에 있어서, 상기 제1 MEC 어플리케이션의 주소 정보는,
    통합 자원 식별자(Uniform Resource Identifier, URI) 정보인, 엣지 컴퓨팅 서비스를 위한 방법.
  11. 멀티 액세스 에지 컴퓨팅 관리 프록시(MMP) 서버를 통해 엣지 컴퓨팅 서비스를 제공하는 이동통신 시스템에서 전자장치가 엣지 컴퓨팅 서비스 정보를 획득하기 위한 방법에 있어서,
    상기 MMP에 대한 정규화된 도메인 이름(fully qualified domain name, FQDN)를 포함하는 적어도 하나의 엣지 컴퓨팅 서버의 질의(query) 메시지를 상기 MMP로 송신하는 단계; 및
    상기 MMP로부터 상기 질의에 응답하는 응답 메시지를 수신하는 단계;를 포함하며,
    상기 응답 메시지는, 상기 MMP를 통해 엣지 컴퓨팅 서비스를 제공할 수 있는 어플리케이션 리스트를 포함하는, 엣지 컴퓨팅 서비스를 위한 방법.
  12. 제11항에 있어서,
    상기 응답 메시지에 포함된 제1 MEC 어플리케이션 이름에 대한 주소를 상기 MMP로 요청하는 단계; 및
    상기 MMP로부터 상기 제1 MEC 어플리케이션의 주소 정보를 수신하는 단계;를 더 포함하는, 엣지 컴퓨팅 서비스를 위한 방법.
  13. 제12항에 있어서, 상기 제1 MEC 어플리케이션의 주소 정보는,
    통합 자원 식별자(Uniform Resource Identifier, URI) 정보인, 엣지 컴퓨팅 서비스를 위한 방법.
  14. 전자 장치에 있어서,
    네트워크 인터페이스;
    엣지 컴퓨팅 서비스(multi-access edge computing services, MEC)를 위한 적어도 하나의 어플리케이션;
    상기 네트워크 인터페이스를 통해 상기 전자 장치의 인증, 상기 MEC의 인증, 상기 MEC의 정책, 상기 MEC의 데이터 경로 설정에 따른 제어를 수행하는 멀티 액세스 서비스 에지전트(MSA); 및
    상기 네트워크 인터페이스를 통해 이동통신 시스템의 MEC 관리 프록시 서버(MMP)와 세션 설정 및 데이터 전송 시의 경로를 설정하고, 질의 정보의 송신 및 응답 신호를 수신하고, MMP를 통해 MEC 어플리케이션 서버의 탐색(discovery)을 수행하는 멀티 액세스 서비스 인에이블러(MSE);를 포함하는, 전자 장치.
  15. 제14항에 있어서, 상기 MSE는,
    상기 MMP에 대한 정규화된 도메인 이름(fully qualified domain name, FQDN)를 포함하는 적어도 하나의 엣지 컴퓨팅 서버의 질의(query) 메시지를 상기 MMP로 송신하고,
    상기 MMP로부터 상기 질의에 응답하는 응답 메시지를 수신하며, 상기 응답 메시지는, 상기 MMP를 통해 엣지 컴퓨팅 서비스를 제공할 수 있는 어플리케이션 리스트를 포함하는, 전자 장치.
PCT/KR2020/004257 2019-03-29 2020-03-27 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치 WO2020204505A1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2021558600A JP2022528867A (ja) 2019-03-29 2020-03-27 エッジコンピューティングサービスのための方法及びその電子装置
EP20784458.0A EP3934208A4 (en) 2019-03-29 2020-03-27 METHOD FOR EDGE COMPUTING SERVICE AND ELECTRONIC DEVICE THEREFORE
CN202080036547.0A CN113826372A (zh) 2019-03-29 2020-03-27 用于边缘计算服务的方法及其电子设备
US17/599,331 US20220201597A1 (en) 2019-03-29 2020-03-27 Method for edge computing service and electronic device therefor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962826218P 2019-03-29 2019-03-29
US62/826,218 2019-03-29

Publications (1)

Publication Number Publication Date
WO2020204505A1 true WO2020204505A1 (ko) 2020-10-08

Family

ID=72666305

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/004257 WO2020204505A1 (ko) 2019-03-29 2020-03-27 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치

Country Status (6)

Country Link
US (1) US20220201597A1 (ko)
EP (1) EP3934208A4 (ko)
JP (1) JP2022528867A (ko)
KR (1) KR20200115359A (ko)
CN (1) CN113826372A (ko)
WO (1) WO2020204505A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112437080A (zh) * 2020-11-20 2021-03-02 中国联合网络通信集团有限公司 一种业务鉴权方法及装置
CN113079206A (zh) * 2021-03-25 2021-07-06 中国联合网络通信集团有限公司 终端场景化应用自动配置方法、mec服务器及用户终端

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020209703A1 (en) * 2019-04-12 2020-10-15 Samsung Electronics Co., Ltd. Method and system for discovering edge-server or edge-service through domain name server (dns) resolution
US11032163B2 (en) 2019-10-25 2021-06-08 Verizon Patent And Licensing Inc. Method and system for selection and orchestration of multi-access edge computing resources
US20220052961A1 (en) * 2020-08-11 2022-02-17 Verizon Patent And Licensing Inc. Resource discovery in a multi-edge computing network
US11871236B2 (en) * 2021-01-20 2024-01-09 Hughes Systique Corporation Method and a system for dynamic discovery of multi-access edge computing (MEC) applications
US11665097B2 (en) * 2021-04-27 2023-05-30 Verizon Patent And Licensing Inc. Methods and systems for differentiating MEC flows using IP header signaling
CN114745434A (zh) * 2022-04-06 2022-07-12 北京三快在线科技有限公司 代理网络请求的方法、装置、设备及存储介质
CN114900288B (zh) * 2022-05-23 2023-08-25 北京科技大学 一种基于边缘服务的工业环境认证方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040013966A (ko) * 2002-08-09 2004-02-14 한국전자통신연구원 이동 통신망에서의 인증 및 키 합의 방법
KR20070052492A (ko) * 2005-11-17 2007-05-22 한국전자통신연구원 서비스 선불요금 차감 스마트 카드 및 이를 이용한 서비스선불요금 차감 방법 및 장치
KR20090039451A (ko) * 2007-10-18 2009-04-22 주식회사 케이티 사용자 패스워드로부터 유도된 비밀키 기반의 인증 방법
WO2011081242A1 (ko) * 2010-01-04 2011-07-07 전자부품연구원 바이너리 cdma에서 키 인증 방법
KR20170129549A (ko) * 2016-05-17 2017-11-27 한국전자통신연구원 패스워드와 ｉｄ 기반 서명을 이용한 인증 키 합의 방법 및 장치

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101341779A (zh) * 2005-12-21 2009-01-07 诺基亚公司 用于无线接入网的优先化网络接入
EP2384040B1 (en) * 2010-04-29 2013-12-25 BlackBerry Limited Authentication server and method for granting tokens
JP5998220B2 (ja) * 2011-09-09 2016-09-28 インターデイジタル パテント ホールディングス インコーポレイテッド ローカライズドアプリケーションにアクセスするための方法および装置
JP5638504B2 (ja) * 2011-11-30 2014-12-10 三菱電機株式会社 情報中継装置および車載情報端末
CN107241372A (zh) * 2016-03-29 2017-10-10 阿里巴巴集团控股有限公司 配置信息生成、发送方法及资源加载方法和装置及系统
US10531420B2 (en) * 2017-01-05 2020-01-07 Huawei Technologies Co., Ltd. Systems and methods for application-friendly protocol data unit (PDU) session management
US10285155B1 (en) * 2018-09-24 2019-05-07 Cisco Technology, Inc. Providing user equipment location information indication on user plane
US10757757B2 (en) * 2018-09-28 2020-08-25 Intel Corporation MEC-based distributed computing environment with multiple edge hosts and user devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040013966A (ko) * 2002-08-09 2004-02-14 한국전자통신연구원 이동 통신망에서의 인증 및 키 합의 방법
KR20070052492A (ko) * 2005-11-17 2007-05-22 한국전자통신연구원 서비스 선불요금 차감 스마트 카드 및 이를 이용한 서비스선불요금 차감 방법 및 장치
KR20090039451A (ko) * 2007-10-18 2009-04-22 주식회사 케이티 사용자 패스워드로부터 유도된 비밀키 기반의 인증 방법
WO2011081242A1 (ko) * 2010-01-04 2011-07-07 전자부품연구원 바이너리 cdma에서 키 인증 방법
KR20170129549A (ko) * 2016-05-17 2017-11-27 한국전자통신연구원 패스워드와 ｉｄ 기반 서명을 이용한 인증 키 합의 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3934208A4 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112437080A (zh) * 2020-11-20 2021-03-02 中国联合网络通信集团有限公司 一种业务鉴权方法及装置
CN113079206A (zh) * 2021-03-25 2021-07-06 中国联合网络通信集团有限公司 终端场景化应用自动配置方法、mec服务器及用户终端
CN113079206B (zh) * 2021-03-25 2022-11-01 中国联合网络通信集团有限公司 终端场景化应用自动配置方法、mec服务器及用户终端

Also Published As

Publication number Publication date
KR20200115359A (ko) 2020-10-07
EP3934208A4 (en) 2022-04-06
JP2022528867A (ja) 2022-06-16
CN113826372A (zh) 2021-12-21
EP3934208A1 (en) 2022-01-05
US20220201597A1 (en) 2022-06-23

Similar Documents

Publication Publication Date Title
WO2020204505A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2020204269A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2020013677A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2020204474A1 (ko) 무선 통신 시스템에서 에지 컴퓨팅 서비스를 제공하기 위한 장치 및 방법
WO2020231120A1 (ko) 에지 컴퓨팅 서비스에서 단말의 식별자 관리 방법 및 장치
WO2017052136A1 (ko) 이동 통신 시스템에서 프로파일 다운로드 방법 및 장치
WO2020032445A1 (en) Electronic device, external electronic device, and method of managing embedded subscriber identity modules of external electronic device
WO2020105969A1 (ko) 무선 통신 시스템에서 업링크 동작을 결정하는 전자 장치 및 그 방법
WO2020171672A1 (en) Method for interoperating between bundle download process and esim profile download process by ssp terminal
WO2019139247A1 (en) Electronic device for managing embedded subscriber identification module and method for same
WO2021201620A1 (en) Electronic device for performing edge computing service and method for the same
WO2021066569A1 (en) Method and apparatus for reinstalling sim profile in wireless communication system
WO2021241849A1 (ko) 에지 컴퓨팅 서비스를 수행하는 전자 장치 및 전자 장치의 동작 방법
WO2021235880A1 (ko) 무선 통신 시스템에서 단말로 지역 데이터 네트워크 정보를 제공하기 위한 방법 및 장치
WO2021091186A1 (ko) Ue policy 전달을 위한 네트워크 제어 방안
WO2022031148A1 (en) Method and apparatus for installing and managing multiple esim profiles
WO2022114483A1 (ko) 에지 컴퓨팅 서비스를 수행하는 전자 장치 및 전자 장치의 동작 방법
WO2021167234A1 (ko) 네트워크 슬라이스와 관련된 통신
WO2020149722A1 (en) Working environment provisioning method and apparatus for execution of application program between electronic device and external server
WO2021221325A1 (ko) 복수 심을 지원하는 전자 장치 및 그 동작 방법
WO2021162386A1 (ko) 전자 장치 및 전자 장치에서 임베디드 가입자 식별 모듈의 프로파일 정책 규칙을 처리하는 방법
WO2021033961A1 (en) Electronic device and method for providing service by electronic device
WO2022045705A1 (ko) 전자 장치 및 복수의 가입자 식별 모듈들을 지원하는 전자 장치에서 단문 메시지를 수신하는 방법
WO2021225283A1 (ko) 네트워크 슬라이스와 데이터 세션을 형성하는 전자 장치 및 그 동작 방법
WO2021182938A1 (ko) 무선 통신 시스템에서 근거리 무선 통신을 이용한 사용자 계정 관리 방법 및 이에 대한 장치

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: 20784458

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021558600

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020784458

Country of ref document: EP

Effective date: 20210929