KR20230131168A - Iot(internet of things) 네트워크에서 qos(quality of service)를 최적화하기 위한 시스템들 및 방법들 - Google Patents

Iot(internet of things) 네트워크에서 qos(quality of service)를 최적화하기 위한 시스템들 및 방법들 Download PDF

Info

Publication number
KR20230131168A
KR20230131168A KR1020237010280A KR20237010280A KR20230131168A KR 20230131168 A KR20230131168 A KR 20230131168A KR 1020237010280 A KR1020237010280 A KR 1020237010280A KR 20237010280 A KR20237010280 A KR 20237010280A KR 20230131168 A KR20230131168 A KR 20230131168A
Authority
KR
South Korea
Prior art keywords
request
network
allocating
analysis engine
resources
Prior art date
Application number
KR1020237010280A
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 KR20230131168A publication Critical patent/KR20230131168A/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/56—Queue scheduling implementing delay-aware scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)

Abstract

IoT 네트워크에서 UE의 QoS 프로파일에 기초하여 네트워크 자원들을 할당하고 IoT 네트워크의 QoS를 최적화하기 위한 접근법들이 설명된다. 일 예에서, 요청이 UE(User Equipment)로부터 수신될 수 있다. UE는 네트워크를 통해 시스템과 통신할 수 있다. 추가로, 수신된 요청은 UE 파라미터들의 세트를 포함할 수 있다. 그 후, UE 파라미터들의 세트는 수신된 요청으로부터 추출될 수 있다. 추출된 UE 파라미터들의 세트에 기초하여, QoS(Quality of Service) 프로파일이 요청에 할당될 수 있다. 그 후, 할당된 QoS 프로파일에 기초하여, 복수의 네트워크 자원들 중 적어도 하나가 요청을 생성하는 UE에 할당될 수 있다.

Description

