KR20200109272A - 애플리케이션 요청의 처리를 최적화하는 방법 및 시스템 - Google Patents

애플리케이션 요청의 처리를 최적화하는 방법 및 시스템 Download PDF

Info

Publication number
KR20200109272A
KR20200109272A KR1020200030666A KR20200030666A KR20200109272A KR 20200109272 A KR20200109272 A KR 20200109272A KR 1020200030666 A KR1020200030666 A KR 1020200030666A KR 20200030666 A KR20200030666 A KR 20200030666A KR 20200109272 A KR20200109272 A KR 20200109272A
Authority
KR
South Korea
Prior art keywords
processing
application request
edge
received
determined
Prior art date
Application number
KR1020200030666A
Other languages
English (en)
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 삼성전자주식회사
Publication of KR20200109272A publication Critical patent/KR20200109272A/ko

Links

Images

Classifications

    • 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/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/32—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B17/00—Monitoring; Testing
    • H04B17/30—Monitoring; Testing of propagation channels
    • H04B17/309—Measuring or estimating channel quality parameters
    • H04B17/318—Received signal strength
    • 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/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
    • 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
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Electromagnetism (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mathematical Physics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 애플리케이션 요청의 처리를 최적화하는 방법 및 시스템이 제공된다. 본 명세서에 개시된 방법은 사용자 장치(UE)가 적어도 하나의 애플리케이션 요청을 처리하기 위한 처리 모드를 결정하는 단계를 포함한다. 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나를 포함할 수 있다.

Description

애플리케이션 요청의 처리를 최적화하는 방법 및 시스템{METHODS AND SYSTEMS FOR OPTIMIZING PROCESSING OF APPLICATION REQUESTS}
본 개시는 다중 액세스 에지 컴퓨팅(multi-access edge computing: MEC)의 분야에 관한 것으로서, 특히 낮은 대기 시간(latency)으로 애플리케이션 요청(application request)을 처리하기 위한 로컬 컴퓨팅 및 에지/MEC 컴퓨팅의 최적 이용을 가능하게 한다.
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) 등이 개발되고 있다.
한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크(cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.
본 명세서의 실시예의 주요 목적은 사용자 디바이스(User Equipment: UE)의 로컬 컴퓨팅과 함께 다중 액세스 에지 컴퓨팅(MEC)을 이용함으로써 적어도 하나의 애플리케이션 요청의 처리를 최적화하는 방법 및 시스템을 개시하는 것이다.
본 명세서의 실시예의 다른 목적은 적어도 하나의 애플리케이션 요청을 처리하기 위한 적어도 하나의 처리 모드를 예측하는 방법 및 시스템을 개시하는 것이며, 여기서 적어도 하나의 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나를 포함한다.
본 명세서의 실시예의 다른 목적은 적어도 하나의 애플리케이션 요청에 대한 에지 처리 시간을 예측하기 위해 적어도 하나의 머신 학습(machine learning: ML) 방법을 사용하는 방법 및 시스템을 개시하는 것이다.
본 명세서의 실시예의 다른 목적은 UE의 로컬 처리 시간, 예측된 에지 처리 시간, 배터리 레벨 및 사용자 선호도(user preference) 중 적어도 하나에 기초하여 비용 함수(cost function)를 도출하는 방법 및 시스템을 개시하는 것이다.
본 명세서의 실시예의 다른 목적은 적어도 하나의 애플리케이션 요청을 처리하기 위한 적어도 하나의 처리 모드를 결정하기 위해 ML 방법을 사용하여 도출된 비용 함수 및 예측된 에지 처리 시간을 분석하는 방법 및 시스템을 개시하는 것이다.
본 명세서의 실시예의 다른 목적은 UE가 적어도 하나의 애플리케이션 요청을 로컬로 처리하기 위해 에지 서버로부터 계산 모듈을 다운로드할 수 있게 하는 방법 및 시스템을 개시하는 것이다.
본 명세서의 실시예의 다른 목적은 다양한 타입의 애플리케이션 요청을 처리하기 위해 적용될 수 있는 에지 서버 상에서 공통 계산 모듈을 호스팅하는 방법 및 시스템을 개시하는 것이다.
따라서, 본 명세서의 실시예는 애플리케이션 요청의 처리를 최적화하는 방법 및 시스템을 제공한다. 본 명세서에 개시된 방법은 사용자 디바이스(UE)가 사용자 디바이스(UE)가 적어도 하나의 애플리케이션에 의해 개시된 적어도 하나의 애플리케이션 요청을 수신하는 단계; 상기 UE가 수신된 적어도 하나의 애플리케이션 요청이 다중 액세스 에지 컴퓨팅(MEC)이 가능한지를 식별하는 단계; 상기 수신된 적어도 하나의 애플리케이션 요청이 MEC가 가능한 경우에 상기 UE가 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 처리 모드를 결정하는 단계로서, 상기 처리 모드는 상기 MEC 및 로컬 컴퓨팅 중 적어도 하나를 사용하여 결정되는, 상기 결정하는 단계; 및 상기 UE가 상기 수신된 적어도 하나의 애플리케이션 요청에 대해 결정된 상기 처리 모드에 기초하여 적어도 하나의 동작을 수행하는 단계를 포함할 수 있다.
또한, 본 명세서의 실시예는 사용자 디바이스(UE)를 제공한다. UE는 메모리; 및 상기 메모리에 결합된 제어부를 포함하는데, 상기 제어부는, 적어도 하나의 애플리케이션에 의해 개시된 적어도 하나의 애플리케이션 요청을 수신하고; 수신된 적어도 하나의 애플리케이션 요청이 MEC 가능한지를 식별하고; 상기 수신된 적어도 하나의 애플리케이션 요청이 MEC 가능한 경우에 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 처리 모드 - 상기 처리 모드는 MEC 컴퓨팅 및 로컬 컴퓨팅 중 적어도 하나를 사용하여 결정됨 -를 결정하며; 상기 수신된 적어도 하나의 애플리케이션 요청에 대해 결정된 상기 처리 모드에 기초하여 적어도 하나의 동작을 수행하도록 구성될 수 있다.
본 명세서의 예시적인 실시예의 이러한 및 다른 양태는 다음의 설명 및 첨부된 도면과 함께 고려될 때 더 잘 인식되고 이해될 것이다. 그러나, 다음의 설명은 예시적인 실시예 및 이의 다수의 특정 상세 사항을 나타내면서 제한이 아닌 예시로서 제공된다는 것이 이해되어야 한다. 본 명세서의 예시적인 실시예의 범위 내에서 본 실시예의 사상을 벗어나지 않고 많은 변경 및 수정이 이루어질 수 있으며, 본 명세서의 예시적인 실시예는 이러한 모든 수정을 포함한다.
낮은 대기 시간으로 애플리케이션 요청을 처리하기 위해 로컬 컴퓨팅 및 에지/MEC 컴퓨팅을 최적으로 활용할 수 있는 방법 및 시스템이 제공된다.
본 명세서의 실시예는 첨부된 도면에 도시되며, 전체에 걸쳐 유사한 참조 문자는 다양한 도면에서 상응하는 부분을 나타낸다. 본 명세서의 실시예는 도면을 참조하여 다음의 설명으로부터 더 잘 이해될 것이다.
도 1a-1e는 다중 액세스 에지 컴퓨팅(MEC)에서 애플리케이션을 처리하는 예시적인 시나리오를 도시한다.
도 2a 및 2b는 본 명세서에 개시된 바와 같은 실시예에 따른 MEC 시스템을 도시한다.
도 3은 본 명세서에 개시된 바와 같은 실시예에 따른 사용자 디바이스(UE)를 도시한다.
도 4는 본 명세서에 개시된 바와 같은 실시예에 따라 MEC 프로세서의 다양한 모듈을 도시하는 블록도이다.
도 5는 본 명세서에 개시된 바와 같은 실시예에 따른 예시적인 MEC 시스템을 도시한다.
도 6은 본 명세서에 개시된 바와 같은 실시예에 따라 낮은 대기 시간으로 UE 상에서 애플리케이션 요청의 처리를 최적화하는 방법을 도시하는 예시적인 흐름도이다.
도 7은 본 명세서에 개시된 바와 같은 실시예에 따라 UE 상에서 애플리케이션 요청들을 처리하기 위한 처리 모드를 결정하는 방법을 도시하는 예시적인 흐름도이다.
도 8a, 8b 및 8c는 본 명세서에 개시된 바와 같은 실시예에 따라 머신 학습(ML) 테이블/학습 모델의 구축을 위해 사용되는 트레이닝 데이터(training data)를 도시하는 예시적인 다이어그램이다.
도 9는 본 명세서에 개시된 바와 같은 실시예에 따라 애플리케이션 요청의 로컬 처리를 위해 에지 서버로부터 계산 라이브러리의 다운로딩을 도시하는 예시적인 다이어그램이다.
도 10은 본 명세서에 개시된 바와 같은 실시예에 따라 애플리케이션 요청의 처리를 최적화하는 방법을 도시하는 흐름도이다.
본 명세서의 예시적인 실시예 및 이의 다양한 특징 및 유리한 상세 사항은 첨부된 도면에 도시되고 다음의 설명에서 상세히 설명되는 비제한적인 실시예를 참조하여 보다 완전하게 설명된다. 잘 알려진 구성 요소 및 처리 기술에 대한 설명은 본 명세서의 실시예를 불필요하게 모호하게 하지 않기 위해 생략된다. 본 명세서의 설명은 단지 본 명세서의 예시적인 실시예가 실시될 수 있는 방식의 이해를 용이하게 하고, 통상의 기술자가 본 명세서의 예시적인 실시예를 더 실시할 수 있게 하기 위한 것이다. 따라서, 본 개시는 본 명세서의 예시적인 실시예의 범위를 제한하는 것으로서 해석되지 않아야 한다.
일반적으로, 사용자가 중앙 집중식 퍼블릭 클라우드(centralized public cloud) 상에서 실행되는 서버로부터 적어도 하나의 서비스에 액세스할 때, 네트워크의 대기 시간은 변동될 수 있다. 현재 사용자 위치에 따라 사용자와 서버 간의 거리가 변경되므로 네트워크 대기 시간은 변동될 수 있다. 예를 들어, 네트워크 대기 시간은 도 1a에 도시된 바와 같이 100-500ms에서 변동될 수 있다. 이러한 변동하는 대기 시간은 일관된 초저 대기 시간(ultra-low latency)을 필요로 하는 새로운 서비스를 도입하는데 장애가 될 수 있다. MEC(Multi-access Edge Computing)(이전에, 모바일 에지 컴퓨팅으로서 알려짐)는 도 1a에 도시된 바와 같이 일관된 낮은 대기 시간(예를 들어, 30ms 미만)을 제공함으로써 이러한 장애를 극복할 수 있다.
MEC는 가능한 최종 사용자와 가깝게 통신 에지 클라우드 상에 서버를 분산할 수 있게 하여, 사용자는 낮은 대기 시간을 경험함으로써 새로운 서비스에 액세스할 수 있도록 한다. 더욱이, MEC는 임의의 통신 네트워크로 작업할 수 있다.
더욱이, MEC를 사용하여, 사용자는 낮은 네트워크 대기 시간 및 서버 컴퓨팅 능력의 이점을 이용함으로써 (사용자 디바이스 상에서 실행되는) 애플리케이션과 관련된 계산을 통신 에지 클라우드 상에 분산된 서버로 오프로드할 수 있다. 그러나, 현재 MEC에서, 통신 네트워크는 사용자 디바이스로부터 통신 에지 클라우드 상에 위치한 서버로의 계산의 오프로딩을 결정한다. 그러나, 통신 네트워크가 사용자 디바이스의 처리 능력을 인식하지 못할 때, 이러한 네트워크 기반 의사 결정(network based decision making)은 사용자 디바이스로부터 서버로의 계산을 오프로딩하기 위한 항상 최상의 선택이 아닐 수 있다.
현재, MEC에서, 통신 에지 클라우드 상에 배치된 서버로 계산을 오프로딩하기로 결정하기 전에 사용자 디바이스의 처리 능력은 고려되지 않을 수 있다.
도 1b에 도시된 바와 같은 예시적인 시나리오를 고려하며, 여기서 사용자 디바이스는 낮은 처리 능력을 갖는 저급(low-end) 사용자 디바이스이며, 이는 통신 에지 클라우드 상에 배치된 서버로 계산을 오프로딩하는 대신에 계산을 위한 로컬 처리를 사용한다. 이러한 시나리오에서, 저급 사용자 디바이스는 더 높은 로컬 처리 시간으로 인해 낮은 대기 시간으로 손실될 수 있다.
도 1c에 도시된 바와 같은 예시적인 시나리오를 고려하며, 여기서 사용자 디바이스는 높은 처리 능력을 갖는 고급(high-end) 사용자 디바이스이며, 이는 통신 에지 클라우드 상에 배치된 서버로 계산을 오프로딩한다. 이러한 시나리오에서, 고급 사용자 디바이스는 더 빠른 로컬 처리와 비교하여 더 느린 원격/에지 처리로 인해 대기 시간이 증가할 수 있다.
현재, MEC는 혼잡으로 인한 네트워크 처리의 동적 변경을 처리할 수 없다. 더욱이, 다양한 네트워크 혼잡은 가변적인 대기 시간을 야기할 수 있음으로써, 통신 에지 클라우드 상에 배치된 서버로의 계산의 오프로딩이 도 1d에 도시된 바와 같이 계산을 위한 항상 최상의 선택이 아닐 수 있다.
현재, MEC에서, 오프로딩하기로 결정하면서 통신 네트워크(예를 들어, 4G-5G-4G)의 네트워크 전환/변경은 고려되지 않을 수 있다. 네트워크는 가변적인 대기 시간을 야기할 수 있음으로써, 통신 에지 클라우드 상에 배치된 서버로 계산을 오프로딩하는 것이 도 1e에 도시된 바와 같이 계산을 위한 항상 최상의 선택이 아닐 수 있다.
더욱이, 선택적인 오프로딩 옵션이 없기 때문에, 애플리케이션은 통신 에지 클라우드 상에 배치된 서버로 계산을 오프로딩하는데 선택의 여지가 없다.
따라서, 현재 MEC는 낮은 대기 시간으로 계산을 처리하기 위한 동적 의사 결정을 포함하지 않는다.
본 명세서의 실시예는 적어도 하나의 애플리케이션 요청의 처리를 최적화하기 위한 적어도 하나의 처리 모드를 예측하는 방법 및 시스템을 개시하며, 여기서 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나를 포함한다. 이제 도면을 참조하면, 특히 도 2a 내지 10을 참조하면, 유사한 참조 문자는 도면 전체에서 일관되게 상응하는 특징을 나타내며, 예시적인 실시예가 도시된다.
도 2a 및 2b는 본 명세서에 개시된 바와 같은 실시예에 따른 다중 액세스 에지 컴퓨팅(MEC) 시스템(200)을 도시한다. MEC(Multi-access edge computing)는 MEC 애플리케이션을 네트워크 에지 내에 위치되거나 네트워크 에지에 가까운 가상화 인프라 위에서 실행되는 소프트웨어 전용 엔터티로서 구현할 수 있다. 본 명세서에서 언급된 MEC 시스템(200)은 ETSI(European Telecommunications Standards Institute) MEC에 따라 서비스 및 콘텐츠를 다수의 사용자에게 지원하는 서비스, 애플리케이션 중 적어도 하나를 제공하도록 구성될 수 있다. 본 명세서에서 언급된 서비스의 예는 스트리밍 서비스(오디오, 비디오, 텍스트 등과 같은 멀티미디어 데이터의 스트리밍), 통화 관련 서비스(call related service), 파일 다운로드 서비스, 캐러셀 서비스(carousel service)(파일 다운로드 서비스 및 스트리밍 서비스를 조합함), 텔레비전(TV) 서비스, 주문형 미디어 서비스(media on demand service) 등일 수 있지만, 이에 제한되지는 않는다. 본 명세서에 언급된 애플리케이션의 예는 통화 관련 애플리케이션, OTT(Over-the Top) 애플리케이션, 스트리밍 애플리케이션, 파일 다운로드 관련 애플리케이션, 소셜 네트워킹 애플리케이션(social networking application), 카메라 애플리케이션, IoT 관련 애플리케이션, 증강 현실(Augmented Reality: AR) 관련 애플리케이션 등일 수 있지만, 이에 제한되지는 않는다. 콘텐츠의 예는 파일, 데이터, 비디오, 오디오/음성 등일 수 있지만, 이에 제한되지는 않는다.
MEC 시스템(200)은 원격/퍼블릭 클라우드(202), 에지 서버(204), 기지국(BS)(206a) 및 사용자 장치(UE)(208)를 포함한다.
원격 클라우드(202)는 서비스, 애플리케이션 및 콘텐츠 중 적어도 하나를 적어도 하나의 UE(208) 중 적어도 하나의 사용자에게 오프로딩하기 위한 하나 이상의 서버(애플리케이션 서버/타사 서버(third party server)를 포함할 수 있다. ETSI 기반 MEC에 따라, 퍼블릭 클라우드(202)는 (도 2b에 도시된 바와 같이) 오프로딩 동안 낮은 대기 시간을 달성하기 위해 (상이한 서비스 제공자/오퍼레이터에 의해 제공되는) 오퍼레이터/통신사(telco)의 네트워크(206) 내에서 BS(206a)에 근접하여 하나 이상의 서버를 배치/위치/분산하도록 구성될 수 있다. 따라서, 서비스, 콘텐츠 및 애플리케이션이 사용자에게 전달되는 것이 향상된다.
(도 2b에 도시된 바와 같은) 오퍼레이터 네트워크(206)는 BS(206a), 서버 분산 모듈(206b) 등을 포함할 수 있다. BS(206a)(eNodeB/gNodeB)는 적어도 하나의 UE(208)가 적어도 하나의 외부 디바이스와 통신할 수 있도록 구성될 수 있다. BS(206a)는 적어도 하나의 무선 액세스 네트워크(Radio Access Network: RAN)(206c)의 셀을 서빙할 수 있다. RAN(206c)의 예는 3GPP(3rd Generation Partnership Project), LTE/4G(Long Term Evolution), LTE-A(LTE-Advanced), 3GPP2, 5G NR(New Radio), 5G 기반 무선 통신 시스템, 4G 기반 무선 통신 시스템, EUTRA-NR 이중 연결(Dual Connectivity)(EN-DC/4G-5G 이중 연결) 등일 수 있지만, 이에 제한되지 않는다.
서버 분산 모듈(206b)은 MEC 플랫폼 제공자에 속하는 MEC 플랫폼일 수 있다. MEC 플랫폼은 원격 클라우드(202)와 연결되어 서버를 적어도 하나의 UE(208)에 가능한 한 가깝게 BS(206a) 중 하나에 근접하여 분산/배치할 수 있다. BS(206a)에 근접하여 배치된 서버(204)는 본 명세서에서 에지 서버(204)로서 지칭될 수 있다. 본 명세서의 실시예는 "에지 서버", "분산형 에지 클라우드", "에지 클라우드", "에지 서버 모듈", "MEC 서버", "MEC 에지 서버", "MEC 클라우드 "등과 같은 용어를 상호 교환 가능하게 사용하지만, 이에 제한되지 않고, BS(206a)에 근접하여 배치되는 원격 클라우드(202)의 적어도 하나의 서버/타사 서버/애플리케이션 서버를 지칭한다. 에지 서버/MEC 서버(204)에 존재하는 서비스, 애플리케이션, 콘텐츠 등 중 적어도 하나는 본 명세서에서 MEC 가능 서비스/애플리케이션/콘텐츠로 지칭될 수 있다.
에지 서버(204)는 서비스, 서비스에 상응하는 애플리케이션/MEC 애플리케이션, 콘텐츠 등 중 적어도 하나를 낮은 대기 시간으로 적어도 하나의 근처 UE(208)로 오프로딩할 수 있다.
일 실시예에서, 에지 서버(204)는 이의 계산/요청을 처리하기 위해 다수의 애플리케이션(다수의 애플리케이션의 서버 인스턴스(server instance))에 의해 사용될 수 있는 공통 처리 기능/모듈을 호스팅할 수 있다. 계산/요청의 예는 얼굴 검출, 사진 처리, 매체(오디오, 비디오, 이미지 등) 처리, 얼굴 태깅(face tagging), 매체에서의 객체 식별, 그래픽 관련 처리, 게임 관련 처리 등일 수 있지만, 이에 제한되지는 않는다. 본 명세서의 실시예는 처리를 위해 적어도 하나의 애플리케이션에 의해 개시된 요청을 지칭하기 위해 "애플리케이션 요청", "계산", "계산 요청", "태스크 요청" 등과 같은 용어를 상호 교환적으로 사용한다. 본 명세서의 일 실시예에서, 공통 계산 모듈은 머신 학습(ML) 기반 트레이닝 모델일 수 있다. 예를 들어, 에지 서버(204)는 에지 서버(204) 상에서 실행되는 다수의 애플리케이션에 의해 사용될 수 있는 공통 객체 트레이닝 모델(계산 모듈 중 하나)을 호스팅할 수 있다. 따라서, 에지 서버(204) 상의 공통 계산 모듈의 호스팅은 애플리케이션이 자체 계산 모듈을 가질 필요성을 제거한다.
일 실시예에서, 에지 서버(204)는 또한 계산 모듈을 다수의 애플리케이션에 대한 라이브러리로서 호스팅할 수 있다. 계산 모듈은 애플리케이션 요청을 처리하기 위해 사용될 수 있는 플러그 앤 플레이 라이브러리(plug-and-play library)일 수 있다. 에지 서버(204)는 UE(208)가 로컬로 요구에 기초하여 애플리케이션 요청을 처리하기 위한 계산 모듈을 다운로드하게 할 수 있다(계산은 다수의 애플리케이션과 관련됨). 예를 들어, 에지 서버(204)는 사진 모드(계산 모듈 중 하나)를 호스팅할 수 있음으로써, UE(208)는 카메라 애플리케이션이 사진을 처리하기 위한 요청을 개시할 때 UE(208)가 사진/이미지를 처리하기를 원할 때 적어도 하나의 에지 서버(204)로부터 사진 모드를 다운로드 할 수 있도록 한다.
본 명세서에서 언급된 UE(208)는 MEC 가능 디바이스일 수 있다. UE(208)의 예는 휴대폰, 스마트 폰, 태블릿, 패블릿, 개인 휴대 정보 단말기(personal digital assistant: PDA), 랩톱, 컴퓨터, 웨어러블 컴퓨팅 디바이스(wearable computing device), 차량 인포테인먼트 디바이스(vehicle infotainment device), 사물 인터넷(Internet of Things: IoT) 디바이스, 의료 장치, 또는 무선 모뎀에 연결되거나 무선 주파수(radio frequency: RF) 처리 능력이 있는 임의의 다른 처리 디바이스일 수 있지만, 이에 제한되지는 않는다. UE(208)는 하나 이상의 가입자 식별 모듈(Subscriber Identity Module: SIM)을 지원할 수 있다. 더욱이, UE(208)에 의해 지원되는 하나 이상의 SIM은 상이한 서비스 제공자/오퍼레이터에 의해 동작될 수 있다. UE(102)는 하나 이상의 물리적 SIM 및/또는 하나 이상의 가상 SIM을 포함할 수 있다.
UE(208)는 무선 인터페이스를 통해 적어도 하나의 BS(206a)에 연결될 수 있음으로써, UE(208)는 적어도 하나의 BS(206a)에 근접하여 위치된 적어도 하나의 에지 서버(204)에 액세스할 수 있도록 한다. UE(208)는 또한 인터넷, 유선 네트워크((LAN(Local Area Network), 이더넷 등), 무선 네트워크(Wi-Fi 네트워크, RAN, Wi-Fi 핫스팟, 블루투스, 지그비 등) 등 중 적어도 하나를 사용하여 외부 데이터베이스, 외부 서버, 애플리케이션 서버 중 적어도 하나에 연결되어, 애플리케이션에 액세스하고, 애플리케이션 요청 등을 처리할 수 있다.
일 실시예에서, UE(208)는 UE(208)가 적어도 하나의 에지 서버(204)로부터 애플리케이션, 콘텐츠, 서비스 등 중 적어도 하나에 액세스할 수 있게 하는 인에이블먼트 계층(enablement layer)/MEC 가능 계층을 포함할 수 있다. 인에이블먼트 계층은 또한 UE(208)가 처리를 위해 다수의 애플리케이션에 의해 개시된 애플리케이션 요청을 적어도 하나의 에지 서버(204)로 오프로딩할 수 있게 한다. 본 명세서의 실시예는 처리를 위해 UE(208)로부터 적어도 하나의 에지 프로세서(204)로의 애플리케이션 요청의 오프로딩을 지칭하기 위해 "MEC 컴퓨팅", "에지 컴퓨팅", "에지 처리" 등과 같은 용어를 상호 교환 가능하게 사용한다.
일 실시예에서, UE(208)는 애플리케이션 요청의 처리를 최적화하기 위해 MEC 컴퓨팅뿐만 아니라 로컬 컴퓨팅(UE(208)에 의해 로컬로 애플리케이션을 처리함)을 이용하도록 구성될 수 있다. 적어도 하나의 애플리케이션에 의한 애플리케이션 요청을 개시할 때, UE(208)는 애플리케이션 요청을 처리하기 위한 처리 모드를 동적으로 결정한다.
처리 모드는 로컬 컴퓨팅/처리, 에지 처리 및 하이브리드 처리 중 적어도 하나일 수 있다. 로컬 처리는 UE(208)에 의해 개시된 애플리케이션 요청을 로컬로 처리하는 것을 포함한다. 에지 처리는 처리를 위해 개시된 애플리케이션 요청을 적어도 하나의 에지 서버(204)로 오프로딩하는 것을 포함한다. 하이브리드 처리는 개시된 애플리케이션 요청을 병렬로 처리하기 위한 로컬 처리 및 에지 처리의 조합을 포함하며, 여기서 애플리케이션 요청은 독립적인 요청일 수 있다. 예시적인 시나리오를 고려하는데, 여기서 소셜 네트워크 애플리케이션은 2개의 애플리케이션 요청(얼굴 태깅을 위한 제1 애플리케이션 요청 및 위치에 대한 날씨 정보를 태깅하기 위한 제2 애플리케이션 요청)을 개시하고, 2개의 애플리케이션 요청은 서로 독립적이다. 이러한 시나리오에서, UE(208)는 개시된 2개의 애플리케이션 요청을 처리하기 위한 하이브리드 처리를 결정한다. 본 명세서의 일례에서, UE(208)는 제1 애플리케이션 요청을 로컬로 처리할 수 있고(로컬 처리), UE(208)는 처리하기 위해 제2 애플리케이션 요청을 적어도 하나의 에지 서버(204)로 오프로딩함으로써(에지 처리), 2개의 애플리케이션 요청이 병렬로 처리될 수 있도록 한다.
일 실시예에서, UE(208)는 적어도 하나의 머신 학습(ML) 방법을 사용하여 학습된 파라미터, 로컬 처리와 에지 처리 간의 비용 비교 등에 기초하여 애플리케이션 요청을 처리하기 위한 처리 모드를 결정할 수 있다.
도 2a 및 2b는 MEC 시스템(200)의 예시적인 블록을 도시하지만, 다른 실시예는 이에 제한되지 않는다는 것이 이해되어야 한다. 다른 실시예에서, MEC 시스템(200)은 더 적거나 더 많은 수의 블록을 포함할 수 있다. 더욱이, 블록의 라벨 또는 명칭은 예시적인 목적을 위해서만 사용되며, 본 명세서의 실시예의 범위를 제한하지 않는다. 하나 이상의 블록은 MEC 시스템(200)에서 동일하거나 실질적으로 유사한 기능을 수행하기 위해 함께 조합될 수 있다.
도 3은 본 명세서에 개시된 바와 같은 실시예에 따른 UE(208)를 도시한다. UE(208)는 통신 인터페이스(302), 디스플레이(304), 메모리(306), 로컬 프로세서(308) 및 MEC 프로세서(310)를 포함한다.
통신 인터페이스(302)는 UE(208)가 (BS(206a), 에지 서버(204), 외부 데이터베이스 등과 같은) 적어도 하나의 외부 디바이스와의 통신을 설정할 수 있도록 구성될 수 있다.
디스플레이(304)는 사용자가 UE(208)와 상호 작용할 수 있도록 구성될 수 있다. 일 실시예에서, 디스플레이(304)는 사용자로부터 사용자 선호도를 수신하도록 구성될 수 있다. 사용자 선호도는 사용자가 로컬 처리 또는 에지/MEC 처리를 애플리케이션 요청을 처리하기 위한 기본 모드(default mode)/옵션으로서 선택했는지를 나타낼 수 있다.
메모리(306)는 애플리케이션, 콘텐츠, 사용자 선호도, UE(208)에 관한 정보(예컨대, 배터리 레벨, 로컬 프로세서(308)의 처리 능력 등), 적어도 하나의 에지 서버(204)에 관한 정보 등을 저장할 수 있다. 메모리(306)는 또한 적어도 하나의 애플리케이션에 의해 개시된 애플리케이션 요청을 처리하기 위한 적어도 하나의 처리 모드를 예측하기 위한 하나 이상의 단계를 수행하기 위해 MEC 프로세서(310) 상에서 실행될 수 있는 프로그램 명령어/프로그램 코드를 저장할 수 있다. 메모리(306)는 하나 이상의 컴퓨터 판독 가능 저장 매체를 포함할 수 있다. 메모리(306)는 비휘발성 저장 요소를 포함할 수 있다. 이러한 비휘발성 저장 요소의 예는 자기 하드 디스크, 광 디스크, 플로피 디스크, 플래시 메모리, 또는 EPROM(electrical programmable memory) 또는 EEPROM(electrically erasable and programmable memory)의 형태를 포함할 수 있다. 게다가, 메모리(306)는, 일부 예에서, 비일시적 저장 매체(non-transitory storage medium)로서 간주될 수 있다. "비일시적(non-transitory)"이라는 용어는 저장 매체가 반송파 또는 전파된 신호로 구현되지 않음을 나타낼 수 있다. 그러나, 용어 "비일시적"은 메모리(306)가 이동 가능하지 않은 것으로 해석되지 않아야 한다. 일부 예에서, 메모리(306)는 메모리보다 많은 양의 정보를 저장하도록 구성될 수 있다. 특정 예에서, 비일시적 저장 매체는 시간이 지남에 따라 (예를 들어, 랜덤 액세스 메모리(RAM) 또는 캐시(cache)에서) 변경될 수 있는 데이터를 저장할 수 있다.
로컬 프로세서/온-디바이스(on-device) 프로세서(308)는 단일 프로세서, 복수의 프로세서, 다수의 동종 코어(homogenous core), 다수의 이종 코어(heterogeneous core), 상이한 종류의 다수의 중앙 처리 유닛(Central Processing Unit: CPU) 등 중 적어도 하나일 수 있다. 로컬 프로세서(308)는 다수의 애플리케이션에 의해 개시된 애플리케이션 요청을 로컬로 처리/계산하도록 구성될 수 있다. 일 실시예에서, 로컬 프로세서(308)는 MEC 프로세서(310)에 의해 적어도 하나의 에지 서버(204)로부터 다운로드되는 계산 모듈을 사용하여 애플리케이션 요청을 처리할 수 있다.
MEC 프로세서(310)는 단일 프로세서, 복수의 프로세서, 다수의 동종 코어, 다수의 이종 코어, 상이한 종류의 다수의 중앙 처리 유닛(CPU) 등 중 적어도 하나일 수 있다. 일 실시예에서, MEC 프로세서(310)는 또한 인터넷, 유선 네트워크((LAN(Local Area Network), 이더넷 등), 무선 네트워크(Wi-Fi 네트워크, RAN, Wi-Fi 핫스팟, 블루투스, 지그비 등) 등 중 적어도 하나를 사용하여 적어도 하나의 외부 데이터베이스와 통신할 수 있다. 적어도 하나의 외부 데이터베이스는 처리 결정 데이터베이스(502a), ML 기반 데이터베이스(502b), 로컬 처리 기반 데이터베이스(502c), 에지 처리 기반 데이터베이스(502d) 등 중 적어도 하나일 수 있다. 일 실시예에서, 메모리(306)는 또한 적어도 하나의 외부 데이터베이스 상에서 호스팅되는 정보를 포함할 수 있다.
처리 결정 데이터베이스(502a)는 상이한 애플리케이션에 대해 선택된 처리 모드에 관한 정보를 포함할 수 있다. ML 기반 데이터베이스(502b)는 ML 테이블/모델 또는 트레이닝/학습 데이터를 포함한다. 트레이닝 데이터는 적어도 하나의 애플리케이션의 고유 식별자(unique identifier: UID)에 대해 이전에 결정된 에지 처리 시간 및 다양한 파라미터 및 적어도 하나의 애플리케이션의 UID에 대해 결정된 로컬 처리 시간에 관한 정보를 포함할 수 있다. UID는 에지 서버 인스턴스를 가진 각각의 애플리케이션에 할당될 수 있는 일련 번호 타입의 고유 식별자일 수 있다. 에지 처리 시간은 적어도 하나의 애플리케이션에 의해 개시된 적어도 하나의 애플리케이션 요청을 처리하기 위해 적어도 하나의 에지 서버(204)에 의해 소요되는 시간일 수 있다. 로컬 처리 시간은 적어도 하나의 애플리케이션에 의해 개시된 적어도 하나의 애플리케이션 요청을 로컬로 처리하기 위해 UE(208)의 로컬 프로세서(308)에 의해 소요되는 시간일 수 있다. 다양한 파라미터는 UE(208)에 의해 지원되는 RAN의 신호 강도, RAN 타입, 네트워크 혼잡 상태 등일 수 있지만, 이에 제한되지는 않는다.
에지 처리 기반 데이터베이스(502d)는 적어도 하나의 애플리케이션의 UID에 대해 결정된 에지 처리 시간 및 다양한 파라미터에 관한 정보를 포함할 수 있다. 로컬 처리 기반 데이터베이스(502c)는 적어도 하나의 애플리케이션의 UID에 대해 결정된 로컬 처리 시간을 포함할 수 있다.
MEC 프로세서(310)는 애플리케이션 요청을 처리하기 위한 처리 모드를 결정하도록 구성될 수 있다. 실시예에서, MEC 프로세서(310)는 로컬 프로세서(308)일 수 있다. 로컬 프로세서(308)는 MEC 프로세서(310)의 적어도 하나의 의도된 기능을 수행할 수 있다.
실시예에서, MEC 프로세서(310)는 MEC 환경에서 UE(210) 내에서 애플리케이션 태스크 관리를 수행한다. MEC 프로세서(310)는 태스크/애플리케이션 요청과 연관된 애플리케이션이 MEC가 가능한지를 결정한다(애플리케이션에 대한 에지 서버의 가용성을 결정함). 애플리케이션이 MEC가 가능한 것으로 결정하면, MEC 프로세서(310)는 MEC 서버/에지 서버(204)를 사용하여 태스크/애플리케이션 요청의 처리와 연관된 복수의 네트워크 파라미터 및 시간을 측정한다. 더욱이, MEC 프로세서(310)는 UE(208) 내의 적어도 하나의 애플리케이션에 상응하는 적어도 하나의 태스크를 실행하기 위해 UE(208)의 처리 능력을 추정한다. MEC 프로세서(310)는 UE(208)가 애플리케이션 실행 시간이 최소가 되도록 MEC 서버를 사용하거나 UE(208) 내에서 MEC가 가능한 애플리케이션에 상응하는 태스크/애플리케이션 요청을 실행하도록 결정하게 한다. UE(208)는 적어도 하나의 태스크를 실행하는데 필요한 최소 시간에 기초하여 태스크/애플리케이션 요청을 실행하도록 결정할 수 있다.
도 4에 도시된 바와 같이, MEC 프로세서(310)는 수신 모듈(402), 학습 모듈(404), 비용 도출 모듈(406) 및 처리 결정 모듈(408)을 포함한다. 수신 모듈(402)은 적어도 하나의 애플리케이션에 의해 개시된 애플리케이션 요청을 수신하도록 구성될 수 있다. 적어도 하나의 애플리케이션은 UE(208)의 사용자로부터 수신된 입력/사용자와의 상호 작용에 기초하여 애플리케이션 요청을 개시할 수 있다.
학습 모듈(404)은 ML 테이블/학습 모델/ML 모델을 구축하도록 구성될 수 있다. 실시예에서, ML 테이블/학습 모델을 구축하기 위해, 학습 모듈(404)은 메모리(306), 로컬 처리 기반 데이터베이스(502c), 에지 처리 기반 데이터베이스(502d) 등 중 적어도 하나로부터 트레이닝 데이터를 인출한다(fetch). 트레이닝 데이터는 적어도 하나의 애플리케이션의 UID에 대해 이전에 결정된 에지 처리 시간 및 다양한 파라미터(신호 강도, RAN 타입, 네트워크 혼잡 상태 등), 적어도 하나의 애플리케이션의 UID에 대해 이전에 결정된 로컬 처리 시간 등일 수 있지만, 이에 제한되지는 않는다. 학습 모듈(404)은 트레이닝 데이터를 사용하여 ML 테이블/학습 모델을 구축할 수 있다. 예에서, 구축된 학습 모듈은 적어도 하나의 애플리케이션의 UID에 대한 지원 벡터 머신(Support Vector Machine: SVM) 타입 분류 모델일 수 있으며, 여기서 SVM 모델의 벡터는 트레이닝 데이터를 나타낼 수 있다. 예에서, 학습 모델은 적어도 하나의 애플리케이션의 UID에 대한 회귀(regression) ML 모델일 수 있다. 학습 모듈(404)은 ML 기반 데이터베이스를 구축된 ML 테이블/학습 모델로 업데이트할 수 있다.
실시예에서, 학습 모듈(404)은 UE(208)가 적어도 하나의 에지 서버(204)에 초기에 연결될 때 적어도 하나의 에지 서버(204)로부터 트레이닝 데이터를 인출할 수 있다. 트레이닝 데이터는 크라우드 소싱된 데이터(crowd-sourced data)의 평균(mean)일 수 있다. 실시예에서, 크라우드 소싱된 데이터의 평균을 도출하기 위해, 에지 서버(204)는 UE가 애플리케이션 서명(application signature)(pkgname)을 가진 REST 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)를 사용하여 ML 모델/학습 모델을 업로드할 수 있게 한다. 적어도 하나의 에지 서버(204)는 상이한 UE에 의해 적어도 하나의 에지 서버(204)에 업로드된 학습 모델로부터 크라우드 소싱된 데이터 값의 평균을 도출한다. 크라우드 소싱된 데이터의 평균은 UE에 의해 업로드된 학습 모델의 정보를 평균화함으로써 도출될 수 있다. 적어도 하나의 에지 서버(204)는 UE(208)가 적어도 하나의 에지 서버(204)에 처음 연결할 때 크라우드 소싱된 데이터의 도출된 평균을 UE(208)에 제공할 수 있다. 학습 모듈(404)은 크라우드 소싱된 데이터의 평균을 통해 적어도 하나의 에지 서버(204)의 에지 처리 능력을 추출하고, 에지 처리 능력으로 ML 기반 데이터베이스(502b)를 업데이트할 수 있다. 에지 처리 능력은 에지 처리 시간, 적재(load)의 측면에서의 에지 서버의 처리 능력, 에지 서버가 초당 실행할 수 있는 다수의 동작(메가헤르츠(MH) 또는 기가헤르츠(GHz)의 측면에서 표현될 수 있음), 연결된 UE에 이용 가능한 다수의 전용 코어 등 중 적어도 하나일 수 있다. 따라서, UE(208)는 학습 모델을 구축하는데 필요치 않을 수 있다.
실시예에서, 학습 모듈(404)은 적어도 하나의 에지 서버(204)로 핸드셰이크(handshake)를 수행함으로써 적어도 하나의 에지 서버(204)로부터 에지 처리 능력에 관한 정보를 인출할 수 있다. 학습 모듈(404)은 UE(208)가 인증을 위한 적어도 하나의 에지 서버(204)로 핸드셰이크를 수행할 수 있게 한다. 성공적인 인증 시에, UE(208)는 에지 처리 능력을 위해 적어도 하나의 에지 서버(204)를 요청한다. 에지 처리 능력에 대한 요청에 응답하여, 학습 모듈(404)은 적어도 하나의 에지 서버(204)로부터 에지 처리 능력과 함께 초기 트레이닝 데이터로서 크라우드 소싱된 데이터의 평균을 수신한다. 학습 모듈(404)은 ML 테이블/학습 모델을 구축하기 위해 크라우드 소싱된 데이터의 평균과 에지 처리 능력을 사용한다. 학습 모듈(404)은 구축된 ML 테이블/학습 모델을 ML 기반 데이터베이스(502b) 및 메모리(306) 중 적어도 하나에 저장한다. 저장된 ML 테이블/학습 모델은 다양한 파라미터에 대한 에지 처리 능력에 관한 정보를 포함한다.
실시예에서, 학습 모듈(404)은 또한 구축된 ML 테이블/학습 모델을 적어도 하나의 에지 서버(204) 및/또는 퍼블릭 클라우드(202)에 업로드할 수 있다. 학습 모듈(404)은 애플리케이션 서명과 함께 REST API를 사용하여 구축된 ML 테이블/학습 모델을 업로드할 수 있다.
학습 모듈(404)은 또한 구축된 ML 테이블/학습 모델을 사용하여 적어도 하나의 애플리케이션에 의해 개시된 애플리케이션 요청에 대한 에지 처리 시간 및 로컬 처리 시간을 예측하도록 구성될 수 있다. 수신 모듈(402)로부터 애플리케이션 요청을 수신하면, 학습 모듈(404)은 디바이스 상태 시스템에 액세스함으로써 현재 시점(current instance of time)에서 다양한 파라미터를 결정한다. 다양한 파라미터는 UE(208)에 의해 지원되는 RAN의 신호 강도, RAN 타입, 네트워크 혼잡 상태, 애플리케이션 요청을 개시한 적어도 하나의 애플리케이션의 UID 등일 수 있지만, 이에 제한되지는 않는다. 실시예에서, 학습 모듈(404)은 ML 기반 데이터베이스(502b) 및 메모리(306) 중 적어도 하나에 액세스하고, ML 테이블/학습 모델을 인출한다. 학습 모듈(404)은 학습된 파라미터를 키 값으로서 인출된 ML 테이블에 전달하여, 애플리케이션 요청을 개시한 적어도 하나의 애플리케이션의 UID에 대한 에지 처리 시간 및 로컬 처리 시간을 예측한다. 로컬 처리 시간 및 에지 처리 시간을 예측하기 위해, 학습 모듈(404)은 개시된 애플리케이션 요청 및 개시된 애플리케이션 요청에 대한 결정된 적어도 하나의 파라미터를 ML 테이블의 데이터와 비교하며, 여기서 ML 테이블의 데이터는 복수의 파라미터, 에지 처리 시간 및 로컬 처리 시간으로 매핑된 복수의 애플리케이션의 복수의 애플리케이션 요청을 포함한다. 학습 모듈(404)은 애플리케이션 요청, 및 개시된 애플리케이션 요청 및 개시된 애플리케이션 요청에 대한 결정된 적어도 하나의 파라미터와 일치하는 ML 테이블의 상응하는 적어도 하나의 파라미터를 식별한다. 학습 모듈(404)은 또한 식별된 요청과 매핑된 로컬 처리 시간 및 에지 처리 시간, 및 ML 테이블의 상응하는 적어도 하나의 파라미터를 개시된 애플리케이션 요청에 대한 로컬 처리 시간 및 에지 처리 시간 중 적어도 하나로서 예측한다. 학습 모듈(404)은 예측된 에지 처리 시간 및 예측된 로컬 처리 시간에 관한 정보를 비용 도출 모듈(406)에 제공한다. 학습 모듈(404)은 또한 예측된 에지 처리 시간을 처리 결정 모듈(408)에 제공한다.
비용 도출 모듈(406)은 개시된 애플리케이션 요청에 대한 비용 함수를 도출하도록 구성될 수 있다. 실시예에서, 비용 도출 모듈(406)은 예측된 에지 처리 시간, 로컬 처리 시간, UE(208)의 배터리 레벨, 및 사용자 선호도 중 적어도 하나에 기초하여 비용 함수를 도출한다. 비용 도출 모듈(406)은 메모리(306)로부터 자동으로 선택된 사용자 선호도/기본 선호도 중 적어도 하나를 인출할 수 있다. 인출된 사용자 선호도에 기초하여, 처리 결정 모듈(408)은 사용자가 적어도 하나의 애플리케이션에 의해 개시된 태스크 요청을 처리하기 위한 기본 모드로서 로컬 처리를 선택했는지를 체크한다. 처리 결정 모듈(408)은 또한 디바이스 상태 시스템을 체크함으로써 UE(208)의 배터리 레벨을 결정한다.
실시예에서, 비용 함수를 도출하기 위해, 비용 도출 모듈(406)은 에지 처리 시간, 로컬 처리 시간, UE(208)의 배터리 레벨, 및 사용자 선호도 중 적어도 하나에 적절한 가중치를 할당한다. 비용 도출 모듈(406)은 미리 정의된 테이블/데이터베이스를 사용하여 적절한 가중치를 할당할 수 있으며, 여기서 가중치는 비용 함수를 계산하는 동안 요소의 우선 순위(에지 처리 시간, 로컬 처리 시간, UE(208)의 배터리 레벨, 및 사용자 선호도)를 나타낸다. 할당된 가중치에 기초하여, 비용 도출 모듈은 비용 함수를 도출한다. 비용 함수는 아래의 식을 사용하여 도출될 수 있다.
비용 =
Figure pat00001
(에지 처리 시간, 로컬 처리 시간, 배터리 소비, 사용자 선호도)
비용 도출 모듈(406)은 도출된 비용 함수를 처리 결정 모듈(408)에 더 제공한다.
처리 결정 모듈(408)은 애플리케이션 요청을 처리하기 위한 처리 모드를 결정하도록 구성될 수 있다. 처리 결정 모듈(408)은 에지 처리 시간, 로컬 처리 시간, UE(208)의 배터리 레벨, 및 사용자 선호도 중 적어도 하나에 할당된 가중치에 기초한 비용 함수, 및 (학습 모듈(404)에 의한) 학습 모델을 사용하여 예측된 에지 처리 시간의 분석을 수행한다. 처리 결정 모듈(408)은 비용 함수 및 학습 모델을 사용하여 예측된 에지 처리 시간의 분석에 기초하여 처리 결정 파라미터를 도출한다. 분석은 로컬 처리 시간과 에지 처리 시간 사이의 비교, 사용자 선호도 및/또는 UE(208)의 배터리 레벨과 함께 로컬 처리 시간과 에지 처리 시간 사이의 비교, 배터리 레벨과 미리 정의된 배터리 레벨의 비교, 사용자 선호도의 체킹 등 중 적어도 하나를 포함할 수 있다. 미리 정의된 배터리 레벨은 사용자에 의해 정의된 배터리 레벨일 수 있다. 미리 정의된 배터리 레벨은 또한 UE(208)에 의해 자동으로 정의될 수 있다. 미리 정의된 배터리 레벨은 다수의 UE로부터(에지 처리의 사용 시의 실패 케이스로부터)의 데이터를 사용하여 학습되는 학습 값일 수 있다. 처리 결정 파라미터는 애플리케이션 요청을 처리하기 위해 사용될 수 있는 처리 모드를 나타낸다. 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나일 수 있다. 하이브리드 처리 모드의 경우에, 로컬 처리 및 에지 처리는 각각의 애플리케이션 요청에 대해 명시될 수 있다. 처리 결정 모듈(408)은 처리 결정 데이터베이스(502a)를 결정된 처리 모드로 업데이트한다.
예시적인 시나리오를 고려하는데, 여기서 카메라 애플리케이션은 2개의 애플리케이션 요청(예컨대, 사진 편집 및 위치 태깅)을 동시에 개시한다. 이러한 시나리오에서, 처리 결정 모듈(408)은 2개의 애플리케이션 요청을 처리하기 위한 처리 결정 파라미터를 생성한다. 일례에서, 처리 결정 파라미터를 생성하기 위해, 처리 결정 모듈(408)은 로컬 처리 시간과 에지 처리 시간을 비교한다. 로컬 처리 시간이 에지 처리 시간보다 작은 경우, 처리 결정 모듈(408)은 카메라 애플리케이션의 2개의 애플리케이션 요청을 처리하기 위한 로컬 처리로서 처리 결정 파라미터를 생성한다. 로컬 처리 시간이 에지 처리 시간보다 큰 경우, 처리 결정 모듈(408)은 사용자가 로컬 처리를 기본 처리 모드로서 선택했는지를 체크하기 위해 사용자 선호도에 액세스하고/하거나 UE(208)의 배터리 레벨을 체크한다. 사용자가 로컬 처리를 기본 처리 모드로서 선택했고/했거나 배터리 레벨이 미리 정의된 배터리 레벨보다 큰 경우, 처리 결정 모듈(404)은 처리 결정 파라미터를 카메라 애플리케이션의 애플리케이션 요청을 처리하기 위한 로컬 처리 모드로서 생성한다. 사용자가 로컬 처리를 기본 처리 모드로서 선택하지 않았고/않았거나 배터리 레벨이 미리 정의된 배터리 레벨보다 작은 경우, 처리 결정 모듈(404)은 처리 결정 파라미터를 카메라 애플리케이션의 애플리케이션 요청을 처리하기 위한 에지 처리 모드로서 생성한다.
예시적인 시나리오를 고려하는데, 여기서 소셜 네트워킹 애플리케이션은 2개의 애플리케이션 요청(예컨대, 사진에 존재하는 사용자의 얼굴, 및 사진이 캡쳐된 위치에 대한 날씨 업데이트를 식별하기 위한 것)을 동시에 개시하고, 2개의 애플리케이션 요청은 동시에 처리될 수 있다. 이러한 시나리오에서, 처리 결정 모듈(408)은 2개의 애플리케이션 요청을 처리하기 위한 처리 결정 파라미터를 생성한다. 일례에서, 처리 결정 모듈(408)은 사용자 선호도 및 배터리 레벨과 함께 로컬 처리 시간 및 에지 처리 시간을 비교한다. 일례에서, 처리 결정 모듈(408)은 로컬 처리 시간이 에지 처리 시간보다 작고, 배터리 레벨이 미리 정의된 임계 값보다 크다고 결정하고/하거나, 사용자가 로컬 처리를 소셜 네트워킹 애플리케이션의 제1 요청(얼굴을 식별함)을 처리하기 위한 기본 모드로서 선택했다고 간주한다. 처리 결정 모듈(408)은 또한 로컬 처리 시간이 에지 처리 시간보다 크고, 사용자는 로컬 처리를 (날씨 업데이트를 위한) 제2 요청을 처리하기 위한 기본 모드로서 선택하지 않았다고 결정한다. 이러한 경우에, 처리 결정 모듈(408)은 제1 요청을 처리하기 위한 로컬 처리 및 소셜 네트워킹 애플리케이션의 제2 요청을 처리하기 위한 에지 처리를 나타냄으로써 처리 결정 파라미터를 하이브리드 처리로서 생성한다.
처리 결정 파라미터가 생성되면, 처리 결정 모듈(408)은 처리 결정 파라미터가 로컬 처리를 나타내는지를 체크한다. 처리 결정 파라미터가 로컬 처리를 나타내는 경우, 처리 결정 모듈(408)은 애플리케이션 요청을 처리하기 위한 명령어를 로컬 프로세서(308)에 제공한다.
실시예에서, 처리 결정 모듈(408)은 적어도 하나의 에지 서버(204)로부터 개시된 애플리케이션 요청에 상응하는 계산 모듈/라이브러리를 다운로드할 수 있다. 처리 결정 모듈(408)은 다운로드된 계산 모듈을 애플리케이션 요청을 처리하기 위한 로컬 프로세서(308)에 제공한다.
예시적인 시나리오를 고려하는데, 여기서 카메라 애플리케이션은 이미지/사진을 처리하기 위한 애플리케이션 요청을 개시한다. 이러한 시나리오에서, 처리 결정 모듈(408)은 로컬 처리를 이미지를 처리하기 위한 최상의 모드로서 결정한다. 카메라 애플리케이션에 대한 로컬 처리가 결정되면, 처리 결정 모듈(408)은 사진을 처리하기 위해 요구에 기초하여 적어도 하나의 에지 서버(204)로부터 사진 모드(계산 모듈)를 다운로드한다. 따라서, UE(208) 상의 애플리케이션이 자체의 계산 모듈을 가질 필요성을 제거한다.
처리 결정 파라미터가 에지 처리를 나타내는 경우, 처리 결정 모듈(408)은 애플리케이션 요청 및 상응하는 애플리케이션의 UID를 처리를 위해 (ETSI 사양에 따라 결정되는 가장 가까운 에지 서버일 수 있는) 적어도 하나의 에지 서버(204)로 송신한다.
처리 결정 파라미터가 애플리케이션 요청을 처리하기 위한 하이브리드 처리(로컬 처리 및 에지 처리의 요구)를 나타내는 경우. 처리 결정 모듈 (408)은 로컬 처리를 위해 명시된 애플리케이션 요청 및 상응하는 애플리케이션의 UID와 함께 명령어를 로컬로 처리하기 위한 로컬 애플리케이션(308)에 제공한다. 처리 결정 모듈(408)은 에지 처리를 위해 명시된 애플리케이션 요청 및 상응하는 애플리케이션의 UID를 처리를 위해 적어도 하나의 에지 서버로 송신한다.
도 3 및 도 4는 UE(208)의 예시적인 블록을 도시하지만, 다른 실시예는 이에 제한되지 않는 것으로 이해되어야 한다. 다른 실시예에서, UE(208)는 더 적거나 더 많은 수의 블록을 포함할 수 있다. 더욱이, 블록의 라벨 또는 명칭은 예시적인 목적을 위해서만 사용되며, 본 명세서의 실시예의 범위를 제한하지 않는다. 하나 이상의 블록은 UE(208)에서 동일하거나 실질적으로 유사한 기능을 수행하기 위해 함께 조합될 수 있다.
도 5는 본 명세서에 개시된 바와 같은 실시예에 따른 예시적인 MEC 시스템(200)을 도시한다. 본 명세서의 예에서, UE(208)는 적어도 하나의 BS(206a)에 연결될 수 있고, BS(206a) 근처에 배치되는 적어도 하나의 에지 서버(204)로부터 서비스, 애플리케이션, 콘텐츠 등에 액세스할 수 있다. UE(208)는 적어도 하나의 RAN을 사용하여 적어도 하나의 BS(206a)에 연결될 수 있다.
UE(208)는 메모리(306), 로컬 프로세서(308) 및 MEC 프로세서(310)를 포함한다. 메모리(306)는 복수의 애플리케이션을 포함한다. 로컬 프로세서(308)는 복수의 애플리케이션에 의해 개시된 애플리케이션 요청을 처리하도록 구성될 수 있다. MEC 프로세서(310)는 개시된 애플리케이션 요청을 인터셉트(intercept)하고, 개시된 애플리케이션 요청을 처리하기 위한 최상의 처리 모드를 선택/결정하도록 구성될 수 있다. 실시예에서, MEC 프로세서(310)는 비용 함수 및 ML 테이블/학습 모델을 사용하여 예측된 에지 처리 시간의 분석에 기초하여 최상의 처리 모드를 결정할 수 있다. 최상의 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나일 수 있다. 따라서, 낮은 대기 시간으로 애플리케이션 요청을 처리하기 위해 로컬 컴퓨팅과 함께 MEC 컴퓨팅의 최적 활용이 가능하다.
도 6은 본 명세서에 개시된 바와 같은 실시예에 따라 낮은 대기 시간으로 UE(208) 상의 애플리케이션 요청의 처리를 최적화하는 방법을 도시하는 예시적인 흐름도이다. 본 명세서의 실시예는 UE(208)의 MEC 프로세서(310)가 UE(208) 상의 애플리케이션 요청의 최적화된 처리를 위한 처리 모드를 결정할 수 있게 한다.
MEC 프로세서(310)는 적어도 하나의 애플리케이션으로부터 애플리케이션 요청을 수신한다(단계(602)). 애플리케이션 요청의 최적 처리를 위해, MEC 프로세서(310)는 개시된 애플리케이션 요청에 대해 도출된 비용 함수 및 ML 테이블/학습 모델을 사용하여 예측된 에지 처리 시간의 분석에 기초하여 처리 결정 파라미터를 생성한다(단계(604)). MEC 프로세서(310)는 애플리케이션 요청을 처리하기 위해 결정된 처리 모드를 결정하기 위해 처리 결정 파라미터를 체크한다(단계(606)). 로컬 처리가 결정되지 않은 것으로 결정하면(단계(606), No), MEC 프로세서(310)는 개시된 애플리케이션 요청의 클라우드 기반 처리를 위해 적어도 하나의 에지 서버(204)/MEC를 사용한다(단계(610)).
로컬 처리를 결정할 때(단계(606), Yes), MEC 프로세서(310)는 MEC가 UE(208) 상에서 활성화되고, 에지 서버(204)가 이용 가능할지라도 개시된 애플리케이션 요청을 처리하도록 로컬 프로세서(308)에게 지시한다(단계(608)). 따라서, 에지 처리뿐만 아니라 로컬 처리의 최상의 조합을 선택함으로써 애플리케이션 요청의 처리가 효율적으로 수행될 수 있다.
도 7은 본 명세서에 개시된 바와 같은 실시예에 따라 UE(208) 상에서 애플리케이션 요청을 처리하기 위한 처리 모드를 결정하는 방법을 도시하는 예시적인 흐름도이다. MEC 프로세서(310)는 적어도 하나의 애플리케이션에 의해 개시된 애플리케이션 요청을 수신한다(단계(702)). MEC 프로세서(310)는 디바이스 상태 시스템에 액세스함으로써 다양한 파라미터를 학습한다. 파라미터는 UE(208)에 의해 지원되는 RAN의 신호 강도, RAN 타입, 네트워크 혼잡 상태, 상응하는 애플리케이션의 UID 등일 수 있지만, 이에 제한되지는 않는다.
MEC 프로세서(310)는 ML 기반 데이터베이스에 액세스하고, 구축된 ML 테이블/학습 모델을 인출한다(단계(704)). MEC 프로세서(310)는 학습된 파라미터를 ML 테이블/학습 모델과 더 비교하고, 개시된 애플리케이션 요청을 처리하기 위한 에지 처리 시간 및 로컬 처리 시간을 예측한다. MEC 프로세서(310)는 로컬 처리 시간, 에지 처리 시간, 배터리 레벨 및 사용자 선호도 중 적어도 하나를 사용하여 비용 함수를 도출하고(단계(706)), 에지 처리 시간을 로컬 처리 시간과 비교한다.
MEC 프로세서(310)는 예측된 로컬 처리 시간이 예측된 에지 처리 시간보다 작은지를 체크한다(단계(708)). MEC 프로세서(310)는 로컬 처리 시간이 예측된 에지 처리 시간보다 작은 경우에 로컬 처리를 애플리케이션의 태스크 요청을 처리하기 위한 최상의 모드로 결정한다(단계(710)). 로컬 처리 시간이 예측된 에지 처리 시간보다 작지 않은 경우, MEC 프로세서(310)는 사용자가 로컬 처리를 애플리케이션 요청을 개시한 적어도 하나의 애플리케이션에 대한 기본 모드로 선택했는지 및/또는 배터리 레벨이 미리 정의된 레벨(예를 들어: 5%)보다 큰지를 체크한다(단계(712)). 사용자가 로컬 처리를 기본 모드로 선택했고/했거나 배터리 레벨이 미리 정의된 값보다 큰 경우, MEC 프로세서(310)는 로컬 처리를 개시된 애플리케이션 요청을 처리하기 위한 최상의 모드로서 결정한다(단계(714)). 사용자가 로컬 처리를 기본 모드로 선택하지 않았고/않았거나 배터리 레벨이 미리 정의된 값보다 크지 않은 경우, MEC 프로세서(310)는 에지 처리를 개시된 애플리케이션 요청을 처리하기 위한 최상의 모드로서 결정한다(단계(716)).
도 8a, 8b 및 8c는 본 명세서에 개시된 바와 같은 실시예에 따라 ML 테이블/학습 모델의 구축을 위해 사용된 트레이닝 데이터를 도시하는 예시적인 다이어그램이다. 본 명세서의 실시예는 MEC 프로세서(310)가 애플리케이션 요청의 처리를 최적화하기 위해 처리 모드를 결정하기 위한 ML 테이블/학습 모델을 구축할 수 있게 한다.
실시예에서, ML 테이블/학습 모델을 구축하기 위해, MEC 프로세서(310)는 로컬 처리 기반 데이터베이스(502c) 및 에지 처리 기반 데이터베이스(502d)에 액세스함으로써 트레이닝 데이터를 인출한다. 로컬 처리 기반 데이터베이스(502c)로부터 인출된 트레이닝 데이터는 애플리케이션의 다양한 UID에 대한 로컬 처리에 관한 정보를 포함할 수 있다. 에지 처리 기반 데이터베이스(502d)로부터 인출된 트레이닝 데이터는 애플리케이션의 다양한 UID 및 다양한 파라미터(예컨대, 신호 강도, RAN 타입, 네트워크 혼잡 상태 등)에 대한 에지 처리 시간에 관한 정보를 포함한다. 로컬 처리 기반 데이터베이스 및 에지 처리 기반 데이터베이스로부터 인출된 예시적인 트레이닝 데이터는 도 8a에 도시된다. MEC 프로세서(310)는 트레이닝 데이터를 사용하여 애플리케이션의 각각의 UID에 대한 ML 모델/학습 모델을 구축한다. 본 명세서의 예에서, 구축된 ML 테이블/학습 모델은 도 8a에 도시된 바와 같은 ML 회귀 모델일 수 있다. MEC 프로세서(310)는 ML 회귀 모델을 사용하여 개시된 애플리케이션 요청에 대한 에지 처리 시간을 예측할 수 있다.
일 실시예에서, MEC 프로세서(310)는 도 8b에 도시된 바와 같이 구축된 ML 회귀 모델을 적어도 하나의 에지 서버(204)에 업로드할 수 있다. MEC 프로세서(310)는 애플리케이션 서명으로서 고유 키를 갖는 에지 처리 능력에 대한 REST API를 사용하여 ML 회귀 모델을 업로드할 수 있다.
일 실시예에서, MEC 프로세서(310)는 처음으로 에지 서버(204)를 연결할 때 적어도 하나의 에지 서버(204)로부터 트레이닝 데이터/회귀 모델(ML 테이블/학습 모델)을 요청할 수 있다. MEC 프로세서(310)로부터의 요청에 응답하여, 에지 서버(204)는 상이한 UE에 의해 업로드된 ML 회귀 모델로부터 크라우드 소싱된 데이터의 평균을 도출한다. 에지 서버(204)는 도 8b에 도시된 바와 같이 ML 회귀 모델로부터의 크라우드 소싱된 데이터의 평균을 트레이닝 데이터로서 MEC 프로세서(310)에 전달한다. 따라서, MEC 프로세서(310)는 ML 테이블/학습 모델을 독립적으로 구축할 필요가 없을 수 있다.
일 실시예에서, MEC 프로세서(310)는 에지 서버(204)로부터 수신된 에지 처리 능력에 기초하여 ML 테이블/학습 모델을 구축할 수 있다. 도 8c에 도시된 바와 같이, 에지 처리 능력을 수신하기 위해, MEC 프로세서(310)는 UE(208)의 인증을 위해 적어도 하나의 에지 서버(204)와의 핸드셰이크를 수행한다(1). 에지 서버(204)는 UE(208)의 인증을 수행하고, MEC 프로세서(310)에게 성공적인 인증에 대해 통지한다(2).
인증이 성공적이면, MEC 프로세서(310)는 처리 능력에 대한 적어도 하나의 에지 서버(204)를 요청한다(3). 처리 능력에 대한 요청에 응답하여, 에지 서버(204)는 (태스크 요청을 개시한) 적어도 하나의 애플리케이션에 대해 크라우드 소싱된 데이터/값의 평균을 전달한다(4). 크라우드 소싱된 데이터의 평균은 초기 트레이닝 세트로서 사용될 수 있다. 그 후, 에지 서버(204)는 또한 에지 서버(204)의 처리 능력을 MEC 프로세서(310)에 전달한다(5). MEC 프로세서(310)는 크라우드 소싱된 데이터의 평균 및 에지 처리 능력을 사용하여 ML 테이블/학습 모델을 구축할 수 있다.
도 9는 본 명세서에 개시된 바와 같은 실시예에 따라 애플리케이션 요청의 로컬 처리를 위해 에지 서버로부터의 계산 라이브러리의 다운로딩을 도시하는 예시적인 다이어그램이다. 본 명세서의 실시예는 MEC 프로세서(310)가 UE(108) 상의 애플리케이션 요청을 로컬로 처리하기 위한 계산 모듈을 다운로드할 수 있게 한다. 일 실시예에서, MEC 프로세서(310)는 MEC 가능 영역(UE(208)에 대한 에지 서버(204)의 이용 가능성)으로부터 비-MEC 가능 영역(UE(208)에 대한 에지 서버(204)의 이용 불가능성)으로의 UE(208)의 이동에 기초하여 계산 모듈의 다운로딩을 트리거링할 수 있다. 일 실시예에서, MEC 프로세서(310)는 애플리케이션 요청을 처리하기 위한 로컬 처리를 결정할 때 에지 서버(204)로부터의 계산 모듈의 다운로딩을 트리거링할 수 있다.
MEC 프로세서(310)는 특정 애플리케이션의 요청을 처리하기 위한 라이브러리로서 계산 모듈을 다운로딩하기 위한 요청을 에지 서버(204)에 송신한다. 계산 모듈에 대한 요청에 응답하여, 에지 서버(204)는 MEC 프로세서(310)가 계산 모듈을 다운로딩할 수 있게 하며, 이는 특정 애플리케이션의 요청을 처리하기 위한 플러그 앤 플레이 서비스(plug-n-play service)로서 사용될 수 있다.
도 10은 본 명세서에 개시된 바와 같은 실시예에 따라 애플리케이션 요청의 처리를 최적화하는 방법을 도시하는 흐름도(1000)이다.
단계(1002)에서, 방법은 UE(208)가 적어도 하나의 애플리케이션에 의해 개시된 적어도 하나의 애플리케이션 요청을 수신하는 단계를 포함한다.
단계(1004)에서, 방법은 UE(208)가 수신된 적어도 하나의 애플리케이션 요청이 MEC 가능한지를 결정하는 단계를 포함한다.
단계(1006)에서, 방법은 UE(208)가 수신된 적어도 하나의 애플리케이션 요청이 MEC 가능한 경우에 수신된 적어도 하나의 애플리케이션 요청에 대한 처리 모드를 결정하는 단계를 포함한다. 처리 모드는 MEC 컴퓨팅 및 로컬 컴퓨팅 중 적어도 하나를 사용하여 결정될 수 있다. 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나일 수 있다.
단계(1008)에서, 방법은 UE(208)가 수신된 적어도 하나의 애플리케이션 요청에 대해 결정된 처리 모드에 기초하여 적어도 하나의 동작을 수행하는 단계를 포함한다. 적어도 하나의 동작은 UE(208)에 의해 개시된 적어도 하나의 애플리케이션 요청을 로컬로 처리하는 것, 처리를 위해 개시된 적어도 하나의 애플리케이션 요청을 UE(208)에 의해 에지 서버(204)로 오프로딩하는 것, 로컬 처리 및 에지 처리와 조합하여 개시된 적어도 하나의 요청을 처리하는 것 중 적어도 하나를 포함한다.
본 명세서의 실시예는 애플리케이션 요청을 처리하기 위해 사용될 수 있는 처리 모드를 제공한다. 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나일 수 있다. 본 명세서의 실시예는 애플리케이션이 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나를 이용하여 애플리케이션과 연관된 고유 API(Application Program Interface)의 세트를 사용하여 이의 태스크 요청을 처리/계산할 수 있게 한다.
본 명세서의 실시예는 사용자 디바이스 내에서 고유 규칙 기반(머신 학습(ML)) 모듈을 제공하며, 이는 에지 처리 시간의 예측을 위한 트레이닝 모델을 제공할 수 있다. 본 명세서의 실시예는 태스크 요청을 개시한 애플리케이션에 대한 비용 함수를 도출한다. 비용 함수는 로컬 처리 시간, 에지 처리 시간, 사용자 선호도 및 UE의 배터리 레벨 중 적어도 하나에 기초하여 도출될 수 있다. 본 명세서의 실시예는 애플리케이션 요청을 처리하기 위한 처리 모드를 결정하기 위해 비용 함수 및 예측된 에지 처리 시간을 분석한다.
본 명세서의 실시예는 UE가 에지 서버로부터 키 값으로서 애플리케이션 서명을 갖는 크라우드 소싱 ML 트레이닝 모듈을 사용하여 에지 서버 처리 능력을 획득할 수 있게 한다. 본 명세서의 실시예는 UE가 서버 인프라 상에서 호스팅되는 에지 계산 플랫폼으로부터 에지 서버 처리 능력을 획득할 수 있게 한다.
본 명세서의 실시예는 UE가 애플리케이션 요청을 처리하기 위해 에지 서버로부터 플러그 앤 플레이 계산 라이브러리로서 계산 모듈을 다운로드할 수 있게 하는 ML 기반 트리거를 제공한다.
본 명세서의 실시예는 에지 서버가 공통 컴퓨팅 모듈을 호스팅할 수 있게 하며, 이는 에지 인프라 상에서 실행되는 애플리케이션 서버 인스턴스에 의해 온디맨드(on-demand) 다운로드될 수 있다.
본 명세서에 개시된 실시예는 적어도 하나의 하드웨어 디바이스 상에서 실행되고, 요소를 제어하기 위해 네트워크 관리 기능을 수행하는 적어도 하나의 소프트웨어 프로그램을 통해 구현될 수 있다. 도 2a, 2b, 3 및 4에 도시된 요소는 하드웨어 디바이스, 또는 하드웨어 디바이스 및 소프트웨어 모듈의 조합 중 적어도 하나일 수 있다.
본 명세서에 개시된 실시예는 애플리케이션 요청의 처리를 최적화하는 방법 및 시스템을 설명한다. 따라서, 보호의 범위는 이러한 프로그램으로 확장되고, 이 내에 메시지를 갖는 컴퓨터 판독 가능 수단 외에, 이러한 컴퓨터 판독 가능 저장 수단은 프로그램이 서버 또는 모바일 디바이스 또는 임의의 적절한 프로그램 가능 디바이스 상에서 실행될 때 방법의 하나 이상의 단계의 구현을 위한 프로그램 코드 수단을 포함하는 것으로 이해된다. 이러한 방법은 바람직한 실시예에서 예를 들어 VHDL(Very high speed integrated circuit Hardware Description Language) 다른 프로그래밍 언어로 작성되거나 적어도 하나의 하드웨어 디바이스 상에서 실행되는 하나 이상의 VHDL 또는 여러 소프트웨어 모듈에 의해 구현되는 소프트웨어 프로그램을 통해 또는 소프트웨어 프로그램과 함께 구현된다. 하드웨어 디바이스는 프로그래밍될 수 있는 모든 종류의 휴대용 디바이스일 수 있다. 디바이스는 또한 예를 들어 ASIC와 같은 하드웨어 수단, 또는 하드웨어 및 소프트웨어 수단, 예를 들어 ASIC 및 FPGA의 조합, 또는 적어도 하나의 마이크로 프로세서 및 이 내에 위치된 적어도 하나의 메모리일 수 있는 수단을 포함할 수 있다. 본 명세서에 설명된 방법 실시예는 부분적으로 하드웨어 및 부분적으로 소프트웨어로 구현될 수 있다. 대안으로, 본 발명은 예를 들어 복수의 CPU를 사용하여 상이한 하드웨어 디바이스 상에서 구현될 수 있다.
특정 실시예에 대한 상술한 설명은 다른 것이 현재의 지식을 적용함으로써 일반적인 개념을 벗어나지 않고 다양한 애플리케이션에 대해 이러한 특정 실시예를 쉽게 수정하고/하거나 적응할 수 있도록 본 명세서의 실시예의 일반적인 본질을 충분히 밝힐 것이며, 따라서, 이러한 적응 및 수정은 개시된 실시예의 의미 및 등가물의 범위 내에서 이해되도록 의도되어야 한다. 본 명세서에 사용된 어구 또는 용어는 설명을 위한 것이며, 제한하려는 것이 아님을 이해해야 한다. 따라서, 본 명세서의 실시예가 실시예의 측면에서 설명되었지만, 통상의 기술자는 본 명세서의 실시예가 본 명세서에 기술된 바와 같은 실시예의 사상 및 범위 내에서 수정하여 실시될 수 있음을 인식할 것이다.

Claims (20)

  1. 애플리케이션 요청의 처리를 최적화하는 방법에 있어서,
    사용자 디바이스(UE)가 적어도 하나의 애플리케이션에 의해 개시된 적어도 하나의 애플리케이션 요청을 수신하는 단계;
    상기 UE가 수신된 적어도 하나의 애플리케이션 요청이 다중 액세스 에지 컴퓨팅(MEC)이 가능한지를 식별하는 단계;
    상기 수신된 적어도 하나의 애플리케이션 요청이 MEC가 가능한 경우에 상기 UE가 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 처리 모드를 결정하는 단계로서, 상기 처리 모드는 상기 MEC 및 로컬 컴퓨팅 중 적어도 하나를 사용하여 결정되는, 상기 결정하는 단계; 및
    상기 UE가 상기 수신된 적어도 하나의 애플리케이션 요청에 대해 결정된 상기 처리 모드에 기초하여 적어도 하나의 동작을 수행하는 단계를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  2. 제 1 항에 있어서,
    상기 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  3. 제 1 항에 있어서,
    상기 UE가 상기 처리 모드를 결정하는 단계는,
    상기 수신된 적어도 하나의 애플리케이션 요청에 대한 디바이스 상태 시스템에 액세스함으로써 적어도 하나의 파라미터를 검출하는 단계로서, 상기 적어도 하나의 파라미터는 상기 UE에 의해 지원되는 무선 액세스 네트워크(RAN)의 신호 강도, RAN의 타입, 상기 RAN과 연관된 네트워크 혼잡 상태, 상기 수신된 적어도 하나의 애플리케이션 요청과 연관된 적어도 하나의 애플리케이션의 고유 식별자(UID) 중 적어도 하나를 포함하는, 상기 검출하는 단계;
    상기 수신된 적어도 하나의 애플리케이션 요청 및 상기 결정된 적어도 하나의 파라미터를 키 값으로서 적어도 하나의 머신 학습(ML) 테이블에 전달함으로써 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 로컬 처리 시간 및 에지 처리 시간 중 적어도 하나를 결정하는 단계;
    상기 수신된 적어도 하나의 애플리케이션 요청에 대한 비용 함수를 도출하는 단계; 및
    상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 비용 함수 및 상기 결정된 로컬 처리 시간 및 에지 처리 시간 중 적어도 하나의 분석에 기초하여 처리 결정 파라미터를 생성하는 단계를 포함하고,
    상기 처리 결정 파라미터는 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 처리 모드를 나타내는, 애플리케이션 요청의 처리를 최적화하는 방법.
  4. 제 3 항에 있어서,
    상기 UE가 로컬 처리 데이터베이스 및 에지 처리 데이터베이스 중 적어도 하나로부터 트레이닝 데이터를 인출함으로써 상기 적어도 하나의 ML 테이블을 구축하는 단계를 포함하고,
    상기 로컬 처리 데이터베이스로부터 인출된 상기 트레이닝 데이터는 복수의 애플리케이션 요청에 대해 이전에 결정된 로컬 처리 시간에 관한 정보를 포함하고, 상기 에지 처리 데이터베이스로부터 인출된 상기 트레이닝 데이터는 상기 복수의 애플리케이션 요청에 대해 이전에 결정된 에지 처리 시간, 및 상기 UE에 의해 지원되는 상기 RAN의 신호 강도, 상기 RAN의 타입, 상기 RAN과 연관된 상기 네트워크 혼잡 상태 중 적어도 하나에 관한 정보를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  5. 제 3 항에 있어서,
    상기 UE가 적어도 하나의 에지 서버로부터 에지 처리 능력을 수신함으로써 상기 적어도 하나의 ML 테이블을 구축하는 단계를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  6. 제 5 항에 있어서,
    상기 UE가 상기 에지 처리 능력을 수신하는 단계는,
    상기 적어도 하나의 에지 서버로부터 크라우드 소싱된 데이터의 평균을 통해 상기 에지 처리 능력을 수신하는 단계로서, 상기 크라우드 소싱된 데이터의 평균은 복수의 사용자 장치(UE)에 의해 상기 적어도 하나의 에지 서버에 업로드된 복수의 ML 테이블로부터 상기 적어도 하나의 에지 서버에 의해 도출되는, 상기 수신하는 단계; 및
    상기 적어도 하나의 에지 서버와의 핸드셰이크를 수행함으로써 상기적어도 하나의 에지 서버로부터 크라우드 소싱된 데이터의 평균과 함께 상기 에지 처리 능력을 수신하는 단계 중 적어도 하나를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  7. 제 3 항에 있어서,
    상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 로컬 처리 시간 및 상기 에지 처리 시간 중 적어도 하나를 결정하는 단계는,
    상기 수신된 적어도 하나의 애플리케이션 요청 및 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 결정된 적어도 하나의 파라미터를 상기 ML 테이블의 데이터와 비교하는 단계로서, 상기 ML 테이블의 데이터는 복수의 파라미터, 에지 처리 시간 및 로컬 처리 시간과 매핑된 복수의 애플리케이션의 복수의 애플리케이션 요청을 포함하는, 상기 비교하는 단계;
    상기 수신된 적어도 하나의 애플리케이션 요청 및 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 결정된 적어도 하나의 파라미터와 일치하는 적어도 하나의 애플리케이션 요청 및 ML 테이블의 상응하는 적어도 하나의 파라미터를 식별하는 단계; 및
    상기 식별된 적어도 하나의 애플리케이션 요청 및 상기 ML 테이블의 상기 상응하는 적어도 하나의 파라미터와 매핑된 상기 로컬 처리 시간 및 상기 에지 처리 시간 중 적어도 하나를 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 로컬 처리 시간 및 상기 에지 처리 시간 중 적어도 하나로서 결정하는 단계를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  8. 제 3 항에 있어서,
    상기 비용 함수를 도출하는 단계는,
    상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 결정된 로컬 처리 시간, 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 결정된 에지 처리 시간, 상기 UE의 배터리 레벨, 및 적어도 하나의 사용자 선호도 중 적어도 하나에 적어도 하나의 가중치를 할당하는 단계; 및
    상기 결정된 로컬 처리 시간, 상기 결정된 에지 처리 시간, 상기 UE의 배터리 레벨 및 상기 적어도 하나의 사용자 선호도 중 적어도 하나에 할당된 적어도 하나의 가중치의 함수로서 상기 비용 함수를 도출하는 단계를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  9. 제 3 항에 있어서,
    상기 처리 결정 파라미터를 생성하는 단계는,
    상기 수신된 적어도 하나의 애플리케이션 요청에 대해 상기 도출된 비용 함수 및 상기 결정된 에지 처리 시간에 대한 분석을 수행하는 단계로서, 상기 도출된 비용 함수에 대한 분석을 수행하는 단계는 상기 결정된 로컬 처리 시간, 상기 결정된 에지 처리 시간, 상기 UE의 배터리 레벨, 및 연관된 적어도 하나의 가중치에 기초한 상기 적어도 하나의 사용자 선호도 중 적어도 하나 간의 비교를 수행하는 단계를 포함하는, 상기 수행하는 단계; 및
    수행된 분석에 기초하여 상기 처리 결정 파라미터를 생성하는 단계를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  10. 제 1 항에 있어서,
    상기 UE가 상기 적어도 하나의 동작을 수행하는 단계는,
    상기 결정된 처리 모드가 로컬 처리인 경우에 상기 수신된 적어도 하나의 애플리케이션 요청을 로컬로 처리하는 단계;
    상기 결정된 처리 모드가 에지 처리인 경우에 상기 수신된 적어도 하나의 애플리케이션 요청을 상기 적어도 하나의 에지 서버로 오프로딩하는 단계; 및
    상기 결정된 처리 모드가 하이브리드 처리인 경우에 상기 로컬 처리 및 상기 에지 처리의 조합을 이용하여 상기 수신된 적어도 하나의 애플리케이션 요청을 처리하는 단계 중 적어도 하나를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  11. 제 1 항에 있어서,
    상기 UE가 상기 적어도 하나의 애플리케이션 요청을 로컬로 처리하기 위해 상기 적어도 하나의 에지 서버로부터의 라이브러리로서 적어도 하나의 계산 모듈을 다운로딩하는 단계를 포함하는, 애플리케이션 요청의 처리를 최적화하는 방법.
  12. 사용자 장치(UE)에 있어서,
    메모리; 및
    상기 메모리에 결합된 제어부를 포함하는데, 상기 제어부는,
    적어도 하나의 애플리케이션에 의해 개시된 적어도 하나의 애플리케이션 요청을 수신하고;
    수신된 적어도 하나의 애플리케이션 요청이 MEC 가능한지를 식별하고;
    상기 수신된 적어도 하나의 애플리케이션 요청이 MEC 가능한 경우에 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 처리 모드 - 상기 처리 모드는 MEC 컴퓨팅 및 로컬 컴퓨팅 중 적어도 하나를 사용하여 결정됨 - 를 결정하며;
    상기 수신된 적어도 하나의 애플리케이션 요청에 대해 결정된 상기 처리 모드에 기초하여 적어도 하나의 동작을 수행하도록 구성되는, 사용자 장치(UE).
  13. 제 12 항에 있어서,
    상기 처리 모드는 로컬 처리, 에지 처리 및 하이브리드 처리 중 적어도 하나를 포함하는, 사용자 장치(UE).
  14. 제 12 항에 있어서,
    상기 제어부는,
    상기 적어도 하나의 애플리케이션 요청을 개시할 때 적어도 하나의 파라미터 - 상기 적어도 하나의 파라미터는 상기 UE에 의해 지원되는 적어도 하나의 무선 액세스 네트워크(RAN)의 신호 강도, 상기 적어도 하나의 RAN의 타입. 상기 적어도 하나의 RAN과 연관된 네트워크 혼잡 상태, 상기 적어도 하나의 애플리케이션의 고유 식별자(UID) 중 적어도 하나를 포함함 - 를 결정하고;
    결정된 적어도 하나의 파라미터 및 적어도 하나의 머신 학습(ML) 테이블을 사용하여 수신된 적어도 하나의 애플리케이션 요청에 대한 로컬 처리 시간 및 에지 처리 시간 중 적어도 하나를 결정하고;
    상기 수신된 적어도 하나의 애플리케이션 요청에 대한 비용 함수를 도출하며;
    상기 수신된 적어도 하나의 애플리케이션 요청에 대한 비용 함수 및 상기 결정된 로컬 처리 시간 및 에지 처리 시간 중 적어도 하나의 분석에 기초하여 처리 결정 파라미터 - 상기 처리 결정 파라미터는 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 처리 모드를 나타냄 - 를 생성하도록 더 구성되는, 사용자 장치(UE).
  15. 제 14 항에 있어서,
    상기 제어부는,
    상기 UE가 로컬 처리 데이터베이스 및 에지 처리 데이터베이스 중 적어도 하나로부터 트레이닝 데이터를 인출함으로써 상기 적어도 하나의 ML 테이블을 구축하도록 더 구성되고,
    상기 로컬 처리 데이터베이스로부터 인출된 상기 트레이닝 데이터는 복수의 애플리케이션 요청에 대해 이전에 결정된 로컬 처리 시간에 관한 정보를 포함하고, 상기 에지 처리 데이터베이스로부터 인출된 상기 트레이닝 데이터는 상기 복수의 애플리케이션 요청에 대해 이전에 결정된 에지 처리 시간, 및 상기 UE에 의해 지원되는 상기 RAN의 신호 강도, 상기 RAN의 타입, 상기 RAN과 연관된 상기 네트워크 혼잡 상태 중 적어도 하나에 관한 정보를 포함하는, 사용자 장치(UE).
  16. 제 14 항에 있어서,
    상기 제어부는,
    상기 UE가 적어도 하나의 에지 서버로부터 에지 처리 능력을 수신함으로써 상기 적어도 하나의 ML 테이블을 구축하도록 더 구성되는, 사용자 장치(UE).
  17. 제 14 항에 있어서,
    상기 제어부는,
    상기 수신된 적어도 하나의 애플리케이션 요청 및 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 결정된 적어도 하나의 파라미터를 상기 ML 테이블의 데이터와 비교하되, 상기 ML 테이블의 데이터는 복수의 파라미터, 에지 처리 시간 및 로컬 처리 시간과 매핑된 복수의 애플리케이션의 복수의 애플리케이션 요청을 포함하고;
    상기 수신된 적어도 하나의 애플리케이션 요청 및 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 결정된 적어도 하나의 파라미터와 일치하는 적어도 하나의 애플리케이션 요청 및 ML 테이블의 상응하는 적어도 하나의 파라미터를 식별하고,
    상기 식별된 적어도 하나의 애플리케이션 요청 및 상기 ML 테이블의 상기 상응하는 적어도 하나의 파라미터와 매핑된 상기 로컬 처리 시간 및 상기 에지 처리 시간 중 적어도 하나를 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 로컬 처리 시간 및 상기 에지 처리 시간 중 적어도 하나로서 결정하도록 더 구성되는, 사용자 장치(UE).
  18. 제 14 항에 있어서,
    상기 제어부는,
    상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 결정된 로컬 처리 시간, 상기 수신된 적어도 하나의 애플리케이션 요청에 대한 상기 결정된 에지 처리 시간, 상기 UE의 배터리 레벨, 및 적어도 하나의 사용자 선호도 중 적어도 하나에 적어도 하나의 가중치를 할당하고,
    상기 결정된 로컬 처리 시간, 상기 결정된 에지 처리 시간, 상기 UE의 배터리 레벨 및 상기 적어도 하나의 사용자 선호도 중 적어도 하나에 할당된 적어도 하나의 가중치의 함수로서 상기 비용 함수를 도출하도록 더 구성되는, 사용자 장치(UE).
  19. 제 14 항에 있어서,
    상기 제어부는,
    상기 수신된 적어도 하나의 애플리케이션 요청에 대해 상기 도출된 비용 함수 및 상기 결정된 에지 처리 시간에 대한 분석을 수행하되, 상기 도출된 비용 함수에 대한 분석은 상기 결정된 로컬 처리 시간, 상기 결정된 에지 처리 시간, 상기 UE의 배터리 레벨, 및 연관된 적어도 하나의 가중치에 기초한 상기 적어도 하나의 사용자 선호도 중 적어도 하나 간의 비교를 수행하고,
    수행된 분석에 기초하여 상기 처리 결정 파라미터를 생성하도록 더 구성되는, 사용자 장치(UE).
  20. 제 12 항에 있어서,
    상기 제어부는,
    상기 결정된 처리 모드가 로컬 처리인 경우에 상기 수신된 적어도 하나의 애플리케이션 요청을 로컬로 처리하고,
    상기 결정된 처리 모드가 에지 처리인 경우에 상기 수신된 적어도 하나의 애플리케이션 요청을 상기 적어도 하나의 에지 서버(204)로 오프로딩하며;
    상기 결정된 처리 모드가 하이브리드 처리인 경우에 상기 로컬 처리와 상기 에지 처리의 조합을 사용하여 상기 수신된 적어도 하나의 애플리케이션 요청을 처리하도록 더 구성되는, 사용자 장치(UE)(208).

KR1020200030666A 2019-03-12 2020-03-12 애플리케이션 요청의 처리를 최적화하는 방법 및 시스템 KR20200109272A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IN201941009482 2019-03-12
IN201941009482 2019-03-12
IN201941009482??? 2019-11-19

Publications (1)

Publication Number Publication Date
KR20200109272A true KR20200109272A (ko) 2020-09-22

Family

ID=72425406

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020200030666A KR20200109272A (ko) 2019-03-12 2020-03-12 애플리케이션 요청의 처리를 최적화하는 방법 및 시스템

Country Status (5)

Country Link
US (2) US11140565B2 (ko)
EP (1) EP3854063B1 (ko)
KR (1) KR20200109272A (ko)
CN (1) CN113574842A (ko)
WO (1) WO2020185000A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102368165B1 (ko) * 2020-11-04 2022-02-28 한국과학기술원 엣지 컴퓨팅 환경에서 비용을 고려한 마이크로서비스 기반 어플리케이션 배포 방법
WO2022075528A1 (ko) * 2020-10-08 2022-04-14 인하대학교 산학협력단 모바일 엣지 컴퓨팅에서 엣지 서버 한도 전력 하에서 보상을 최대화하는 작업 오프로딩
KR102627462B1 (ko) * 2022-12-19 2024-01-23 주식회사 비플러스헬스케어 Mec를 이용한 의료기기 연동 및 문진성능 향상시스템 및 그 방법

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102368576B1 (ko) * 2020-11-09 2022-02-25 한국교통대학교산학협력단 지역 동적 지도를 이용한 채널상태 예측을 통한 무선 통신을 수행하기 위한 방법 및 장치
CN112764936B (zh) * 2021-01-29 2022-06-14 北京邮电大学 基于深度强化学习的边缘计算服务器信息处理方法及装置
CN113727362B (zh) * 2021-05-31 2022-10-28 南京邮电大学 一种基于深度强化学习的无线供电系统的卸载策略方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3257303A1 (en) * 2015-02-12 2017-12-20 Nokia Solutions and Networks Oy Access control to services in a network
US10587721B2 (en) 2015-08-28 2020-03-10 Qualcomm Incorporated Small cell edge computing platform
EP3380940A1 (en) 2015-11-24 2018-10-03 NEC Laboratories Europe GmbH A method and network for managing and orchestrating virtual network functions and network applications
EP3466122B1 (en) * 2016-06-06 2021-12-22 Nokia Solutions and Networks Oy Mobile edge computing
US10440096B2 (en) * 2016-12-28 2019-10-08 Intel IP Corporation Application computation offloading for mobile edge computing
WO2018206844A1 (en) 2017-05-08 2018-11-15 Nokia Technologies Oy Routing and policy management at network edge
US20180352038A1 (en) * 2017-05-30 2018-12-06 Intel Corporation Enhanced nfv switching
US10972575B2 (en) * 2017-06-02 2021-04-06 Huawei Technologies Co., Ltd. Method and system for supporting edge computing
WO2019011408A1 (en) * 2017-07-10 2019-01-17 Nokia Solutions And Networks Oy MEC APPLICATION TRANSFER
US10110495B1 (en) * 2017-11-22 2018-10-23 Intel Corporation Multi-access edge computing (MEC) service provision based on local cost measurements
CN108600002B (zh) * 2018-04-17 2021-02-26 浙江工业大学 一种基于半监督学习的移动边缘计算分流决策方法
CN109257429A (zh) * 2018-09-25 2019-01-22 南京大学 一种基于深度强化学习的计算卸载调度方法
TWI675572B (zh) * 2018-11-23 2019-10-21 財團法人工業技術研究院 網路服務系統及網路服務方法
US11187548B2 (en) * 2019-02-05 2021-11-30 International Business Machines Corporation Planning vehicle computational unit migration based on mobility prediction

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022075528A1 (ko) * 2020-10-08 2022-04-14 인하대학교 산학협력단 모바일 엣지 컴퓨팅에서 엣지 서버 한도 전력 하에서 보상을 최대화하는 작업 오프로딩
KR102368165B1 (ko) * 2020-11-04 2022-02-28 한국과학기술원 엣지 컴퓨팅 환경에서 비용을 고려한 마이크로서비스 기반 어플리케이션 배포 방법
KR102627462B1 (ko) * 2022-12-19 2024-01-23 주식회사 비플러스헬스케어 Mec를 이용한 의료기기 연동 및 문진성능 향상시스템 및 그 방법

Also Published As

Publication number Publication date
WO2020185000A1 (en) 2020-09-17
EP3854063A4 (en) 2021-12-01
EP3854063B1 (en) 2024-05-01
CN113574842A (zh) 2021-10-29
US20220022075A1 (en) 2022-01-20
US11140565B2 (en) 2021-10-05
EP3854063A1 (en) 2021-07-28
US20200296609A1 (en) 2020-09-17

Similar Documents

Publication Publication Date Title
KR20200109272A (ko) 애플리케이션 요청의 처리를 최적화하는 방법 및 시스템
US11310104B2 (en) Management of persistent network slices by a distributed learning system in a 5G or other next generation wireless network
US11388222B2 (en) Mobile edge computing
US20230114909A1 (en) Recalibrating resource profiles for network slices in a 5g or other next generation wireless network
US11212768B2 (en) Densifying a mobility network by siting antennas with demand zone planning, in a communications network
CN113949705B (zh) 通信方法和通信装置
US20230180114A1 (en) Modifying capacity assigned to support a network slice allocated to a user device in a 5g or other next generation wireless network
US20230247497A1 (en) Using dynamic thresholds for non-mobility handovers in a fifth generation (5g) or other next generation network
US11729055B1 (en) Utilizing templates with associated naming policies to deploy network equipment
US20230100203A1 (en) Autonomous onsite remediation of adverse conditions for network infrastructure in a fifth generation (5g) network or other next generation wireless communication system
US11665686B2 (en) Facilitating a time-division multiplexing pattern-based solution for a dual-subscriber identity module with single radio in advanced networks
US11570586B2 (en) Location aware assignment of resources for push to talk (PTT) communication systems in a fifth generation (5G) network or other next generation wireless communication system
US11381934B2 (en) Aggregation of application and systems for services for 6G or other next generation network
US20240040394A1 (en) Placing components for a virtual radio access network based on resource availability and performance
US20230135397A1 (en) Selecting network routes based on aggregating models that predict node routing performance
US11991645B2 (en) Determining a response by user equipment to a base station signal based on transmission signal strength relayed with the signal
US20230084221A1 (en) Providing notice that a network device is identified by more than one network identifier
US20230135898A1 (en) Monitoring configuration of an inventory of devices using captured images of the devices
US20230164579A1 (en) Planning and deploying service elements of a network service across transport and core network segments
US11768082B2 (en) Facilitation of predictive simulation of planned environment
US20240146395A1 (en) Using unmanned mobile vehicles to improve signal propagation by placing temporary access points
US11817927B1 (en) Allocating antenna resources to prepare for idle equipment to transition to active mode
US20240039900A1 (en) Using a transmission profile to provide availability and security options for communicating data
US20240037007A1 (en) Utilization of a resource to perform a task based on a predicted capacity of the resource
US20230422143A1 (en) Using a reflective surface to reflect a signal from access point equipment to signal receiving equipment

Legal Events

Date Code Title Description
A201 Request for examination