IOT(INTERNET OF THINGS) 네트워크에서 QOS(QUALITY OF SERVICE)를 최적화하기 위한 시스템들 및 방법들
[0001] 본 개시의 실시예들은 일반적으로 사물 인터넷(IoT: Internet of Things) 네트워크에서 서비스 품질(QoS: Quality of Service)을 최적화하기 위한 접근법들에 관한 것이다. 보다 구체적으로, 본 개시는 IoT(Internet of Things) 네트워크에서 사용자 장비(UE: User Equipment)의 QoS(Quality of Service) 프로파일에 기초하여 네트워크 자원들을 할당하기 위한 접근법들에 관한 것이다.
[0002] 관련 기술에 대한 이하의 설명은 본 개시의 분야에 속하는 배경 정보를 제공하도록 의도된 것이다. 이 섹션은 본 개시의 다양한 특징들과 관련될 수 있는 기술의 특정 양태들을 포함할 수 있다. 그러나, 이 섹션은 본 개시에 대한 독자의 이해를 향상시키기 위해서만 사용되며 종래 기술을 인정하는 것이 아님을 이해해야 한다.
[0003] 일반적으로, 센서들, 사용자 디바이스들 및 서버들과 같은 복수의 디바이스들이 IoT(Internet of Things) 네트워크를 형성하기 위해 연결될 수 있다. 현재, IoT 디바이스로부터의 데이터는 임의의 다른 일반 디바이스로서 취급될 수 있으며 데이터는 임의의 인터넷 데이터로서 취급되므로 디폴트 QoS(Quality of Service) 프로파일이 설정된다. 현재, IoT 애플리케이션들/데이터가 신뢰성, 레이턴시 민감도(latency sensitivity) 측면에서 전체 최종 사용 사례 속성들에 기초하여 취급되는 현재 에코시스템(ecosystem)에 존재하는 이러한 지능/메커니즘이 없을 수 있다. 실제 세계에서, 특정 지연 후 데이터가 시스템을 통해 송신될 수 그러한 많은 IoT 애플리케이션들이 존재하며, 이러한 경우들에서 네트워크는, 데이터를 캐싱(caching)하고 그의 자원 및 컴퓨테이션 부하로 인해 일정 시간 기간 동안 이 데이터를 송신할 수 있다. 또한, 특정 데이터는 최종 사용 사례 시나리오로 인해 특정 컴퓨테이션을 필요로 할 수 있다.
[0004] 예를 들어, 농업 IoT 환경에서, 다양한 센서에 의해 수집된 데이터는 시간이 중요하지 않을 수 있으므로, 시스템을 통해 즉시 송신할 필요가 없을 수 있고 다양한 레벨들에서 캐싱되고 하루에 한 번 송신될 수 있거나, 최종 사용 사례 시나리오에 기초하여 시스템의 애플리케이션 서버 또는 디바이스에 의해 구성될 수 있다. 또한 토양 - PH, 수분 등과 같은 수집된 센서 데이터는 최종 사용자에게 의미가 없을 수 있고 이로부터 의미 있는 데이터를 만들기 위해 특정 컴퓨테이션 또는 수학적 통계 모델들을 실행할 필요가 있으므로 그대로 송신되지 않을 것이다. 이러한 컴퓨테이션은 디바이스, RAN 또는 애플리케이션 서버 또는 애플리케이션 기능(5G 네트워크의 일부)과 같은 다양한 레벨들에서 수행될 수 있다. 따라서, 본질적으로 IOT 애플리케이션들은 레이턴시 민감(latency sensitive)이거나 또는 레이턴시 둔감(latency insensitive)일 수 있다. 레이턴시 둔감 애플리케이션 데이터는 데이터가 애플리케이션 서버로 송신되기 전에 확장된 기간 동안 무선 액세스 시스템(RAS: Radio Access System)에서 캐싱될 수 있다.
[0005] 애플리케이션이 레이턴시 민감인지 또는 레이턴시 둔감인지, 그리고 추가로 이러한 애플리케이션이 GSM 이볼루션을 위한 향상된 데이터 레이트들(EDGE: Enhanced Data rates for GSM Evolution) 또는 무선 액세스 엔티티들에서 캐싱 및/또는 데이터 프로세싱 지원을 필요로 할 수 있는지를 식별하기 위한 종래의 방법들이 존재하지 않는다. 기존의 셀룰러 네트워크(4세대(4G), 5G, NB-IoT)는 부상하는 IoT 애플리케이션 유형들에 적합하지 않은 QoS 카테고리들을 지원한다. IoT 애플리케이션 유형들은 의료용 IoT 디바이스들과 같은 레이턴시 민감 카테고리들로부터 농업 분야들에서 사용되는 토양 센서 IoT 디바이스들과 같은 레이턴시 둔감 디바이스들 또는 애플리케이션 유형들까지 다양할 수 있다. 종래의 QoS 파라미터들은 "스루풋, 전송 지연, 우선 순위, 보호"와 같은 값들을 포함할 수 있지만, 종래의 QoS 파라미터들은 데이터 스트림, 데이터의 패킷 또는 디바이스에서 발생하는 임의의 데이터가 캐싱을 필요로 하는 경우 캐싱의 장소를 포함하지 않을 수 있으며, 데이터가 로컬 프로세싱을 필요로 하는 경우 프로세싱 상세 사항들의 특성을 포함하지 않을 수 있다.
[0006] 따라서, 기존 선행 기술의 단점들을 극복할 수 있는 방법들 및 시스템들을 제공할 필요성이 본 기술 분야에 존재한다.
[0007] 본원의 적어도 하나의 실시예가 충족시키는 본 개시의 목적들 중 일부가 여기에서 아래에 열거된다.
[0008] 본 개시의 목적은 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)의 효율적인, 레이턴시 감도 및 신뢰성 있는 최적화를 위한 시스템들 및 방법들을 제공하는 것이다.
[0009] 본 개시의 다른 목적은 애플리케이션이 레이턴시 둔감인지, EDGE 및/또는 무선 액세스 노드들에서 캐싱 지원 및/또는 연합 프로세싱(federated processing) 능력들을 필요로 하는지를 식별하는 데 도움이 될 새로운 QoS 프로파일을 위한 시스템들 및 방법들을 제공하는 것이다.
[0010] 본 개시의 다른 목적은 특정 애플리케이션들에 대한 지능형 데이터 프로세싱을 수행할 수 있는 무선 액세스 네트워크의 추가 컴퓨트(compute) 엔티티들을 지원하기 위한 시스템들 및 방법들을 제공하는 것이다.
[0011] 본 개시의 다른 목적은 새로운 QoS 클래스들을 적절하게 할당하기 위해 IOT 네트워크에 의해 사용될 IOT 애플리케이션 카테고리 또는 유형을 인식하는 시스템들 및 방법들을 제공하는 것이다.
[0012] 본 개시의 다른 목적은 일부 애플리케이션 우선 순위들이 상대적이므로(예를 들어, 레이턴시 둔감 유형으로부터 레이턴시 민감 유형까지) 카테고리 유형들 사이의 우선 순위들을 변경하도록 시그널링하기 위한 시스템들 및 방법들을 제공하는 것이다.
[0013] 본 개시의 다른 목적은 새로운 애플리케이션 카테고리들을 규정된 새로운 QoS 클래스 식별자들에 매핑할 수 있는 논-액세스 계층(NAS: Non-Access Stratum)에 대한 애플리케이션들 사이의 모뎀 인터페이스를 이용하는 시스템들 및 방법들을 제공하는 것이다.
[0014] 본 개시의 다른 목적은 신뢰성, 레이턴시 민감도 측면에서 전체 최종 사용자 사례 속성들에 기초하여 IoT 애플리케이션들/데이터를 취급하기 위한 시스템들 및 방법들을 제공하는 것이다.
[0015] 본 개시의 다른 목적은 데이터 스트림, 데이터 패킷 또는 캐싱을 필요로 하는 디바이스로부터 발생하는 임의의 데이터, 캐싱의 장소, 로컬 프로세싱을 필요로 하는 경우 프로세싱 상세 사항들의 특성과 같은 QoS 파라미터들을 수반하는 시스템들 및 방법들을 제공하는 것이다.
[0016] 본 개시의 다른 목적은 확장된 QoS 템플릿의 QoS 메커니즘, 레이턴시 둔감 애플리케이션들을 위한 새로운 QoS 템플릿을 해석하고 적용하는 메커니즘을 위한 시스템들 및 방법들을 제공하는 것이다.
[0017] 본 개시의 목적들의 본 개시의 실시예들은 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)을 최적화하기 위한 접근법들에 관한 것이다. 보다 구체적으로, 본 개시는 IoT(Internet of Things) 네트워크에서 UE(User Equipment)의 QoS(Quality of Service) 프로파일에 기초하여 네트워크 자원들을 할당하기 위한 접근법들에 관한 것이다.
[0018] 본 개시의 일 실시예는 IoT(Internet of Things) 네트워크에서 UE(User Equipment)의 QoS(Quality of Service) 프로파일에 기초하여 네트워크 자원들을 할당하기 위한 시스템에 관한 것이다. 시스템은 프로세서 및 프로세서에 커플링된 분석 엔진을 포함할 수 있다. 분석 엔진은 UE(User Equipment)로부터 요청을 수신하도록 구성될 수 있다. UE는 네트워크를 통해 시스템과 통신할 수 있다. 추가로, 수신된 요청은 UE 파라미터들의 세트를 포함할 수 있다. 그 후, UE 파라미터들의 세트는 수신된 요청으로부터 추출될 수 있다. 추출된 UE 파라미터들의 세트에 기초하여, QoS(Quality of Service) 프로파일이 요청에 할당될 수 있다. 그 후, 할당된 QoS 프로파일에 기초하여, 복수의 네트워크 자원들 중 적어도 하나가 요청을 생성하는 UE에 할당될 수 있다.
[0019] 일 양태에서, 요청은 통신 모뎀을 통해 UE로부터 수신될 수 있다. 통신 모뎀은 네트워크를 통해 UE 및 시스템에 통신 가능하게 커플링될 수 있다.
[0020] 다른 양태에서, 분석 엔진은 UE로부터 수신된 요청에 기초하여, UE와의 프로토콜 데이터 유닛(PDU: Protocol Data Unit) 세션을 확립하도록 추가로 구성될 수 있다.
[0021] 또 다른 양태에서, 분석 엔진은 사전 규정된 매핑 기준에 기초하여 QoS 프로파일을 프로파일에 할당할 수 있다.
[0022] 또 다른 양태에서, 분석 엔진은 추출된 UE 파라미터들의 세트에 기초하여, UE로부터의 요청을 레이턴시 민감 요청(latency sensitive request) 및 레이턴시 둔감 요청(latency insensitive request) 중 하나로 카테고리화할 수 있다.
[0023] 또 다른 양태에서, 복수의 네트워크 자원들을 요청을 생성하는 UE에 할당하는 것은 프로세싱 자원들의 할당, 메모리 자원들의 할당, 실행 우선순위 레벨(priority level of execution) 할당 또는 이들의 조합 중 하나를 포함할 수 있다.
[0024] 또 다른 양태에서, 프로세싱 자원들을 UE에 할당하는 것은 요청을 생성하는 UE로 하여금 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 프로세싱 자원들 중 하나를 이용하게 하는 것을 포함할 수 있다.
[0025] 또 다른 양태에서, 메모리 자원들을 UE에 할당하는 것은 요청을 생성하는 UE로 하여금 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 캐시 메모리들 중 하나를 이용하게 하는 것을 포함할 수 있다.
[0026] 또 다른 양태에서, 실행 우선순위 레벨을 UE에 할당하는 것은 특정 시간 기간 동안 요청의 실행 지연을 야기하는 것을 포함할 수 있다.
[0027] 또 다른 양태에서, UE 파라미터들의 세트는 센서 데이터, 애플리케이션 데이터 또는 이들의 조합 중 하나를 포함할 수 있다.
[0028] 또 다른 양태에서, 센서 데이터는 UE와 통신하는 복수의 센서들 중 하나로부터 획득될 수 있다.
[0029] 또 다른 양태에서, 애플리케이션 데이터는 UE 상에서 실행되는 애플리케이션으로부터 획득될 수 있다.
[0030] 본 개시의 다른 실시예는 IoT(Internet of Things) 네트워크에서 UE(User Equipment)의 QoS(Quality of Service) 프로파일에 기초하여 네트워크 자원들을 할당하기 위한 방법에 관한 것이다. 본 방법은 분석 엔진에 의해, UE(User Equipment)로부터 요청을 수신하는 단계를 포함할 수 있다. UE는 네트워크를 통해 시스템과 통신할 수 있다. 추가로, 수신된 요청은 UE 파라미터들의 세트를 포함할 수 있다. 그 후, UE 파라미터들의 세트는 수신된 요청으로부터 추출될 수 있다. 추출된 UE 파라미터들의 세트에 기초하여, QoS(Quality of Service) 프로파일은 요청에 할당될 수 있다. 그 후, 할당된 QoS 프로파일에 기초하여, 복수의 네트워크 자원들 중 적어도 하나는 요청을 생성하는 UE에 할당될 수 있다.
[0031] 일 양태에서, 요청은 통신 모뎀을 통해 UE로부터 수신될 수 있다. 통신 모뎀은 네트워크를 통해 UE 및 시스템에 통신 가능하게 커플링될 수 있다.
[0032] 다른 양태에서, 본 방법은 UE로부터 수신된 요청에 기초하여, UE와의 PDU(Protocol Data Unit) 세션을 확립하는 단계를 추가로 포함할 수 있다.
[0033] 또 다른 양태에서, QoS 프로파일을 프로파일에 할당하는 단계는 사전 규정된 매핑 기준에 기초할 수 있다.
[0034] 또 다른 양태에서, 본 방법은 추출된 UE 파라미터들의 세트에 기초하여, UE로부터의 요청을 레이턴시 민감 요청 및 레이턴시 둔감 요청 중 하나로 카테고리화하는 단계를 추가로 포함할 수 있다.
[0035] 또 다른 양태에서, 복수의 네트워크 자원들을 요청을 생성하는 UE에 할당하는 단계는 프로세싱 자원들을 할당하는 단계, 메모리 자원들을 할당하는 단계, 실행 우선순위 레벨을 할당하는 단계 또는 이들의 조합을 포함할 수 있다.
[0036] 또 다른 양태에서, 프로세싱 자원들을 UE에 할당하는 단계는 요청을 생성하는 UE로 하여금 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 프로세싱 자원들 중 하나를 이용하게 하는 단계를 포함할 수 있다.
[0037] 또 다른 양태에서, 메모리 자원들을 UE에 할당하는 단계는 요청을 생성하는 UE로 하여금 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 캐시 메모리들 중 하나를 이용하게 하는 단계를 포함할 수 있다.
[0038] 또 다른 양태에서, 실행 우선순위 레벨을 UE에 할당하는 단계는 특정 시간 기간 동안 요청의 실행 지연을 야기하는 단계를 포함할 수 있다.
[0039] 또 다른 양태에서, UE 파라미터들의 세트는 센서 데이터, 애플리케이션 데이터 또는 이들의 조합 중 하나를 포함할 수 있다.
[0040] 또 다른 양태에서, 센서 데이터는 UE와 통신하는 복수의 센서들 중 하나로부터 획득될 수 있다.
[0041] 또 다른 양태에서, 애플리케이션 데이터는 UE 상에서 실행되는 애플리케이션으로부터 획득될 수 있다.
[0042] 본원의 청구대상의 다양한 목적들, 특징들, 양태들 및 이점들은 동일한 번호들이 동일한 구성 요소들을 나타내는 첨부 도면들과 함께 이하의 바람직한 실시예들의 상세한 설명으로부터 더욱 명백해질 것이다.
[0043] 본원에 통합되고 본 발명의 일부를 구성하는 첨부 도면들은 개시된 방법들 및 시스템들의 예시적인 실시예들을 예시하며, 여기서 동일한 참조 번호들은 상이한 도면들 전체에 걸쳐 동일한 부분들을 지칭한다. 도면들의 구성 요소들은 반드시 축척에 따른 것은 아니며, 대신에 본 발명의 원리들을 명확하게 예시하는 데 중점을 둔다. 일부 도면들은 블록도들을 사용하여 구성 요소들을 나타낼 수 있으며 각각의 구성 요소의 내부 회로를 나타내지 않을 수 있다. 이러한 도면들의 발명은 이러한 구성 요소들을 구현하는 데 통상적으로 사용되는 전기 구성 요소들, 전자 구성 요소들 또는 회로의 발명을 포함한다는 것이 본 기술 분야의 통상의 기술자에 의해 이해될 것이다.
[0044] 도 1은 본 개시의 일 실시예에 따라 본 개시의 제안된 시스템이 내부에 구현될 수 있거나 또는 함께 구현될 수 있는 예시적인 네트워크 아키텍처를 예시한다.
[0045] 도 2는 본 개시의 일 실시예에 따라 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)을 최적화하기 위한 제안된 시스템의 예시적인 표현을 예시한다.
[0046] 도 3은 본 개시의 일 실시예에 따라 시스템에서 구현될 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)을 최적화하기 위한 흐름도를 예시한다.
[0047] 도 4는 본 개시의 일 실시예에 따라 QoS 설정을 위한 컴퓨테이션 레벨들의 예시적인 시퀀스도 표현을 예시한다.
[0048] 도 5a 내지 도 5e는 본 개시의 일 실시예에 따라 애플리케이션과 통신 모뎀 사이의 애플리케이션 유형(AT: Application Type) 커맨드들의 예시적인 시퀀스도 표현들을 예시한다.
[0049] 도 5f는 본 개시의 일 실시예에 따른 일반적인 네트워크 아키텍처에서 캐싱 레벨의 예시적인 블록도 표현을 예시한다.
[0050] 도 5g는 본 개시의 일 실시예에 따른 시스템에 걸친 애플리케이션 유형의 자동 검출을 위한 방법의 예시적인 흐름도 표현을 예시한다.
[0051] 도 5h는 본 개시의 일 실시예에 따라 통신 네트워크를 구성하는 애플리케이션 서버(AS: Application Server)뿐만 아니라 애플리케이션 유형의 인식에 기초한 QoS 프로파일 상의 모뎀의 예시적인 시퀀스도 표현을 예시한다.
[0052] 도 5i는 본 개시의 일 실시예에 따라 5세대(5G) 네트워크 아키텍처에서 AT(Application Type) 커맨드들의 예시적인 시퀀스도 표현을 예시한다.
[0053] 도 5j는 본 개시의 일 실시예에 따라 5세대(5G) 네트워크 아키텍처에서 새로운 논-액세스 계층(NAS)을 사용하는 애플리케이션 유형(AT) 커맨드들의 예시적인 시퀀스도 표현을 예시한다.
[0054] 도 5k는 본 개시의 일 실시예에 따라 5세대(5G) 네트워크 아키텍처에서 포스트-핸드오버 동안 손실된 사용자 장비 컨텍스트/애플리케이션 유형 손실된 시나리오 동안 새로운 논-액세스 계층(NAS)을 사용하는 애플리케이션 유형(AT) 커맨드들의 예시적인 시퀀스도 표현을 예시한다.
[0055] 도 6은 본 개시의 실시예들에 따라 본 발명의 실시예들이 그 내부에서 이용될 수 있거나 또는 그와 함께 이용될 수 있는 예시적인 컴퓨터 시스템을 예시한다.
[0056] 상술한 내용은 본 발명의 이하의 보다 상세한 설명으로부터 더욱 명백해질 것이다.
[0057] 이하의 설명에서, 설명의 목적을 위해, 본 개시의 실시예들의 완전한 이해를 제공하기 위해 다양한 특정 상세 사항들이 제시된다. 그러나, 본 개시의 실시예들은 이러한 특정 상세 사항들 없이 실시될 수 있음이 명백할 것이다. 이후에 설명되는 몇몇 특징들은 각각 서로 독립적으로 또는 다른 특징들의 임의의 조합으로 사용될 수 있다. 개별 특징은 위에서 논의된 모든 문제들을 해결하지 못하거나 위에서 논의된 문제들 중 일부만을 해결할 수 있다. 위에서 논의된 문제들 중 일부는 본원에 설명된 특징들 중 임의의 것에 의해 완전히 해결되지 않을 수 있다.
[0058] 이어지는 설명은 예시적인 실시예들만을 제공하며, 본 개시의 범위, 적용 가능성 또는 구성을 한정하려는 의도가 아니다. 오히려, 예시적인 실시예들의 이어지는 설명은 예시적인 실시예를 구현하기 위한 가능한 설명을 본 기술 분야의 통상의 기술자에게 제공할 것이다. 제시된 바와 같은 본 발명의 사상 및 범위를 벗어나지 않고 요소들의 기능 및 배열에 다양한 변경들이 이루어질 수 있음을 이해해야 한다.
[0059] 본 개시는 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)을 최적화하기 위한 접근법들을 제공한다. 본원의 청구대상의의 접근법들에 따라, 네트워크 자원들은 개개의 QoS 프로파일들에 기초하여 네트워크의 다양한 UE(User Equipment)들에 할당될 수 있다. 상이한 UE들 상에서 실행되는 다양한 애플리케이션들이 분석될 수 있으며, 레이턴시 민감도 레벨에 기초하여, 네트워크 자원들이 그에 따라 할당될 수 있다. 일 예에서, 캐싱 지원 및 연합 프로세싱 능력들이 제공될 수 있다. 다른 예에서, 애플리케이션 및 대응 UE는 네트워크의 전체 QoS를 개선하기 위해 네트워크에서 특정 프로세싱 자원을 할당받을 수 있다. 이해할 수 있는 바와 같이, 본 주제는 그에 따라 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)의 효율적인, 레이턴시 민감도 및 신뢰성 있는 최적화를 제공할 수 있다.
[0060] 다른 예에서, 본 개시는 특정 애플리케이션에 대해 지능형 데이터 프로세싱을 수행할 수 있는 무선 액세스 네트워크의 추가 컴퓨트 엔티티들을 지원하는 시스템들 및 방법들을 제공한다. 또 다른 예에서, 본 개시는 새로운 QoS 클래스들을 적절하게 할당하기 위해 IOT 네트워크에 의해 사용될 IOT 애플리케이션 카테고리 또는 유형을 인식하는 시스템들 및 방법들을 제공한다. 또 다른 예에서, 본 개시는 일부 애플리케이션 우선 순위들이 상대적이므로(예를 들어, 레이턴시 둔감 유형으로부터 레이턴시 민감 유형으로) 카테고리 유형들 간의 우선 순위들을 변경하도록 시그널링하기 위한 시스템들 및 방법들을 제공한다. 또 다른 예에서, 본 개시는 새로운 애플리케이션 카테고리들을 규정된 새로운 QoS 클래스 식별자들로 매핑할 수 있는 논-액세스 계층(NAS)에 대한 애플리케이션들 사이의 모뎀 인터페이스를 이용하는 시스템들 및 방법들을 제공한다. 또 다른 예에서, 본 개시는 신뢰성, 레이턴시 민감도 측면에서 전체 최종 사용 사례 속성에 기초하여 IoT 애플리케이션들/데이터를 취급하기 위한 시스템들 및 방법들을 제공한다. 또 다른 예에서, 본 개시는 데이터 스트림, 데이터 패킷 또는 캐싱을 필요로 하는 디바이스로부터 발생하는 임의의 데이터, 캐싱의 장소, 로컬 프로세싱을 필요로 하는 경우 프로세싱 상세 사항들의 특성과 같은 QoS 파라미터들을 수반하는 시스템들 및 방법들을 제공한다. 또 다른 예에서, 본 개시는 확장된 QoS 템플릿의 QoS 메커니즘, 레이턴시 둔감 애플리케이션들을 위한 새로운 QoS 템플릿을 해석하고 적용하는 메커니즘을 위한 시스템들 및 방법들을 제공한다.
[0061] 이러한 양태 및 다른 양태들은 도 1 내지 도 6과 관련하여 더욱 상세히 설명될 것이다. 도면들은 단지 예시일 뿐이며 어떠한 방식으로든 본 주제의 범위를 제한하는 것으로 해석되어서는 안된다는 점에 유의할 수 있다. 추가로 유의할 수 있는 것은 도 1 내지 도 3은 연계되어 설명되었으며, 적용 가능한 경우 동일한 참조 번호들이 사용되었다는 것이다.
[0062] 본 개시의 일 실시예에 따라 QoS(Quality of Service) 최적화 시스템을 위한 예시적인 네트워크 아키텍처(100)(네트워크 아키텍처(100)라고도 칭함)를 예시하는 도 1을 참조한다. 도 1에 묘사된 바와 같이, 복수의 UE(User Equipment)들(102-1, 102-2, 102-3,..., 102-N)(집합적으로 UE(User Equipment)(102)로 지칭됨)은 네트워크(106)를 통해 애플리케이션 서버(104)와 통신할 수 있다.
[0063] 일 예에서, UE(102)는 임의의 전기, 전자, 전자-기계 또는 장비 또는 모바일 폰, 스마트폰, 가상 현실(VR: Virtual Reality) 디바이스들, 증강 현실(AR: Augmented Reality) 디바이스들, 랩탑, 범용 컴퓨터, 데스크탑, 개인 휴대 정보 단말기(personal digital assistant), 태블릿 컴퓨터, IoT 센서, IoT 디바이스, IoT 기기들, 메인프레임 컴퓨터 또는 임의의 다른 컴퓨팅 디바이스와 같은 위의 디바이스들 중 하나 이상의 조합을 포함할 수 있지만 이에 한정되지 않으며, 여기서 컴퓨팅 디바이스는 카메라, 오디오 보조 장치, 마이크로폰, 키보드와 같은 시각 보조 디바이스, 터치 패드, 터치 인에이블링된 스크린, 전자 펜과 같이 사용자로부터 입력을 수신하기 위한 입력 디바이스들, 임의의 범위의 주파수들의 임의의 오디오 또는 시각적 신호를 수신하기 위한 수신 디바이스들 및 임의의 범위의 주파수들의 임의의 오디오 또는 시각적 신호를 전송할 수 있는 전송 디바이스들을 포함하지만 이에 한정되지 않는 하나 이상의 내장형 또는 외부적으로 커플링된 액세서리들을 포함할 수 있다. UE(102)는 언급된 디바이스들에 제한되지 않고 다양한 다른 디바이스들이 사용될 수 있음을 이해할 수 있다. 스마트 컴퓨팅 디바이스는 데이터 및 기타 개인/민감한 정보를 저장하기 위한 적절한 시스템들 중 하나일 수 있다.
[0064] 추가로, 애플리케이션 서버(104)는 임의의 하드웨어 기반, 소프트웨어 기반, 네트워크 기반 또는 클라우드 기반 서버로서 구현될 수 있다. 다른 예에서, 애플리케이션 서버(104)는 애플리케이션 서버(AS: Application Server) 또는 IoT 서버일 수 있다.
[0065] 다른 예에서, 애플리케이션 서버(104)는 액세스 및 모빌리티 관리 기능(AMF: Access and Mobility Management function), 세션 관리 기능(SMF: Session Management Function), 정책 제어 기능(PCF: Policy Control Function), 사용자 관리 기능(UPF: User Plane Function), 데이터 네트워크(DN: Data Network) 등과 같은 네트워크(100)의 복수의 다른 구성 요소들과 통신할 수 있다. 이러한 구성 요소들은 도 4에 묘사되어 있으며, 이후의 설명에서 기술된다. 또 다른 예에서, 이러한 구성 요소들은 애플리케이션 서버(104)의 일부일 수 있다. 임의의 다른 구현이 또한 본원의 청구대상의 범위 내에 포함될 것이다.
[0066] 또 다른 예에서, 애플리케이션 서버(104)는 시스템 온 칩(SoC: System On Chip) 시스템일 수 있지만 이에 한정되지 않는다. 또 다른 예에서, 온사이트(onsite) 데이터 캡처, 저장, 매칭, 프로세싱, 의사-결정 및 작동 로직은 마이크로-서비스 아키텍처(MSA: Micro-Services Architecture)를 사용하여 코딩될 수 있지만 이에 한정되지 않는다. 이식성을 지원하기 위해 복수의 마이크로서비스들이 컨테이너화되고 이벤트 기반이 될 수 있다.
[0067] 또 다른 예에서, 네트워크 아키텍처(100)는 근사 프로세싱이 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)을 최적화하기 위해 획득될 수 있으므로 애플리케이션 서버(104)에서 임의의 종류의 변화들을 수용하기 위해 모듈식이고 유연할 수 있다. 애플리케이션 서버(104) 구성 상세 사항은 즉시(on the fly) 수정될 수 있다.
[0068] 또 다른 예에서, 애플리케이션 서버(104)는 원격으로 모니터링될 수 있고, 애플리케이션 서버(104)의 데이터, 애플리케이션 및 물리적 보안이 완전히 보장될 수 있다. 일 실시예에서, 데이터가 수집되고 클라우드-기반 데이터 레이크(lake)에 보관되어 작용 가능한 통찰력들을 추출하기 위해 프로세싱될 수 있다. 따라서, 예측 유지 보수의 양태가 달성될 수 있다. 다른 예시적인 실시예에서, 애플리케이션 서버(104)는 예시의 방식으로 제한 없이 독립형 서버, 서버 블레이드(server blade), 서버 랙(server rack), 서버들의 뱅크(bank), 서버 팜(server farm), 클라우드 서비스 또는 시스템의 일부를 지원하는 하드웨어, 홈 서버, 가상화된 서버를 실행하는 하드웨어, 서버로서의 기능을 하는 코드를 실행하는 하나 이상의 프로세서들, 본원에 설명된 서버측 기능을 수행하는 하나 이상의 기계들, 위의 임의의 것들 중 적어도 일부, 이들의 일부 조합 중 하나 이상을 포함하거나 포괄할 수 있다.
[0069] 애플리케이션 서버(104)는 분석 엔진(도 1에 미도시)을 포함할 수 있다. 일 예에서, 분석 엔진은 애플리케이션 서버(104)의 일부일 수 있다. 다른 예에서, 분석 엔진은 애플리케이션 서버(104)와 통신할 수 있다. 또 다른 예에서, 분석 엔진은 중앙 집중식 서버를 통해 구현될 수 있으며, 이러한 중앙 집중식 서버는 애플리케이션 서버(104)와 통신할 수 있다. 분석 엔진의 임의의 다른 구현도 본원의 청구대상의 범위 내에 포함될 수 있다.
[0070] UE(102)는 추가로 복수의 센서들(도 1에 미도시)과 통신할 수 있다. 이러한 센서들은 개개의 UE(102)와 통신할 수 있고 상태를 지속적으로 모니터링할 수 있다. 이러한 센서들, UE(102) 및 애플리케이션 서버(102)는 서로 통신할 수 있고 IoT 네트워크의 일부를 형성할 수 있다.
[0071] 네트워크(106)는 IoT 통신 네트워크로서 구현될 수 있다. 네트워크(106)는 무선 네트워크, 유선 네트워크 또는 인트라넷, 근거리 네트워크(LAN: Local Area Network), 광역 네트워크(WAN: Wide Area Network), 인터넷 등과 같은 상이한 유형들의 네트워크들 중 하나로서 구현될 수 있는 이들의 조합일 수 있다. 추가로, 네트워크(106)는 전용 네트워크 또는 공유 네트워크일 수 있다. 공유 네트워크는 예를 들어, 하이퍼텍스트 전송 프로토콜(HTTP: Hypertext Transfer Protocol), 전송 제어 프로토콜/인터넷 프로토콜(TCP/IP: Transmission Control Protocol/Internet Protocol), 무선 애플리케이션 프로토콜(WAP: Wireless Application Protocol) 등과 같은 다양한 프로토콜들을 사용할 수 있는 상이한 유형들의 네트워크들의 연관을 나타낼 수 있다.
[0072] 예시적인 실시예에서, IoT 통신 네트워크(106)는 예시의 방식으로 제한 없이 하나 이상의 메시지들, 패킷들, 신호들, 파들, 전압 또는 전류 레벨들, 이들의 일부 조합 등을 전송, 수신, 전달, 생성, 버퍼링, 저장, 라우팅, 스위칭, 프로세싱 또는 이들의 조합 등을 수행하는 하나 이상의 노드들을 갖는 하나 이상의 네트워크들의 적어도 일부를 포함할 수 있다. 네트워크는 예시의 방식으로 제한 없이 무선 네트워크, 유선 네트워크, 인터넷, 인트라넷, 공중 네트워크, 사설 네트워크, 패킷-교환 네트워크, 회선-교환 네트워크, 애드 혹(ad hoc) 네트워크, 인프라스트럭처 네트워크, 공중-교환 전화 네트워크(PSTN: Public-Switched Telephone Network), 케이블 네트워크, 셀룰러 네트워크, 위성 네트워크, 광섬유 네트워크, 이들의 일부 조합 중 하나 이상을 포함할 수 있다.
[0073] 일 예에서, UE(102)는 AndroidTM, iOSTM, Kai OSTM 등을 포함하되 이에 한정되지 않는 임의의 운영 체제 상에 상주하는 실행 가능한 명령들의 세트를 통해 애플리케이션 서버(104)와 통신할 수 있다.
[0074] 개개의 UE(102)의 QoS 프로파일에 기초하여 네트워크 자원들을 할당하고 따라서 네트워크 환경(100)의 QoS를 최적화하기 위한 애플리케이션 서버(104)의 작동이 도 2 및 도 3과 관련하여 더욱 상세히 설명된다.
[0075] 도 2는 본 개시의 일 실시예에 따라 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)을 최적화하기 위한 제안된 시스템의 예시적인 표현을 예시한다. 일 예에서, 시스템은 도 1에 설명된 바와 같이 애플리케이션 서버(104)로서 구현될 수 있다.
[0076] 도 2에 묘사된 바와 같이, 애플리케이션 서버(104)는 하나 이상의 프로세서(들)(202)를 포함할 수 있다. 하나 이상의 프로세서(들)(202)는 하나 이상의 마이크로프로세서들, 마이크로컴퓨터들, 마이크로제어기들, 에지 또는 포그(fog) 마이크로제어기들, 디지털 신호 프로세서들, 중앙 처리 장치들, 로직 회로들 및/또는 동작 명령들에 기초하여 데이터를 프로세싱하는 임의의 디바이스들로서 구현될 수 있다. 다른 능력들 중에서, 하나 이상의 프로세서(들)(202)는 애플리케이션 서버(104)의 메모리(204)에 저장된 컴퓨터-판독 가능 명령들을 페칭(fetching)하여 실행하도록 구성될 수 있다. 메모리(204)는 네트워크 서비스를 통해 데이터 패킷들을 생성 또는 공유하기 위해 페칭 및 실행될 수 있는 하나 이상의 컴퓨터-판독 가능 명령들 또는 루틴들을 비일시적 컴퓨터 판독 가능 저장 매체에 저장하도록 구성될 수 있다. 메모리(204)는 예를 들어, RAM과 같은 휘발성 메모리 또는 EPROM, 플래시 메모리 등과 같은 비휘발성 메모리를 포함하는 임의의 비일시적 저장 디바이스를 포함할 수 있다.
[0077] 일 실시예에서, 애플리케이션 서버(104)는 인터페이스(들)(106)를 포함할 수 있다. 인터페이스(들)(106)는 예를 들어, I/O 디바이스들로 지칭되는 데이터 입력 및 출력 디바이스들, 저장 디바이스들 등을 위한 인터페이스들과 같은 다양한 인터페이스들을 포함할 수 있다. 인터페이스(들)(106)는 애플리케이션 서버(104)의 통신을 용이하게 할 수 있다. 인터페이스(들)(106)는 또한 애플리케이션 서버(104)의 하나 이상의 구성 요소들에 대한 통신 경로를 제공할 수 있다. 이러한 구성 요소들의 예들은 프로세싱 엔진(들)(208) 및 데이터베이스(210)를 포함하지만 이에 한정되지 않는다.
[0078] 프로세싱 유닛/엔진(들)(208)은 프로세싱 엔진(들)(208)의 하나 이상의 기능들을 구현하기 위해 하드웨어 및 프로그래밍(예를 들어, 프로그래밍 가능한 명령들)의 조합으로서 구현될 수 있다. 본원에 설명된 예들에서, 하드웨어와 프로그래밍의 이러한 조합들은 몇몇 상이한 방식들로 구현될 수 있다. 예를 들어, 프로세싱 엔진(들)(208)에 대한 프로그래밍은 비일시적 기계-판독 가능 저장 매체 상에 저장된 프로세서 실행 가능 명령들일 수 있고, 프로세싱 엔진(들)(208)에 대한 하드웨어는 이러한 명령들을 실행하는 프로세싱 자원(예를 들어, 하나 이상의 프로세서들)을 포함할 수 있다. 본 예들에서, 기계-판독 가능 저장 매체는 프로세싱 자원에 의해 실행될 때 프로세싱 엔진(들)(208)을 구현하는 명령들을 저장할 수 있다. 이러한 예들에서, 애플리케이션 서버(104)는 명령들 및 명령들을 실행하기 위한 프로세싱 자원을 저장하는 기계-판독 가능 저장 매체를 포함할 수 있거나, 기계-판독 가능 저장 매체는 애플리케이션 서버(104) 및 프로세싱 자원에 대해 분리되어 있지만 이들이 액세스할 수 있다. 다른 예들에서, 프로세싱 엔진(들)(208)은 전자 회로에 의해 구현될 수 있다.
[0079] 프로세싱 엔진(208)은 분석 엔진(212) 및 다른 엔진들(214)을 포함할 수 있다. 일 예에서, 프로세싱 엔진(208)은 에지-기반 마이크로 서비스 이벤트 프로세싱에 기초할 수 있지만 이에 한정되지 않는다.
[0080] 본 설명은 단일 UE(102)와 관련하여 설명될 것이지만, 이는 명확성을 위해서만 수행된다는 점에 유의할 수 있다. 본원의 청구대상의 접근법들은 본원의 청구대상의 범위를 벗어나지 않고 네트워크 환경(100)의 복수의 UE들(102)의 네트워크에서 구현될 수 있다.
[0081] 동작 중에, 애플리케이션(108)은 UE(102) 상에서 실행될 수 있다. 일 예에서, 애플리케이션(108)은 최종 사용자 요구에 따라 소프트웨어 로직을 실행하는 애플리케이션 유형일 수 있다. 실행하는 동안 애플리케이션(108)은 네트워크(100)로부터의 일부 자원들을 이용하도록 요구될 수 있다. 이러한 네트워크 자원들의 예들은 프로세싱 자원들 및 메모리 자원들을 포함할 수 있지만 이에 한정되지 않는다. 이러한 애플리케이션(108)은 실행 중에 UE(102)의 센서들과 통신할 수 있다. 개개의 UE(102) 상에서 실행되는 애플리케이션(108)은 대응하는 UE(102)로 하여금 요청을 생성하게 할 수 있다. 일 실시예에서, 그 후 요청은 애플리케이션 서버(104)에 의해 수신될 수 있다(도 3에서 블록 302로 묘사). 이러한 요청은 UE(102)에 의해 애플리케이션 서버(104)와 통신하여 이용 가능한 네트워크 자원들 중 일부를 이용하는 데 사용될 수 있다.
[0082] 다른 예에서, 요청은 통신 모뎀(110)을 통해 UE(102)로부터 애플리케이션 서버(104)로 전달될 수 있다. 통신 모뎀(110)은 임의의 하드웨어 기반 또는 소프트웨어 기반 컴퓨팅 디바이스로서 구현될 수 있다. 다른 예에서, 통신 모뎀(110)은 UE(102)의 일부일 수 있다. 또 다른 예에서, 통신 모뎀(206)은 2세대(2G)/3세대(3G)/롱 텀 이볼루션(LTE: Long Term Evolution)/협대역 사물 인터넷(NB-IoT: Narrow Band Internet of Things)/5세대(5G)/6세대(6G) 또는 근거리 네트워크(LAN)/광역 네트워크(WAN)를 통한 임의의 다른 통신 네트워크들에 기초한 모뎀일 수 있다. 그러나, 이러한 예들은 단지 예시일 뿐이며 요청은 본원의 청구대상의 범위를 벗어나지 않고 임의의 방식으로 UE(102)로부터 애플리케이션 서버(104)로 전달될 수 있다는 점에 유의할 수 있다.
[0083] 추가로 계속해서, UE(102)로부터 요청을 수신 시, 애플리케이션 서버(104)는 UE(102)와 PDU(Protocol Data Unit) 세션을 확립할 수 있다. UE(102)로부터 수신된 요청은 UE 파라미터들의 세트를 포함할 수 있다. 일 예에서, UE 파라미터들의 세트는 UE(102)에 의해 생성된 메타데이터(metadata)일 수 있다. 다른 예에서, UE 파라미터들의 세트는 센서 데이터, 애플리케이션 데이터 또는 이들의 조합 중 하나를 포함할 수 있다. 또 다른 예에서, 센서 데이터는 대응하는 UE(102)와 통신할 수 있는 복수의 센서들 중 하나로부터 획득될 수 있다. 또 다른 예에서, 애플리케이션 데이터는 하나 이상의 요인들에 기초하여 UE 상에서 실행되는 애플리케이션(108)으로부터 획득될 수 있다. 또 다른 예에서, 메타데이터는 애플리케이션을 실행하는 동안 UE(102)의 사용자에 의해 설정될 수 있는 사전 결정된 플래그 비트들 또는 일부 우선 순위 클래스 식별자 비트들을 포함할 수 있다. 이러한 우선 순위 클래스 식별자는 애플리케이션(108) 자체에 의해 즉시 설정될 수 있거나, 애플리케이션(108)을 UE(102)로 다운로드할 때 상수로서 설정될 수 있다. 이해되는 바와 같이, UE 파라미터는 애플리케이션(108)이 UE(102) 상에서 실행될 수 있고 상기 애플리케이션(108)의 실행에 의해 네트워크 자원들이 요구될 수 있는 방식을 나타낼 수 있다.
[0084] 추가로 계속해서, UE 파라미터는 그 후 수신된 요청으로부터 추출될 수 있다(도 3에서 단계 304로 묘사). 그 후, 추출된 UE 파라미터에 기초하여, 서비스 품질(QoS: Quality of Service) 프로파일이 대응하는 요청에 할당될 수 있다(도 3의 단계 306으로 묘사). 일 예에서, 분석 엔진(212)은 사전 규정된 매핑 기준에 기초하여 대응하는 요청에 QoS 프로파일을 할당할 수 있다. 다른 예에서, 분석 엔진(212)은 대응하는 UE로부터의 대응하는 요청을 레이턴시 민감 요청 및 레이턴시 둔감 요청 중 하나로 카테고리화할 수 있다.
[0085] 다른 예에서, 대응하는 UE로부터 수신된 요청의 QoS 프로파일을 레이턴시 민감 또는 레이턴시 둔감으로 카테고리화할 때, 분석 엔진(212)은 상기 애플리케이션들의 레이턴시 둔감도의 등급에 기초하여 QoS 프로파일을 복수의 카테고리들로 추가로 분류할 수 있다.
[0086] 추가로 계속해서, 할당된 QoS 프로파일에 기초하여, 복수의 네트워크 자원들 중 적어도 하나는 그 후 대응하는 요청을 생성하는 대응하는 UE에 할당될 수 있다(도 3에서 단계 308로 묘사). 일 예에서, 대응하는 요청을 생성하는 대응하는 UE에 할당되는 복수의 네트워크 자원들은 프로세싱 자원들의 할당, 메모리 자원들의 할당, 실행 우선순위 레벨 할당 또는 이들의 조합 중 하나를 포함할 수 있다. 다른 예에서, 분석 엔진(212)은 대응하는 요청을 생성하는 대응하는 UE로 하여금 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 프로세싱 자원들 중 하나를 이용하게 할 수 있다. 또 다른 예에서, 분석 엔진(212)은 대응하는 요청을 생성하는 대응하는 UE로 하여금 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 캐시 메모리들 중 하나를 이용하게 할 수 있다. 또 다른 예에서, 분석 엔진(212)은 특정 시간 기간 동안 대응하는 요청 실행의 지연을 야기할 수 있다.
[0087] 또 다른 예에서, 분석 엔진(212)은 할당된 메모리 자원들에 기초하여 캐싱 메커니즘을 할당할 수 있다. 또 다른 예에서, QoS 프로파일을 결정하고 네트워크 자원들을 할당할 때, 분석 엔진(212)은 새로운 식별된 QoS 프로파일을 구성하고 매핑하는 애플리케이션 유형을 통신 모뎀(110) 및 네트워크(106)가 인식하도록 애플리케이션(108)으로 하여금 AT(Application Type) 커맨드들을 사용하게 할 수 있다. AT 커맨드 인터페이스들은 네트워크가 식별 및 적용할 QoS 프로파일의 올바른 유형을 알도록 애플리케이션 유형, 센서 유형 및 필요한 시그널링 식별자들을 식별할 수 있다.
[0088] 또 다른 예에서, 분석 엔진(212)은 적절한 컴퓨트 알고리즘들의 가능한 캐싱 및 실행을 포함하는 QoS 프로파일의 필요한 속성들을 실행하기 위해 IoT 통신 네트워크(106)의 아키텍처 엔티티들로 하여금 QoS 프로파일을 판독하고 해석하게 할 수 있다. IoT 통신 네트워크(106)와 같은 IoT 무선 액세스 네트워크의 이러한 추가 컴퓨트 엔티티들은 특정 애플리케이션들에 대한 지능형 데이터 프로세싱을 수행할 수 있다.
[0089] 또 다른 예에서, 적절한 무선 액세스 네트워크(RAN: Radio Access Network) 시그널링 메커니즘들을 통해 적절하게 지능형 데이터 프로세싱 및 구성을 수행하기 위해 상이한 레벨들의 캐싱 및 컴퓨테이션 엔티티들이 레이턴시 둔감 애플리케이션 유형에 대해 규정될 수 있다.
[0090] 또 다른 예에서, 네트워크 아키텍처(100)의 시스템 및 흐름은 AT 커맨드들에 기초한 애플리케이션 트리거들, 지능적으로 우선 순위 변경을 식별하는 네트워크, 및 UE(102) 또는 IoT RAN 엔티티(도 1 및 도 2에 미도시)를 식별하고 적절하게 시그널링하는 애플리케이션 서버(104)와 같은 이하의 방법들 중 임의의 것에 기초하여 레이턴시 민감인 것과 둔감인 것 사이에서 동적으로 우선 순위를 변경하도록 규정될 수 있다.
[0091] 또 다른 예에서, 애플리케이션 우선 순위 변경 유형은 IoT 통신 네트워크(106)에 의해 지능적으로 검출되고 결국 QoS 프로파일을 구성할 수 있다. 또 다른 예에서, 분석 엔진(212)은 애플리케이션 유형의 인식에 기초하여 애플리케이션 서버(104)로 하여금 IoT 통신 네트워크(106)뿐만 아니라 통신 모뎀(110)에서 새로운 QoS 프로파일을 구성하게 할 수 있다.
[0092] 또 다른 예에서, UE(102)와 같은 센서 기반 IoT 디바이스에 대해, 트래픽 특성화는 미리 규정된 기간에 트래픽 데이터의 바이트들의 세트가 송신되고 그 후 다음 타이머가 만료될 때까지 아무 것도 송신되지 않도록 이루어진다. 이러한 경우들에 있어서, IoT 통신 네트워크(106)는 RRC 비활성 상태를 규정하지 않기로 결정할 수 있고, 자원들을 해제하고 다른 필요한 디바이스들에 대해 동일한 것을 재사용할 수 있다.
[0093] 위의 애플리케이션 유형들을 수용하기 위해, 애플리케이션이 레이턴시 둔감인지, GSM 이볼루션을 위한 향상된 데이터 레이트들(EDGE) 및/또는 무선 액세스 노드들에서 캐싱 지원 및/또는 연합 프로세싱 능력들을 필요로 하는지를 식별하는 데 도움이 될 수 있는 새로운 QoS 프로파일들이 구현될 수 있다. 네트워크 아키텍처(100)는 특정 애플리케이션들에 대한 지능형 데이터 프로세싱을 수행할 수 있는 RAN의 추가 컴퓨트 엔티티들을 지원할 수 있다.
[0094] 일 예에서, 네트워크 아키텍처(100)는 새로운 QoS 클래스들을 적절히 할당하기 위해 IoT 통신 네트워크(106)에 의해 사용될 수 있는 IoT 애플리케이션 카테고리 또는 유형을 인식할 수 있다. 이는 네트워크에서 자원들을 최적화하는 데 필요할 수 있으며, 새로운 QoS 카테고리들은 이러한 애플리케이션 유형들을 취급할 수 있다. 추가로, 시그널링은 일부 애플리케이션 우선 순위가 상대적이기 때문에 (예를 들어, 레이턴시 둔감 유형으로부터 레이턴시 민감 유형까지) 카테고리 유형들 간의 우선 순위들을 변경할 수 있다. 구체적으로, 논-액세스 계층(NAS)에 대한 애플리케이션(108) 사이의 새로운 모뎀 인터페이스는 새로운 애플리케이션 카테고리들을 규정된 새로운 QoS 클래스 식별자들에 매핑할 수 있다. 이러한 IoT 애플리케이션 카테고리들은 또한 추가 하위 카테고리들을 지원할 수 있다.
[0095] 다른 예에서, 확장된 QoS 템플릿의 QoS 메커니즘이 제공될 수 있고, 메커니즘은 레이턴시 둔감 애플리케이션들을 위한 새로운 QoS 템플릿을 해석하고 적용하는 데 사용될 수 있다. 일 실시예에서, 서버(104)는 애플리케이션의 속성을 정의하는 것을 돕는 QoS 템플릿 또는 프로파일을 규정할 수 있다.
[0096] 또 다른 예에서, 레이턴시 둔감 애플리케이션들은 다음과 같은 상이한 사용 사례 시나리오들을 충족시키기 위해 4 개의 상이한 하위 카테고리들로 분류될 수 있다.
등급 1 - 24시간 이상까지 지연 허용.
등급 2 - 수 시간 내 그러나 24시간 미만까지 지연 허용.
등급 3 - 10분 단위로 지연 허용.
등급 4 - 분 단위 그러나 10분 미만의 지연 허용.
[0097] 또 다른 예에서, 네트워크 자원들을 할당하는 것은 캐싱의 필요성, 캐싱의 장소, 프로세싱에 대한 요건, 프로세싱의 특성, 프로세싱 표시자들, 패킷들의 연속, 데이터의 평균화, 진입 데이터의 임계값 결정, 특정된 데이터 집계 메커니즘의 적용에 대한 필요성을 결정하는 것을 추가로 포함할 수 있다. 그러나, 이러한 예들은 단지 예시일 뿐이며 어떠한 방식으로든 본원의 청구대상의 범위를 제한하는 것으로 해석되어서는 안 된다는 점에 유의할 수 있다. 임의의 다른 네트워크 자원 할당 기술도 본원의 청구대상의 범위 내에 포함될 것이다.
[0098] 이러한 예시적인 양태 및 실시예와 다른 예시적인 양태들 및 실시예들이 도 4 및 도 5에서 설명되었다.
[0099] 도 4는 본 개시의 일 실시예에 따라 QoS 설정을 위한 컴퓨테이션 레벨들의 예시적인 시퀀스도 표현을 예시한다.
[00100] 등록 -> PDU 확립(레이턴시 둔감 유형) -> SMF(406)는 캐싱하기 위한 RAN(402)(CU-UP) 또는 UPF(410), 및 캐싱 곤련 파라미터들, 이를테면 저장 공간, 데이터 프로세싱/패키징, UPF(410)에 기초한 저장 클래스들, 관련 타이머들 등을 나타낸다.
[00101] 단계 (414-1)에서, 애플리케이션(108)은 애플리케이션 유형(레이턴시 민감)을 모뎀(110)으로 전송할 수 있다. 단계 (414-2)에서, 모뎀(110)은 RAN(402)에 PDU 확립 요청을 전송할 수 있다. 단계 (414-3)에서, 모뎀(110)은 무선 자원 제어(RRC: Radio Resource Control) 연결 요청을 RAN(402)에 전송할 수 있다. 단계 (414-4)에서, RAN(402)은 RRC 연결 확인을 모뎀(110)으로 다시 전송할 수 있다. 단계 (414-5)에서, AMF(404)는 SMF 선택을 수행할 수 있다. 단계 (414-6)에서, AMF(404)는 SMF(416)로 SM 컨텍스트 요청을 생성하기 위한 Nsmf(즉, SMF가 나타내는 서비스 기반 인터페이스) PDU 세션을 전송할 수 있다.
[00102] 단계 (414-7)에서, SMF(406)는 SM 응답을 생성하기 위해 Nsmf PDU 세션을 AMF(404)로 다시 전송할 수 있다. 단계 (414-8)에서, AMF(404)는 SMF(406)로 설정된 컨텍스트 요청을 전송할 수 있다. 단계 (414-9)에서, SMF(406)는 AMF(404)로 설정된 컨텍스트에 대한 확인을 전송할 수 있다.
[00103] 단계 (414-10)에서, SMF(406)는 책 제어 기능(PCF: Policy Control Function)을 선택할 수 있고, 단계 (414-11)에서, SMF(406)는 확립 원인을 포함하는 SM 개시 정책 연관을 수정할 수 있고, 단계 (414-12)에서 SMF(406)는 UPF를 선택할 수 있다. 단계 (414-13)에서 SMF(406)는 N1 N2 메시지를 AMF(404)로 전달할 수 있다. 단계 (414-14)에서 SMF(406)는 캐싱을 위한 추가 파라미터 IE를 갖는 PFCP 메시지를 UPF(410)로 전송할 수 있다. 단계 (414-15)에서 AMF(404)는 새로운 QFI를 갖는 PDU 세션 요청을 RAN(402)으로 전송할 수 있다. 단계 (414-16)에서 RAN(402)은 PDU 확립 확인응답(acknowledgement)을 모뎀(110)으로 전송할 수 있다.
[00104] 도 5a 내지 도 5e는 애플리케이션과 통신 모뎀 사이의 애플리케이션 유형(AT) 커맨드들의 예시적인 시퀀스도 표현을 예시한다. 애플리케이션은 108로서 구현될 수 있고 통신 모뎀은 도 1에 설명된 바와 같이 통신 모뎀(110)으로서 구현될 수 있다. 도 5a의 시퀀스도에서, UE(102)와 모뎀(110)은 단계들 (502-1) 내지 (502-11)을 수행할 수 있다. 도 5b의 시퀀스도에서, UE(102)와 모뎀(110)은 단계들 (504-1) 내지 (504-14)를 수행할 수 있다. 도 5c의 시퀀스도에서, UE(102)와 모뎀(110)은 단계들 (506-1) 내지 (506-3)을 수행할 수 있다. 도 5d의 시퀀스도에서, UE(102)와 모뎀(110)은 단계들 (508-1) 내지 (508-4)를 수행할 수 있다. 도 5e의 시퀀스도에서, UE(102)와 모뎀(110)은 단계들 (510-1) 내지 (510-2)를 수행할 수 있다.
[00105] 모뎀이 센서 데이터를 수신하면, 제어 채널 또는 데이터 채널 및 센서 능력을 통해 동일한 센서 데이터가 전송될 것이며 애플리케이션으로부터 수신될 때 동일한 센서 데이터가 UE 능력 메시지, 애플리케이션 유형, 애플리케이션에 대한 위의 데이터를 통해 송신될 것이고, 모뎀은 아래와 같이 Service Request Establishment_Cause IE를 통해 PDU 확립/수정/등록 절차 중에 동일한 것을 사용하여 네트워크로 송신할 수 있다 점에 유의할 수 있다.
확립 원인 ::= ENUMERATED {긴급, 높은 우선 순위 액세스, mt-액세스, mo-시그널링, mo-데이터, mo-음성 호출, mo-비디오 호출, mo-SMS, mps-우선 순위 액세스, mcs-우선 순위 액세스, IoT - 레이턴시 민감/IoT - 레이턴시 둔감, IoT - 데이터 신뢰성, 스페어4, 스페어3, 스페어2, 스페어1}.
[00106] 일단 네트워크가 위의 확립 원인을 수신하면, RAN은 이를 AMF로 전달한 다음 SMF로 그리고 SMF를 통해 PCF로 전달할 것이다. PCF는 최종적으로 기존 메커니즘을 사용하여 그에 따라 QCI/5QI 및 다른 파라미터들을 설정할 것이다. 유사한 흐름이 4G 또는 기타 기술에도 적용되며 5G NR에만 한정되는 것은 아니다. 여기서는 5G NR을 단지 예로 들어 설명한다.
[00107] 도 5f는 본 개시의 일 실시예에 따른 일반적인 네트워크 아키텍처에서 캐싱 레벨의 예시적인 블록도 표현을 예시한다.
[00108] 상술한 바와 같이, 할당된 QoS 프로파일에 기초하여, 복수의 네트워크 자원들 중 적어도 하나가 대응하는 요청을 생성하는 대응하는 UE에 할당될 수 있다. 일 예에서, 레이턴시 민감도 레벨에 기초하여, 상이한 캐싱 레벨이 규정될 수 있다. 도 5f는 네트워크 자원들 및 컴퓨테이션 능력을 절약하기 위해 레이턴시 둔감 사용 사례들에서 컨텐츠를 캐싱하는 상이한 가능한 방식들 중 하나를 묘사한다. 일반적인 네트워크 아키텍처에서의 캐싱 레벨은 UE(102), 액세스 네트워크(512), 코어 네트워크(514) 및 데이터 네트워크(DN: Data Network)/인터넷(412)을 포함할 수 있다.
[00109] 추가로 묘사된 바와 같이, C1-C6(즉, UE(102), 무선 액세스 네트워크(RAN)(402), 사용자 평면 기능(UPF)(410), 데이터 네트워크(DN)(412), 액세스 및 모빌리티 관리 기능(AMF)(404), 세션 관리 기능(SMF)(406), 애플리케이션 기능(AF)(516) 및 정책 제어 기능(PCF)(408))은 레이턴시 둔감 사용 사례들 또는 서비스들에 대해 확인되었거나 구성된 IoT 디바이스 또는 UE(102)로부터 획득된 데이터에 대해 수행될 수 있는 캐싱의 상이한 가능 위치일 수 있다.
[00110] 캐싱의 보다 바람직한 위치는 중앙 집중식 유닛 사용자 평면(CU-UP: Centralized Unit User Plane)의 RAN(402)에 있을 수 있으며 (동일한 것을 구성하는 마스터로서) SMF(406)를 통해 동일한 것이 전달될 것이다. SMF(406)가 캐싱 및 컴퓨테이션을 수행하기 위해 UPF(410) 또는 CU-UP와 통신하는 메커니즘은 PDU 확립 절차들 중에 QoS 프로파일을 설정하는 동안 아래에 규정된 흐름들의 일부로서 전달될 것이다. QoS 템플릿이 적용되면 시그널링의 일부로서의 SMF(406) 엔티티는 아래와 같이 추가 파라미터들과 함께 캐시 위치에 추가 정보를 제공해야 한다. 흐름의 일부로서, 파라미터들은 컨텐츠 캐싱(데이터 무결성 포함)과 관련하여 SMF(406)에 의해 전달되거나 다음과 같은 5QI 값들에 기초하여 설정된 디폴트 구성을 가질 수 있다.
메모리 풋프린트 - 이는 UPF 또는 CU-UP가 UE 또는 디바이스들의 클래스별로 컨텐츠 캐싱을 위한 메모리를 할당하는 데 도움이 된다.
컨텐츠가 캐싱되는 시간 - 이는 컨텐츠가 얼마나 오랫동안 캐싱될 필요가 있는지 나타내는 타이머이다.
컨텐츠 캐싱과는 별개로, 이하의 상이한 레벨의 캐싱이 - L0 - 일반 데이터 또는 메시지들만 캐싱됨을 의미, 경보/경고 - L1 - 알람들/경고들도 캐싱됨, 구성 - L2 - 구성들이 또한 캐싱되는 등의 메시지들을 보기 위해 규정될 것이다.
[00111] 위의 새로 제안된 스키마(schema) 또는 구조는 아래에 제시된 바와 같을 수 있다.
[00112] 위에서 설명된 모든 구성은 PCF가 QoS 프로파일을 구성한 후 SMF(406)에 의해 캐싱 엔티티로 전달될 수 있다. 긴급 서버로 메시지가 플러싱(flushing)될 때를 나타내는 타이머와 별도로, 타이머가 만료되기 전에 할당된 메모리가 가득 차면 메시지가 전송할 수 있거나 컨텐츠를 전송하려는 시도들의 횟수가 최대 한계에 도달되면 플러싱될 수 있음에 또한 유의할 수 있다. 추가로, 동일한 것에 대한 최대 제한이 위 구조의 일부로서 전달될 것이다.
[00113] 컴퓨테이션 레벨들, 캐싱과 유사하게, 컴퓨테이션 레벨들은 또한 QoS 설정의 통신 부분일 수 있다. 컴퓨테이션은 CU-UP, UPF 또는 모든 EDGE 컴퓨테이션 또는 임의의 알고리즘 또는 수학적 통계 모델들이 구현될 수 있는 아키텍처에 도입되어야 하는 완전히 새로운 엔티티와 같은 상이한 엔티티들에서 발생할 수 있다. 예를 들어, 농업-IoT 시나리오를 위해 수집될 필요가 있는 센서 데이터는 EDGE 계산을 위해 또는 지정된 엔티티에서 구성될 수 있다. 예를 들어, 이러한 IoT 시스템에서 올바른 QoS 프로파일을 구성하기 위해 시스템에 걸쳐 애플리케이션 유형을 전달하는 상이한 세 가지 방식들이 있을 수 있다. 일 예에서, 이것은 AT 커맨드들을 사용하여 구현될 수 있다. 이러한 경우들에 있어서, 애플리케이션과 모뎀은 QoS 프로파일을 교환하기 위해 AT 인터페이스를 통해 상호 작용할 수 있다. 다른 예에서, 이러한 구현은 애플리케이션 서버를 사용하여 수행될 수 있다. 이러한 경우들에 있어서, 애플리케이션 서버는 QOS 프로파일을 구성할 수 있다. 또 다른 예에서, 이러한 구현은 자동으로 수행될 수 있다.
[00114] 도 5g는 본 개시의 일 실시예에 따라 시스템에 걸쳐 애플리케이션 유형의 자동 검출을 위한 방법(500)의 예시적인 흐름도 표현을 예시한다.
[00115] 블록 (518-1)에서, 네트워크가 초기에 PDU 세션을 확립하는 동안 디폴트 QoS를 설정할 때, RAN 레벨의 네트워크는 데이터를 계속 수집하여 트래픽 패턴을 분석한다. 본 방법은 QoS 프로파일 레이턴시의 민감도를 결정한다. 그렇다면, 블록 (518-3)에서, 네트워크는 5QI를 "Y"로 설정하고 관련된 모든 엔티티들 - PCF, AMF, SMF, RAN 및 UE에 동일한 것을 전달한다. 그렇지 않은 경우, 단계 (518-2)에서, 네트워크는 5QI를 "X"로 설정하고, 관련된 모든 엔티티들 - PCF, AMF, SMF, RAN 및 UE에 동일한 것을 전달한다.
[00116] 무선 지능형 제어기(RIC: Radio Intelligent Controller)의 일부 또는 CU-UP 또는 DU-UP의 일부에서, 데이터 수집 및 트래픽 패턴 분석이 발생할 것으로 예상된다. 트래픽 패턴이 분석되면, 섹션 3(AT 커맨드 규정 후)에 규정된 대로 아래 흐름을 사용하여 원인에 대해 AMF - SMF - PCF로 공유하는 데 사용될 것이며, 이에 의해 올바른 QCI가 설정된다. 초기에 기존 절차에 따른 디폴트 QCI를 사용하여 위의 절차가 원하는 대로 QoS 프로파일 설정을 세분화할 때까지 규정한다.
[00117] 애플리케이션 서버(210) 구성을 사용하는 시스템에 걸친 애플리케이션 유형의 통신이 도 5h에서 설명될 수 있다. 도 5h에 도시된 바와 같이, 단계 (520-1)에서 UE(202)는 완료된 절차/PDN 확립 절차를 부착하고 디폴트 QoS가 할당된다. 단계 (520-2)에서, 애플리케이션 서버(104)는 네트워크(208)와 애플리케이션 레벨 구성 {IMEI, QCI, 5QI, Param1..N}을 수행할 수 있다. 단계 (520-3)에서, 네트워크(106)는 UE(102)와 애플리케이션 레벨 구성 {QCI, 5QI, Param1..N}을 수행할 수 있다. 단계 (520-4)에서, UE(102)는 새로 설정된 QoS 프로파일과 NW도 사용한다. 따라서, 설정된 레벨 (C1...C6)에 따라 캐싱을 수행한다.
[00118] AT 커맨드 인터페이스들을 사용하여 시스템에 걸친 애플리케이션 유형의 통신은 다른 방식일 수 있으며, 여기서 IoT 디바이스(102)의 애플리케이션(108)은 애플리케이션 유형뿐만 아니라 센서 데이터 및 그 능력에 대해 모뎀(110)에 전달될 수 있다. 이러한 AT 커맨드들을 사용하여, 모뎀(110)은 센서 능력, 센서 데이터뿐만 아니라 애플리케이션 유형을 인식하게 될 수 있다. 또한, 애플리케이션에 의해 필요에 따라 네트워크에 의해 송신된 임의의 구성을 송신하기 위해 유사한 AT 인터페이스가 필요할 수 있다. 이하는 아래와 같은 AT 인터페이스/포트를 통해 모뎀과 애플리케이션 간에 교환되도록 규정된 AT 커맨드들의 세트이다:
[00119] 위 커맨드들에 대한 가능한 응답들이 아래 표 1에 제공된다.
표 1
[00120] 설명: SENSOR 데이터/능력 수신을 관리하는 AT 커맨드. 전원을 켤 때 또는 새로운 세션 확립 중에 애플리케이션에 의해 모뎀으로 송신됨.
[00121] 규정된 값들: 센서 데이터/센서 디바이스의 능력 정보를 공유함.
[00122] 설명: 이 커맨드는 그 능력 및 해당 시간에 이용 가능한 임의의 센서 데이터와 함께 처음 전원이 켜질 때 애플리케이션에 의해 송신됨.
[00123] 규정된 값들:
<cmd>:
"SENSOR_CAP" - 디바이스 능력 정보 공유
<Params>:
<Sensor_Capability> :: { <Sensor_Type> = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO.....} }
<cmd>:
"SENSOR_DATA" - 디바이스 센서 데이터 요청
<Params>:
<Sensor_Data> :: { { <Sensor_Data> = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO.....} , {<Sesndor_Data> = Array[][]}}
AT%SENSORREQ
[00124] 위 커맨드들에 대한 가능한 응답들이 아래 표 2에 제공된다.
표 2
[00125] 설명: SENSOR 데이터/능력을 요청하는 AT 커맨드. REQUEST는 모뎀으로부터 애플리케이션으로 송신됨.
[00126] 규정된 값들: 센서 디바이스의 센서 데이터/능력 정보 획득.
[00127] 설명: 이 커맨드는 센서 데이터 및 센서 디바이스의 능력을 얻기 위해 모뎀에 의해 사용됨. 이는 특정 세션을 활성화하기 전에 또는 첫 번째 부착/TAU 등 중에 모뎀에 의해 획득됨.
[00128] 규정된 값들:
<cmd>:
"REQUEST_CAP" - 디바이스 능력 정보 요청
<ResponseType>:
Response will be <Sensor_Capability> :: { <Sensor_Type> = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO.....} }
<cmd>:
"REQUEST_SENSORDATA" - 디바이스 센서 데이터 요청
<ResponseType>:
Response will be <Sensor_Data> :: { { <Sensor_Type> = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO.....} , {<Sesndor_Data> = Array[][]}}
AT%SENSOREV
[00129] 위의 커맨드들에 대한 가능한 응답들이 아래 표 3에 제공된다.
표 3
[00130] 설명: 이 요청되지 않은 커맨드는 해당 서비스에 영향을 미치는 센서 데이터에 변화가 있음을 호스트에 나타냄. 그 후 모뎀은 AT%SENSORDREQ를 사용하여 추가 데이터를 질의함.
[00131] 규정된 값들
<cmd> : 수치 파라미터
1 - 요청하지 않은 센서 데이터 표시 인에이블
<event1> : 수치 파라미터
0 - 센서 능력 변경 표시
1 - 센서 데이터 변경 표시
2 - 센서 유형을 이용 불능
3 - 센서 유형 이용 가능
3 -99 - 예약됨
4 <event2> : 스트링
0 - event1이 4가 아닌 경우 송신됨
AT%SENSORCIND
[00132] 위의 커맨드들에 대한 가능한 응답들이 아래 표 4에 제공된다.
표 4
[00133] 설명: 애플리케이션 서버 또는 애플리케이션과 관련된 네트워크에 의해 송신될 때 모뎀에 의해 구성 정보를 애플리케이션에 공유하라는 AT 커맨드.
[00134] 규정된 값들: 센서 디바이스의 센서 구성 정보 획득.
[00135] 설명: 이 커맨드는 센서 구성 데이터를 공유하기 위해 모뎀에 의해 사용됨.
[00136] 규정된 값들:
<cmd>:
"CONFIG_IND" - 네트워크 또는 애플리케이션 서버에 의해 규정된 구성 파라미터들인 param1..N을 갖는 센서 디바이스에 대한 애플리케이션 레벨 구성 변화를 나타냄
<ResponseType>:
OK / ERROR
AT%APPTYPE
[00137] 위의 커맨드들 대한 가능한 응답들이 아래 표 5에 제공된다.
표 5
[00138] 설명: 애플리케이션에 의해 송신된 모뎀에 대한 속성들과 함께 애플리케이션 유형을 공유하라는 AT 커맨드.
[00139] 규정된 값들: 애플리케이션에 의해 애플리케이션 유형 정보를 획득하는 모뎀.
[00140] 설명: 이 커맨드는 모뎀이 애플리케이션 유형을 알게 하기 위해 애플리케이션에 의해 사용됨.
[00141] 규정된 값들:
<cmd>:
"APP_TYPE" - 네트워크 또는 애플리케이션 서버에 의해 규정된 구성 파라미터들인 param1..N을 갖는 IoT 디바이스의 애플리케이션 레벨 구성을 나타냄
Param 1...N은 이하와 같은 유형 또는 속성을 나타냄 -
레이턴시 민감
레이턴시 둔감
큰 트래픽
랜덤 웨이크업(Wakeup)
요구되는 높고 즉각적인 TP
보장된 전달
등
<ResponseType>:
OK / ERROR
AT%APPIND
[00142] 위의 커맨드들에 대한 가능한 응답들이 아래 표 6에 제공된다.
표 6
[00143] 설명: 애플리케이션 서버 또는 애플리케이션과 관련된 네트워크에 의해 송신될 때 모뎀에 의해 구성 정보를 애플리케이션에 공유하하는 AT 커맨드.
[00144] 규정된 값들: IoT 디바이스의 애플리케이션 측 구성 정보 획득.
[00145] 설명: 이 커맨드는 애플리케이션 구성 데이터를 공유하기 위해 모뎀에 의해 사용됨.
[00146] 규정된 값들:
<cmd>:
"APP_Config" - 네트워크 또는 애플리케이션 서버(210)에 의해 규정된 구성 파라미터들인 param1..N을 갖는 센서 디바이스에 대한 애플리케이션 레벨 구성 변화를 나타냄.
Param -
레이턴시 민감
레이턴시 둔감
큰 트래픽
랜덤 웨이크업
요구되는 높고 즉각적인 TP
보장된 전달 등
<ResponseType>:
OK / ERROR
[00147] 본 개시의 일 실시예에 따라 5세대(5G) 네트워크 아키텍처에서 애플리케이션 유형(AT) 커맨드들의 예시적인 시퀀스도 표현을 예시하는 도 5i를 참조한다.
[00148] 단계 (522-1)에서, UE는 네트워크 상에 등록될 수 있다. 단계 (522-2)에서, 애플리케이션(108)은 애플리케이션 유형(레이턴시 민감)을 모뎀(110)으로 전송할 수 있다. 단계 (522-3)에서 모뎀(110)은 RAN(402)으로 PDU 확립 요청을 전송할 수 있다. 단계 (522-4)에서 모뎀(110)은 무선 자원 제어(RRC) 연결 요청을 RAN(402)으로 전송할 수 있다. 단계 (522-5)에서 RAN(402)은 RRC 연결 확인을 모뎀(110)으로 다시 전송할 수 있다. 단계 (522-6)에서 AMF(404)는 SMF 선택을 수행할 수 있다. 단계 (522-7)에서, AMF(404)는 SM 컨텍스트 요청을 생성하기 위해 SMF(406)로 Nsmf(즉, SMF가 나타내는 서비스 기반 인터페이스) PDU 세션을 전송할 수 있다.
[00149] 단계 (522-8)에서 SMF(406)는 SM 응답을 생성하기 위해 Nsmf PDU 세션을 AMF(404)로 다시 전송할 수 있다.
[00150] 단계 (522-9)에서 SMF(406)는 정책 제어 기능(PCF)을 선택할 수 있고 단계 (522-10)에서 SMF(406)는 확립 원인을 포함하는 SM 개시된 정책 연관을 수정할 수 있고, 단계 (522-11)에서 SMF(406)는 UPF를 선택할 수 있다. 단계 (522-12)에서 SMF(406)는 N1 N2 메시지를 AMF(404)로 전달할 수 있다. 단계 (522-13)에서 AMF(404)는 새로운 QFI를 갖는 PDU 세션 요청을 RAN(402)으로 전송할 수 있다. 단계 (522-14)에서 RAN(402)은 모뎀(110)으로 PDU 확립 확인응답을 전송할 수 있다. 단계 (522-15)에서 모뎀(110)은 AT% APPCIND를 애플리케이션(108)으로 전송할 수 있다. 단계 (522-18)에서 모뎀(110)과 DN(412) 사이에서 메시지가 전달될 수 있다.
[00151] 도 5j는 본 개시의 일 실시예에 따라 5세대(5G) 네트워크 아키텍처에서 새로운 논-액세스 계층(NAS)을 사용하는 애플리케이션 유형(AT) 커맨드들의 예시적인 시퀀스도 표현을 예시한다.
[00152] 단계 (524-1)에서 UE(102)는 네트워크 상에 등록될 수 있다. 단계 (524-2)에서, 애플리케이션(108)은 애플리케이션 유형(레이턴시 민감)을 모뎀(110)으로 전송할 수 있다. 단계 (524-3)에서 모뎀(110)은 RAN(402)으로 PDU 확립 요청을 전송할 수 있다. 단계 (524-4)에서 모뎀(110)은 무선 자원 제어(RRC) 연결 요청을 RAN(402)으로 전송할 수 있다. 단계 (524-5)에서, RAN(402)은 RRC 연결 확인을 모뎀(110)으로 다시 전송할 수 있다. 단계 (524-6)에서 AMF(404)는 SMF 선택을 수행할 수 있다. 단계 (524-7)에서, AMF(404)는 SM 컨텍스트 요청을 생성하기 위해 SMF(406)로 Nsmf(즉, SMF가 나타내는 서비스 기반 인터페이스) PDU 세션을 전송할 수 있다.
[00153] 단계 (524-8)에서, SMF(406)는 SM 응답을 생성하기 위해 Nsmf PDU 세션을 AMF(404)로 다시 전송할 수 있다. 단계 (524-9)에서 AMF(404)는 SMF(406)로 설정된 컨텍스트 요청을 전송할 수 있다. 단계 (524-10)에서 SMF(406)는 AMF(404)로 설정된 컨텍스트에 대한 확인을 전송할 수 있다. 단계 (524-11)에서 SMF(406)는 정책 제어 기능(PCF)을 선택할 수 있고, 단계 (524-12)에서 SMF(406)는 확립 원인을 포함하는 SM 개시된 정책 연관을 수정할 수 있고, 단계 (524-13)에서 SMF(406)는 UPF를 선택할 수 있다. 단계 (524-14)에서 SMF(406)는 N1 N2 메시지를 AMF(404)로 전달할 수 있다. 단계 (524-15)에서 AMF(404)는 새로운 QFI를 갖는 PDU 세션 요청을 RAN(402)으로 전송할 수 있다. 단계 (524-16)에서 RAN(402)은 모뎀(110)으로 PDU 확립 확인응답을 전송할 수 있다. 단계 (524-17)에서 모뎀(110)은 AT% APPCIND를 애플리케이션(108)으로 전송할 수 있다. 단계 (524-18)에서 메시지는 모뎀(110)과 DN(412) 사이에서 전달될 수 있다.
[00154] 도 5k는 본 개시의 일 실시예에 따라, 5세대(5G) 네트워크 아키텍처에서 핸드오버 동안/핸드오버 후에 손실된 사용자 장비 컨텍스트/애플리케이션 유형 손실 시나리오 동안 새로운 논-액세스 계층(NAS)을 사용하는 애플리케이션 유형(AT) 커맨드들의 예시적인 시퀀스도 표현을 예시한다.
[00155] 단계 (526-1)에서 UE(102)는 핸드오버 등록을 수행할 수 있다. 단계 (526-2)에서 PCF는 UE(102)로부터 컨텍스트를 검색하기 위해 SMF(406)를 개시할 수 있다. 단계 (526-3 내지 526-11)에서 UE로부터 컨텍스트가 검색될 수 있다.
[00156] 단계 (526-12)에서, SMF(406)는 확립 원인을 포함하는 SM 개시된 정책 연관을 수정할 수 있고, 단계 (526-13)에서 SMF(406)는 UPF를 선택할 수 있다. 단계 (526-14)에서 SMF(406)는 N1 N2 메시지를 AMF(404)로 전달할 수 있다. 단계 (526-15)에서 AMF(404)는 새로운 QFI를 갖는 PDU 세션 요청을 RAN(402)으로 전송할 수 있다. 단계 (526-16)에서 RAN(402)은 모뎀(110)으로 PDU 확립 확인응답을 전송할 수 있다. 단계 (526-17)에서 모뎀(110)은 AT% APPCIND를 애플리케이션(108)으로 전송할 수 있다. 단계 (526-18)에서, 메시지는 모뎀(110)과 DN(412) 사이에서 전달될 수 있다.
[00157] 다른 실시예에서, 자원 제어가 센서 유형의 인식에 의해 달성될 수 있는 방식은 아래에서 설명될 수 있다:
AS(Access Stratum)의 RRC(Radio Resource Control) - 모뎀 스택의 일부는 자원 및 모빌리티 관리에서 중요한 역할을 함. RRC 절차의 일부 - RRC는 RRC_IDLE, RRC_CONNECTED, RRC_INACTIVE의 3 개의 주요 상태들을 유지함.
RRC_IDLE: RRC 연결이 해제됨
RRC_CONNECTION: 활성 세션이 진행 중 - 데이터/시그널링
RRC_INACTIVE: 활성 데이터 전달이 완료되었지만 추가 데이터 전달을 예상하여 연결이 여전히 유지되는 비활성 기간.
[00158] 그러나, 애플리케이션이 고정된 양의 데이터만을 송신할 필요가 있고 나중에 더 이상 송신할 것이 없는 특정 IoT 사용 사례들에서, 이후 네트워크는 즉시 연결을 해제하고 디바이스를 RRC_INACTIVE 상태로 유지하지 않을 수 있으며, 이에 의해 네트워크 자원을 해제한다.
[00159] 이를 위해, UE(102)는 기존 메커니즘을 사용하는 네트워크가 디바이스에 RRC_Inactive_Timer를 0으로 표시하여 RRC 연결이 즉시 해제되도록 이러한 특정 정보를 네트워크(RAN)에 송신할 필요가 있을 수 있다. 위의 정보는 UE에 의해 아래에서 제시되는 같이 능력 정보 IE의 RAN 부분으로 전달될 것이다.
<RRC 비활성 상태 표시>
[00160] 새로운 필드 UE-Sensor-Capability가 이하와 같이 UE Capability Information-NB 객체에 추가될 수 있다.
[00161] 센서 능력들은 네트워크가 다양한 효율성 사용 사례들에 대해 동일하게 사용하도록 돕기 위해 UE-Sensor-capability_NB 시퀀스에 추가될 수 있다. 이 실시예에서 센서들의 도움으로 움직임을 감지하는 NB-IoT 디바이스의 능력은 UE-Sensor-Capability-NB 시퀀스 아래의 네트워크에 표시된다. 이는 이러한 제안에서 Boolean flag ue Mobility Sensor 파라미터로 표시된다.
[00162] 또 다른 실시예에서, UE-Sensor-capability NB는 또한 예를 들어, 가속도계 또는 자이로스코프 또는 GPS 또는 임의의 이러한 센서와 같은 센서 유형을 포함할 수 있으며, 일 실시예에서 측정 보고들은 또한 이러한 센서들로부터의 판독값들을 포함할 수 있다. 이는 측정 보고들 자체를 통해 센서 데이터를 전송하는 데 도움이 된다. 그 후 네트워크는 사전 지식에 기초하여 또는 APN/목적지 주소 표시를 통해 데이터를 적절한 목적지 서버로 라우팅할 것이다. 이는 초기 전송 메커니즘을 달성하는 데 도움이 되며 센서 디바이스에 대한 데이터 경로를 제공한다. 네트워크는 측정 보고 주기성을 스케줄링할 수 있으므로 디바이스가 송신할 수 있는 정보의 양을 제한할 수 있다.
[00163] 또 다른 실시예에서 UE 능력은 또한 디바이스에 의해 지원되는 주파수들을 포함할 수 있다. 매우 특정한 주파수들(예를 들어, 대역 3 또는 대역 5 전용)을 지원하는 것은 측정 최적화에 도움이 되고 배터리 전원도 절약할 수 있다. 이는 또한 디바이스가 가능한 한 오랫동안 셀에 유지될 수 있을 때 네트워크가 핸드오버들을 최적화하는 데 도움이 될 수 있다.
[00164] 또 다른 실시예에서, UE(센서 디바이스)는 또한 비활성 타이머 및 상태들이 그에 따라 구성될 수 있도록 그 전송 패턴, 즉, 고정 패턴을 갖는 고정 바이트들에 대해 네트워크가 알 수 있도록 그 능력을 포함할 수 있다. 이는 UE가 비활성 상태 구성을 필요로 하는지 또는 마지막 패킷의 전송 후 트랜잭션을 완료할 수 있는지를 나타내는 Boolean flag - ue Inactive State Ind를 사용하여 달성될 수 있다.
[00165] 마지막 패킷을 나타내기 위해, RLC 헤더에 비트가 표시된다. 이러한 정보는 UE 능력 정보 요소에서 캡처될 수 있다. 모빌리티 센서 정보를 추가한 후의 예시적인 실시예로서, NB-IoT에 대한 UE 능력 정보는 아래에서 설명하는 바와 같이 다음과 같다.
[00166] 농업 센서들과 같은 추가 센서 유형들이 유사한 방식으로 구조에 추가될 수 있으며 제공된 예는 단지 하나의 예시적인 샘플이라는 것을 이해해야 한다.
[00167] 도 6은 본 개시의 실시예들에 따라 본 발명의 실시예들이 그 내부에서 이용될 수 있거나 또는 그와 함께 이용될 수 있는 예시적인 컴퓨터 시스템(600)을 예시한다. 도 6에 도시된 바와 같이, 컴퓨터 시스템(600)은 외부 저장 디바이스(610), 버스(620), 메인 메모리(630), 판독-전용 메모리(640), 대용량 저장 디바이스(650), 통신 포트(660) 및 프로세서(670)를 포함할 수 있다. 본 기술 분야의 통상의 기술자는 컴퓨터 시스템이 하나 초과의 프로세서(670) 및 통신 포트들(660)을 포함할 수 있음을 이해할 것이다. 프로세서(670)의 예들은 Intel® Itanium® 또는 Itanium 2 프로세서(들), 또는 AMD® Opteron® 또는 Athlon MP® 프로세서(들), Motorola® 프로세서들의 라인, FortiSOC™ 시스템 온 칩 프로세서들 또는 다른 미래의 프로세서들을 포함하지만 이에 한정되지 않는다. 프로세서(670)는 본 발명의 실시예들과 연관된 다양한 모듈들을 포함할 수 있다. 통신 포트(660)는 모뎀 기반 다이얼업(dialup) 연결과 함께 사용하기 위한 RS-232 포트, 10/100 이더넷(Ethernet) 포트, 구리 또는 섬유를 사용하는 기가비트(Gigabit) 또는 10 기가비트 포트, 직렬 포트, 병렬 포트 또는 다른 기존 또는 미래의 포트들 중 임의의 것일 수 있다. 통신 포트(660)는 근거리 네트워크(LAN: Local Area Network), 광역 네트워크(WAN: Wide Area Network) 또는 컴퓨터 시스템이 연결되는 임의의 네트워크들과 같은 네트워크에 따라 선택될 수 있다. 메모리(630)는 랜덤 액세스 메모리(RAM: Random Access Memory) 또는 본 기술 분야에 일반적으로 알려진 임의의 다른 동적 저장 디바이스일 수 있다. 판독-전용 메모리(640)는 예를 들어, 프로세서(670)에 대한 기동(start-up) 또는 BIOS 명령들과 같은 정적 정보를 저장하기 위한 예를 들어, 프로그래밍 가능한 판독-전용 메모리(PROM: Programmable Read Only Memory) 칩들과 같은 임의의 정적 저장 디바이스(들)일 수 있지만 이에 한정되지 않는다. 대용량 저장 디바이스(650)는 정보 및/또는 명령들을 저장하는 데 사용될 수 있는 임의의 현재 또는 미래의 대용량 저장 솔루션일 수 있다. 예시적인 대용량 저장 솔루션들은 병렬 고급 기술 결합(PATA: Parallel Advanced Technology Attachment) 또는 직렬 고급 기술 결합(SATA: Serial Advanced Technology Attachment) 하드 디스크 드라이브들 또는 솔리드-스테이트 드라이브들(내부 또는 외부, 예를 들어, 범용 직렬 버스(USB: Universal Serial Bus) 및/또는 파이어와이어(Firewire) 인터페이스들을 가짐), 예를 들어 Seagate로부터 이용 가능한 것(예를 들어, Seagate Barracuda 782 제품군) 또는 Hitachi로부터 이용 가능한 것(예를 들어, Hitachi Deskstar 13K800), 하나 이상의 광 디스크들, 독립 디스크들의 리던던트 어레이(RAID: Redundant Array of Independent Disks) 스토리지, 예를 들어, Dot Hill Systems Corp., LaCie, Nexsan Technologies, Inc. 및 Enhance Technology, Inc.를 포함하는 다양한 벤더들로부터 이용 가능한 디스크들의 어레이(예를 들어, SATA 어레이들)를 포함하지만 이에 한정되지 않는다.
[00168] 버스(620)는 프로세서(들)(670)를 다른 메모리, 저장 및 통신 블록들과 통신 가능하게 커플링한다. 버스(620)는 확장 카드들, 드라이브들 및 다른 하위 시스템들뿐만 아니라 프로세서(670)를 소프트웨어 시스템에 연결하는 전면 버스(FSB: front side bus)와 같은 다른 버스들을 연결하기 위한, 예를 들어, 주변 구성 요소 인터커넥트(PCI: Peripheral Component Interconnect)/PCI 확장(PCI-X) 버스, 소형 컴퓨터 시스템 인터페이스(SCSI: Small Computer System Interface), USB 등일 수 있다.
[00169] 선택적으로, 운영자 및 관리 인터페이스들, 예를 들어, 디스플레이, 키보드 및 커서 제어 디바이스는 또한 컴퓨터 시스템과의 직접적인 운영자 상호 작용을 지원하기 위해 버스(620)에 커플링될 수 있다. 다른 운영자 및 관리 인터페이스들이 통신 포트(660)를 통해 연결된 네트워크 연결들을 통해 제공될 수 있다. 외부 저장 디바이스(610)는 임의의 종류의 외부 하드-드라이브들, 플로피 드라이브들, IOMEGA® Zip Drive들, 컴팩트 디스크-판독-전용 메모리(CD-ROM: Compact Disc-Read Only Memory), 컴팩트 디스크-재기입 가능(CD-RW: Compact Disc-Re-Writable), 디지털 비디오 디스크-판독-전용 메모리(DVD-ROM: Digital Video Disk-Read Only Memory)일 수 있다. 위에서 설명한 구성 요소들은 다양한 가능성들을 예시하기 위한 것일 뿐이다. 앞서 언급한 예시적인 컴퓨터 시스템이 본 개시의 범위를 절대로 제한해서는 안 된다.
[00170] 본원에서는 바람직한 실시예들에 대해 상당한 강조가 이루어졌지만, 많은 실시예들이 이루어질 수 있고 본 발명의 원리를 벗어나지 않고도 바람직한 실시예들에서 많은 변경들이 이루어질 수 있음을 이해할 것이다. 본 발명의 바람직한 실시예들의 이러한 변경 및 다른 변경들은 본원의 개시로부터 본 기술 분야의 통상의 기술자에게 명백할 것이며, 이에 의해 상술한 설명 사항은 제한하는 것이 아니라 단지 본 발명을 예시하는 것으로 구현된다는 것을 분명히 이해할 것이다.
본 개시의 이점들
[00171] 본 개시는 IoT(Internet of Things) 네트워크에서 QoS(Quality of Service)의 효율적인, 레이턴시 감도 및 신뢰성 있는 최적화를 위한 시스템들 및 방법들을 제공한다.
[00172] 본 개시는 애플리케이션이 레이턴시 둔감인지, EDGE 및/또는 무선 액세스 노드들에서 캐싱 지원 및/또는 연합 프로세싱 능력들을 필요로 하는지 식별하는 데 도움이 될 새로운 QoS 프로파일을 위한 시스템들 및 방법들을 제공한다.
[00173] 본 개시는 특정 애플리케이션들에 대한 지능형 데이터 프로세싱을 수행할 수 있는 무선 액세스 네트워크의 추가 컴퓨트 엔티티들을 지원하기 위한 시스템들 및 방법들을 제공한다.
[00174] 본 개시는 새로운 QoS 클래스들을 적절하게 할당하기 위해 IOT 네트워크에 의해 사용될 IOT 애플리케이션 카테고리 또는 유형을 인식하는 시스템들 및 방법들을 제공한다.
[00175] 본 개시는 일부 애플리케이션 우선 순위들이 상대적이므로(예를 들어, 레이턴시 둔감 유형으로부터 레이턴시 민감 유형까지) 카테고리 유형들 사이의 우선 순위들을 변경하도록 시그널링하기 위한 시스템들 및 방법들을 제공한다.
[00176] 본 개시는 새로운 애플리케이션 카테고리들을 규정된 새로운 QoS 클래스 식별자들에 매핑할 수 있는 논-액세스 계층(NAS)에 대한 애플리케이션들 사이의 모뎀 인터페이스를 이용하는 시스템들 및 방법들을 제공한다.
[00177] 본 개시는 신뢰성, 레이턴시 민감도 측면에서 전체 최종 사용자 사례 속성들에 기초하여 IoT 애플리케이션들/데이터를 취급하기 위한 시스템들 및 방법들을 제공한다.
[00178] 본 개시는 데이터 스트림, 데이터 패킷 또는 캐싱을 필요로 하는 디바이스로부터 발생하는 임의의 데이터, 캐싱의 장소, 로컬 프로세싱을 필요로 하는 경우 프로세싱 상세 사항들의 특성과 같은 QoS 파라미터들을 수반하는 시스템들 및 방법들을 제공한다.
[00179] 본 개시는 확장된 QoS 템플릿의 QoS 메커니즘, 레이턴시 둔감 애플리케이션들을 위한 새로운 QoS 템플릿을 해석하고 적용하는 메커니즘을 위한 시스템들 및 방법들을 제공한다.

Claims (24)

  1. 사물 인터넷(IoT: Internet of Things) 네트워크에서 사용자 장비(UE: User Equipment)의 서비스 품질(QoS: Quality of Service) 프로파일에 기초하여 네트워크 자원들을 할당하기 위한 시스템으로서,
    프로세서;
    상기 프로세서에 커플링된 분석 엔진을 포함하고,
    상기 분석 엔진은,
    UE(User Equipment)로부터 요청을 수신하고 ― 상기 UE는 네트워크를 통해 상기 시스템과 통신하고, 상기 UE로부터 수신된 요청은 UE 파라미터들의 세트를 포함함 ―;
    상기 수신된 요청으로부터 상기 UE 파라미터들의 세트를 추출하고;
    상기 추출된 UE 파라미터들의 세트에 기초하여, QoS(Quality of Service) 프로파일을 상기 요청에 할당하고; 그리고
    상기 할당된 QoS 프로파일에 기초하여, 복수의 네트워크 자원들 중 적어도 하나를 상기 요청을 생성하는 상기 UE에 할당하는, 네트워크 자원들을 할당하기 위한 시스템.
  2. 제1 항에 있어서,
    상기 요청은 통신 모뎀을 통해 상기 UE로부터 수신되고, 상기 통신 모뎀은 상기 네트워크를 통해 상기 UE 및 상기 시스템에 통신 가능하게 커플링되는, 네트워크 자원들을 할당하기 위한 시스템.
  3. 제1 항에 있어서,
    상기 분석 엔진은 추가로, 상기 UE로부터 수신된 요청에 기초하여, 상기 네트워크를 통해, 상기 UE와의 프로토콜 데이터 유닛(PDU: Protocol Data Unit) 세션을 확립하는, 네트워크 자원들을 할당하기 위한 시스템.
  4. 제1 항에 있어서,
    상기 분석 엔진이 상기 추출된 UE 파라미터들의 세트에 기초하여 상기 QoS 프로파일을 상기 요청에 할당하는 것은, 사전 규정된 매핑 기준(pre-defined mapping criteria)에 기초하는, 네트워크 자원들을 할당하기 위한 시스템.
  5. 제1 항에 있어서,
    상기 분석 엔진은, 상기 추출된 UE 파라미터들의 세트에 기초하여, 상기 UE로부터의 상기 요청을 레이턴시 민감 요청(latency sensitive request) 및 레이턴시 둔감 요청(latency insensitive request) 중 하나로 카테고리화하는, 네트워크 자원들을 할당하기 위한 시스템.
  6. 제1 항에 있어서,
    상기 요청을 생성하는 상기 UE에 할당되는 상기 복수의 네트워크 자원들은 프로세싱 자원들의 할당, 메모리 자원들의 할당, 실행 우선순위 레벨(priority level of execution) 할당 또는 이들의 조합 중 하나를 포함하는, 네트워크 자원들을 할당하기 위한 시스템.
  7. 제6 항에 있어서,
    상기 분석 엔진은 상기 프로세싱 자원들을 상기 UE에 할당하기 위해, 상기 요청을 생성하는 상기 UE로 하여금 상기 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 프로세싱 자원들 중 하나를 이용하게 하는, 네트워크 자원들을 할당하기 위한 시스템.
  8. 제6 항에 있어서,
    상기 분석 엔진은 상기 메모리 자원들을 상기 UE에 할당하기 위해, 상기 요청을 생성하는 상기 UE로 하여금 상기 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 캐시 메모리들 중 하나를 이용하게 하는, 네트워크 자원들을 할당하기 위한 시스템.
  9. 제6 항에 있어서,
    상기 분석 엔진은 실행 우선순위 레벨을 상기 UE에 할당하기 위해, 특정 시간 기간 동안 상기 요청의 실행 지연을 야기하는, 네트워크 자원들을 할당하기 위한 시스템.
  10. 제1 항에 있어서,
    상기 UE 파라미터들의 세트는 센서 데이터, 애플리케이션 데이터 또는 이들의 조합 중 하나를 포함하는, 네트워크 자원들을 할당하기 위한 시스템.
  11. 제10 항에 있어서,
    상기 센서 데이터는 상기 UE와 통신하는 복수의 센서들 중 하나로부터 획득되는, 네트워크 자원들을 할당하기 위한 시스템.
  12. 제10 항에 있어서,
    상기 애플리케이션 데이터는 상기 UE 상에서 실행되는 애플리케이션으로부터 획득되는, 네트워크 자원들을 할당하기 위한 시스템.
  13. IoT(Internet of Things) 네트워크에서 UE(User Equipment)의 QoS(Quality of Service) 프로파일에 기초하여 네트워크 자원들을 할당하기 위한 방법으로서,
    분석 엔진에 의해, UE(User Equipment)로부터 요청을 수신하는 단계 ― 상기 UE는 네트워크를 통해 시스템과 통신하고, 상기 UE로부터 수신된 요청은 UE 파라미터들의 세트를 포함함 ―;
    상기 분석 엔진에 의해, 상기 수신된 요청으로부터 상기 UE 파라미터들의 세트를 추출하는 단계;
    상기 분석 엔진에 의해, 상기 추출된 UE 파라미터들의 세트에 기초하여, QoS(Quality of Service) 프로파일을 상기 요청에 할당하는 단계; 및
    상기 분석 엔진에 의해, 상기 할당된 QoS 프로파일에 기초하여, 복수의 네트워크 자원들 중 적어도 하나를 상기 요청을 생성하는 상기 UE에 할당하는 단계
    를 포함하는, 네트워크 자원들을 할당하기 위한 방법.
  14. 제13 항에 있어서,
    상기 분석 엔진에 의해, 상기 UE로부터 상기 요청을 수신하는 단계는 통신 모뎀을 통해 상기 요청을 수신하는 단계를 포함하고, 상기 통신 모뎀은 상기 네트워크를 통해 상기 UE 및 상기 시스템에 통신 가능하게 커플링되는, 네트워크 자원들을 할당하기 위한 방법.
  15. 제13 항에 있어서,
    상기 UE로부터 수신된 요청에 기초하여, 상기 네트워크를 통해, 상기 UE와의 PDU(Protocol Data Unit) 세션을 확립하는 단계를 더 포함하는, 네트워크 자원들을 할당하기 위한 방법.
  16. 제13 항에 있어서,
    상기 분석 엔진에 의해, 상기 추출된 UE 파라미터들의 세트에 기초하여, 상기 QoS 프로파일을 할당하는 단계는 사전 규정된 매핑 기준에 기초하는, 네트워크 자원들을 할당하기 위한 방법.
  17. 제13 항에 있어서,
    상기 추출된 UE 파라미터들의 세트에 기초하여, 상기 UE로부터의 상기 요청을 레이턴시 민감 요청 및 레이턴시 둔감 요청 중 하나로 카테고리화하는 단계를 더 포함하는, 네트워크 자원들을 할당하기 위한 방법.
  18. 제13 항에 있어서,
    상기 복수의 네트워크 자원들을 상기 요청을 생성하는 상기 UE에 할당하는 단계는 프로세싱 자원들을 할당하는 단계, 메모리 자원들을 할당하는 단계, 실행 우선순위 레벨을 할당하는 단계 또는 이들의 조합을 포함하는, 네트워크 자원들을 할당하기 위한 방법.
  19. 제18 항에 있어서,
    상기 분석 엔진에 의해, 상기 프로세싱 자원들을 상기 UE에 할당하는 단계는,
    상기 요청을 생성하는 상기 UE로 하여금 상기 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 프로세싱 자원들 중 하나를 이용하게 하는 단계를 포함하는, 네트워크 자원들을 할당하기 위한 방법.
  20. 제18 항에 있어서,
    상기 분석 엔진에 의해, 상기 메모리 자원들을 상기 UE에 할당하는 단계는, 상기 요청을 생성하는 상기 UE로 하여금 상기 네트워크의 복수의 엔티티들 중 하나의 엔티티의 복수의 캐시 메모리들 중 하나를 이용하게 하는 단계를 포함하는, 네트워크 자원들을 할당하기 위한 방법.
  21. 제18 항에 있어서,
    상기 분석 엔진에 의해, 실행 우선순위 레벨을 상기 UE에 할당하는 단계는 특정 시간 기간 동안 상기 요청의 실행 지연을 야기하는 단계를 포함하는, 네트워크 자원들을 할당하기 위한 방법.
  22. 제13 항에 있어서,
    상기 UE 파라미터들의 세트는 센서 데이터, 애플리케이션 데이터 또는 이들의 조합 중 하나를 포함하는, 네트워크 자원들을 할당하기 위한 방법.
  23. 제22 항에 있어서,
    상기 센서 데이터는 상기 UE와 통신하는 복수의 센서들 중 하나로부터 획득되는, 네트워크 자원들을 할당하기 위한 방법.
  24. 제22 항에 있어서,
    상기 애플리케이션 데이터는 상기 UE 상에서 실행되는 애플리케이션으로부터 획득되는, 네트워크 자원들을 할당하기 위한 방법.
KR1020237010280A 2021-08-31 2022-08-27 Iot(internet of things) 네트워크에서 qos(quality of service)를 최적화하기 위한 시스템들 및 방법들 KR20230131168A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IN202121039486 2021-08-31
IN202121039486 2021-08-31
PCT/IB2022/058037 WO2023031750A1 (en) 2021-08-31 2022-08-27 Systems and methods for optimizing quality of service (qos) in internet of things (iot) network

Publications (1)

Publication Number Publication Date
KR20230131168A true KR20230131168A (ko) 2023-09-12

Family

ID=85410895

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237010280A KR20230131168A (ko) 2021-08-31 2022-08-27 Iot(internet of things) 네트워크에서 qos(quality of service)를 최적화하기 위한 시스템들 및 방법들

Country Status (3)

Country Link
KR (1) KR20230131168A (ko)
CN (1) CN116368840A (ko)
WO (1) WO2023031750A1 (ko)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9730112B2 (en) * 2015-03-31 2017-08-08 Northrop Grumman Systems Corporation Identity based access and performance allocation

Also Published As

Publication number Publication date
CN116368840A (zh) 2023-06-30
WO2023031750A1 (en) 2023-03-09

Similar Documents

Publication Publication Date Title
EP3761560B1 (en) Control method for application programming interface (api) gateway cluster, and api gateway cluster
CN108353082B (zh) 用于处理虚拟网络驱动器的恶意活动的技术
KR101665897B1 (ko) 컴퓨팅 디바이스의 무선 재연결 시간을 감소시키기 위한 혼합식 오프 사이트/온 사이트 예측 계산
KR101682080B1 (ko) 컴퓨팅 디바이스의 무선 재연결 시간 감소
WO2017107018A1 (zh) 应用拓扑关系发现的方法、装置和系统
US20200112489A1 (en) Intelligent Network Equipment Failure Prediction System
CN111124819B (zh) 全链路监控的方法和装置
WO2017112365A1 (en) Managing communication congestion for internet of things devices
WO2017112366A1 (en) Managing communication congestion for internet of things devices
WO2016180182A1 (zh) 业务套餐的推荐方法和装置
KR20140051447A (ko) 통신 네트워크들에 대한 클라우드 컴퓨팅 강화 게이트웨이
CN111966289B (zh) 基于Kafka集群的分区优化方法和系统
US10178569B1 (en) Adaptive application behavior based on assessed network characteristics
CN107135088B (zh) 云计算系统中处理日志的方法和装置
US9641595B2 (en) System management apparatus, system management method, and storage medium
CN112564994A (zh) 流量监测方法、装置、云服务器及存储介质
KR102469441B1 (ko) 가상 게이트웨이 클러스터 전역 장애에 대한 모니터링 방법 및 장치
US20150296041A1 (en) Constraint based signal for intellegent and optimized end user mobile experience enhancement
KR20230131168A (ko) Iot(internet of things) 네트워크에서 qos(quality of service)를 최적화하기 위한 시스템들 및 방법들
US9559904B2 (en) Dynamic agent replacement within a cloud network
CN116260747A (zh) 终端测试设备的监测方法、装置及电子设备
TWI767427B (zh) 監控伺服器及其設備資源監控方法
EP3605964A1 (en) Method of controlling virtual network function, virtual network function management device, and virtual network providing system
JP7176295B2 (ja) 判定装置、ゲートウェイ、判定方法及び判定プログラム
US20230370959A1 (en) Systems and methods for retrieving ran information

Legal Events

Date Code Title Description
A201 Request for examination