KR20220128714A - Pfd 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치 - Google Patents

Pfd 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치 Download PDF

Info

Publication number
KR20220128714A
KR20220128714A KR1020210033158A KR20210033158A KR20220128714A KR 20220128714 A KR20220128714 A KR 20220128714A KR 1020210033158 A KR1020210033158 A KR 1020210033158A KR 20210033158 A KR20210033158 A KR 20210033158A KR 20220128714 A KR20220128714 A KR 20220128714A
Authority
KR
South Korea
Prior art keywords
filter
network entity
information
function
upf
Prior art date
Application number
KR1020210033158A
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 삼성전자주식회사
Priority to PCT/KR2021/003158 priority Critical patent/WO2022196837A1/ko
Priority to KR1020210033158A priority patent/KR20220128714A/ko
Publication of KR20220128714A publication Critical patent/KR20220128714A/ko
Priority to US18/368,418 priority patent/US20240031257A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/06—Generation of reports
    • H04L43/062—Generation of reports related to network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Liquid Crystal Substances (AREA)
  • Filtration Of Liquid (AREA)

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 본 개시는 5GC (5G core network)의 SMF 및 UPF 간 동작에 관한 것으로, PFD 관리 절차에 있어서, UPF에 양방향 PFD를 제공하는 방법에 관한 것이다. 이에 따르면, 상향링크에 대한 PFD 또는 하향링크에 대한 PFD 중 어느 하나만 UPF에 제공해도 됨에 따라 중복적인 정보의 송수신을 방지하고, SMF 및 UPF 간 송수신될 수 있는 메시지 크기의 제약 문제를 해결할 수 있다.

Description

PFD 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치{METHOD AND APPARATUS FOR PROVISIONING BI-DIRECTIONAL FILTER IN A PFD MANAGEMENT PROCEDURE}
본 개시는 차세대 이동 통신 시스템의 코어 네트워크(core network)에서 제어 평면(control plane)의 SMF(session management function) 및 사용자 평면(user plane)의 UPF(user plane function) 간 동작에 대한 것이다. 보다 구체적으로, 본 개시는 UPF가 어플리케이션 트래픽(application traffic)을 감지(detection)할 수 있도록, SMF가 어플리케이션의 트래픽을 감지하기 위한 필터를 UPF에 제공하는 방법에 대한 것이다.
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 기술 융합의 일 예라고 할 수 있을 것이다.
한편, 상술한 기술 발전에 발맞추어 통신 시스템의 코어 네트워크(core network)의 새로운 구조에 대해서도 논의가 진행되어 왔다. 기존 LTE 통신 시스템에서는 이동성 관리 기능 및 세션 관리 기능을 담당하는 MME(mobility management entity), 단말과 외부 PDN(packet data network) 간 패킷을 전달하는 기능과 데이터 사용량에 따른 과금(charging) 등 기능을 수행하는 P-GW(packet data network gateway), 및 기지국과 P-GW 사이에서 사용자 패킷들을 라우팅(routing) 하는 기능을 수행하는 S-GW(serving gateway) 등이 코어 네트워크인 EPC(evolved packet core)를 구성하였다. EPC를 구성하는 MME, P-GW, S-GW들은 제어 평면(control plane) 기능과 사용자 평면(user plane) 기능이 밀접하게 결합된 네트워크 엔티티(network entity)이므로, 유연한 네트워크 관리가 어려웠다. 한편, 3GPP의 릴리즈 14 표준에서, SDN(software defined network) 기술을 이용하여, EPC의 P-GW와 S-GW의 제어 평면과 사용자 평면을 분리하는 CUPS(control and user plane separation)의 구조가 도입되었다. 이후, 4G 통신 시스템에서 5G 통신 시스템으로 발전하면서, 5G 통신 시스템의 요구조건(requirement)를 충족하기 위해 상술한 CUPS 구조가 5G 코어 네트워크(5GC)의 구조 설계의 핵심 요소 중 하나로 적용되었고, 그 결과 5G 코어 네트워크에서는 제어 평면과 사용자 평면 간 완전한 분리가 이루어졌다. 구체적으로, 제어 평면의 측면에서, EPC MME의 인증, 접속 제어, 이동성 제어 기능이 5GC AMF(access and mobility management function)에 의해 수행되고, EPC MME의 세션 관리 기능이 5GC SMF(session management function)에 의해 수행되며, 사용자 평면의 측면에서 EPC GW의 패킷 프로세싱 등이 5GC UPF(user plane function)에 의해 수행되는 구조로 제어 평면과 사용자 평면 간 완전한 분리가 이루어졌다. 이에, 제어 평면을 처리하는 AMF, SMF와 사용자 평면을 처리하는 UPF들의 기능 및 구현 복잡도와 네트워크 엔티티 간 시그널링 부하를 감소시킬 수 있는 방법에 대한 다양한 논의가 진행되고 있다.
상술한 5GC에서는, 제어 평면의 SMF는 사용자 평면의 UPF가 어플리케이션의 트래픽(application traffic)을 감지할 수 있도록 복수의 필터들을 UPF에 제공할 수 있다. 5G 통신 시스템에서는 서비스될 수 있는 어플리케이션의 수가 기존의 LTE 통신 시스템과 비교하여 크게 증가하였고, 상기 어플리케이션의 트래픽 종류 또한 다양해짐에 따라, 하나의 어플리케이션을 감지하기 위해 정의해야 할 필터의 개수 또한 크게 증가하였다. 그러나, SMF와 UPF 간 인터페이스를 통해 송수신될 수 있는 메시지의 길이(length)는 제한되어 있어, 하나의 메시지를 통해 UPF에 전달될 수 있는 필터의 개수는 한정적이다. 만약, UPF가 다양하고, 충분한 수의 필터를 제공받지 못한 경우, 어플리케이션의 트래픽이 제대로 감지되지 않을 수 있으며, 이에 따라 비정상적인 네트워크 상황이 초래될 수 있다.
따라서, 본 개시를 통해 SMF가 어플리케이션의 트래픽을 감지하는데 사용되는 필터를 UPF에 제공함에 있어, 상술한 문제점을 해결하기 위한 방법을 제안하고자 한다.
상술한 문제점을 해결하기 위해, 본 개시의 일 실시 예에 따르면, 통신 시스템에서 SMF(session management function)을 수행하는 제1 네트워크 엔티티(network entity)의 방법이 제공된다. 상기 방법은, 어플리케이션과 연관된 제1 방향에 대한 제1 필터 및 제2 방향에 대한 제2 필터를 획득하는 단계; 상기 제1 필터 및 상기 제2 필터를 비교한 결과에 기반하여, 상기 제1 필터가 양방향 필터인지 여부를 확인하는 단계; 상기 제1 필터가 상기 양방향 필터인 경우, UPF(user plane function)을 수행하는 제2 네트워크 엔티티가 상기 제1 필터에 기반하여 상기 제2 필터를 획득하는 기능을 지원하는지 확인하는 단계; 및 상기 제2 네트워크 엔티티가 상기 기능을 지원하는 경우, 상기 제1 필터 및 상기 제1 필터가 상기 양방향 필터라는 것을 지시하는 정보를 포함하는 메시지를 상기 제2 네트워크 엔티티에 전송하는 단계를 포함하는 것을 특징으로 한다.
또한, 본 개시의 일 실시 예에 따르면, 통신 시스템에서 UPF(user plane function)을 수행하는 제2 네트워크 엔티티의 방법이 제공된다. 상기 방법은, SMF(session management function)을 수행하는 제1 네트워크 엔티티로부터, 어플리케이션과 연관된 제1 방향에 대한 제1 필터를 포함하는 메시지를 수신하는 단계; 상기 메시지에 상기 제1 필터가 양방향 필터라는 것을 지시하는 정보가 포함되어 있는 경우, 상기 제1 필터의 정보에 기반하여 제2 방향에 대한 제2 필터를 확인하는 단계; 및 상기 제1 필터 및 상기 제2 필터에 기반하여, 상기 어플리케이션의 트래픽(traffic)을 감지(detect)하는 단계를 포함하는 것을 특징으로 한다.
또한, 본 개시의 일 실시 예에 따르면, 통신 시스템의 SMF을 수행하는 제1 네트워크 엔티티가 제공된다. 상기 제1 네트워크 엔티티는, 송수신부; 및 어플리케이션과 연관된 제1 방향에 대한 제1 필터 및 제2 방향에 대한 제2 필터를 획득하고, 상기 제1 필터 및 상기 제2 필터를 비교한 결과에 기반하여, 상기 제1 필터가 양방향 필터인지 여부를 확인하고, 상기 제1 필터가 상기 양방향 필터인 경우, UPF(user plane function)을 수행하는 제2 네트워크 엔티티가 상기 제1 필터에 기반하여 상기 제2 필터를 획득하는 기능을 지원하는지 확인하며, 상기 제2 네트워크 엔티티가 상기 기능을 지원하는 경우, 상기 제1 필터 및 상기 제1 필터가 상기 양방향 필터라는 것을 지시하는 정보를 포함하는 메시지를 상기 제2 네트워크 엔티티에 전송하도록 상기 송수신부를 제어하는 제어부를 포함하는 것을 특징으로 한다.
또한, 본 개시의 일 실시 예에 따르면, 통신 시스템의 UPF을 수행하는 제2 네트워크 엔티티가 제공된다. 상기 제2 네트워크 엔티티는, 송수신부; 및 SMF(session management function)을 수행하는 제1 네트워크 엔티티로부터, 어플리케이션과 연관된 제1 방향에 대한 제1 필터를 포함하는 메시지를 수신하도록 상기 송수신부를 제어하고, 상기 메시지에 상기 제1 필터가 양방향 필터라는 것을 지시하는 정보가 포함되어 있는 경우, 상기 제1 필터의 정보에 기반하여 제2 방향에 대한 제2 필터를 확인하고, 상기 제1 필터 및 상기 제2 필터에 기반하여, 상기 어플리케이션의 트래픽(traffic)을 감지(detect)하는 제어부를 포함하는 것을 특징으로 한다.
본 개시에 따르면, SMF가 UPF에 어플리케이션의 트래픽을 감지하는데 사용되는 필터를 효율적으로 제공할 수 있는 방법이 제공된다.
본 개시의 일 실시 예에 따르면, SMF가 PFD(packet flow description) 관리 절차를 통해 어플리케이션의 트래픽을 감지하기 위한 복수의 필터들을 각각 포함하는 복수의 PFD들을 UPF에 전달하는 방법에 있어서, 필터가 양방향(예를 들어, 상향링크 방향 및 하향링크 방향)에 모두 적용될 수 있는 경우, 어느 하나의 방향에 대한 필터를 포함하는 PFD만 전달하는 방법이 제공된다. 상술한 방법에 따르면, UPF는 수신된 PFD에 포함된 어느 하나의 방향에 대한 필터로부터 다른 방향에 대한 필터를 도출할 수 있게 됨으로써, 중복적인 정보의 송수신을 방지할 수 있다. 또한, 망 운용자는 하나의 어플리케이션에 대해 보다 많은 개수의 필터들을 설정하고, 이를 UPF에 제공할 수 있게 됨에 따라 보다 효율적인 시스템이 구현될 수 있다.
본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 개시의 상기 및 다른 목적, 특징 및 이점은 첨부된 도면을 참조하여 본 개시의 실시 예들에 대한 다음의 설명을 통해 보다 명확해질 것이다.
도 1은 본 개시의 일 실시 예에 따른 5GC의 구조를 도시한 도면이다.
도 2a는 본 개시의 일 실시 예에 따른 SMF와 PFDF(packet flow detection function) 간 인터페이스를 도시한 도면이다.
도 2b는 본 개시의 일 실시 예에 따른 SMF가 PFDF로부터 PFD를 획득하는 과정을 도시한 도면이다.
도 3은 본 개시의 일 실시 예에 따른 PFD 관리 절차를 도시한 도면이다.
도 4는 본 개시의 일 실시 예에 따른 SMF 및 UPF 간 Association 절차를 도시한 도면이다.
도 5는 본 개시의 일 실시 예에 따른 SMF의 동작을 도시한 도면이다.
도 6은 본 개시의 일 실시 예에 따른 SMF가 UPF에 어플리케이션의 트래픽을 감지하기 위한 필터를 포함하는 PFD를 제공하는 과정을 도시한 도면이다.
도 7은 본 개시의 일 실시 예에 따른 UPF의 동작을 도시한 도면이다.
도 8은 본 개시의 일 실시 예에 따른 UPF가 SMF로부터 어플리케이션의 트래픽을 감지하기 위한 필터를 포함하는 PFD를 제공받고, 필터에 기반하여 어플리케이션 트래픽 감지 동작을 수행하는 과정을 도시한 도면이다.
도 9는 본 개시의 일 실시 예에 따른 SMF가 양방향 필터를 포함하는 PFD을 UPF에 제공하는 PFD 관리 절차의 전반적인 흐름을 도시한 도면이다.
도 10은 본 개시의 일 실시 예에 따른 SMF를 수행할 수 있는 네트워크 엔티티의 구조를 도시한 도면이다.
도 11은 본 개시의 일 실시 예에 따른 UPF를 수행할 수 있는 네트워크 엔티티의 구조를 도시한 도면이다.
이하, 첨부된 도면을 참조하여 실시 예를 상세하게 설명한다.
실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부된 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성 요소에는 동일한 참조 번호를 부여하였다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
이때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 실시 예에서 '~부'는 하나 이상의 프로세서를 포함할 수 있다.
또한, 본 개시의 일 실시 예에서 명백하게 다른 내용을 지시하지 않는 “한”과, “상기”와 같은 단수 표현들은 복수 표현들을 포함한다는 것이 이해될 수 있을 것이다.
또한, 본 개시의 일 실시 예에서 제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성 요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 개시의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다.
또한, 본 개시의 일 실시 예에서 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
또한, 본 개시의 일 실시 예에서 사용되는 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 본 개시를 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, “포함하다” 또는 “가지다” 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
또한, 본 개시의 일 실시 예에서 사용되는 용어 “~와 연관되는(associated with)” 및 “~와 연관되는(associated therewith)”과 그 파생어들은 포함하고(include), ~내에 포함되고(be included within), ~와 서로 연결되고(interconnect with), 포함하고(contain), ~내에 포함되고(be contained within), ~에 연결하거나 혹은 ~와 연결하고(connect to or with), ~에 연결하거나 혹은 ~와 연결하고(couple to or with), ~와 통신 가능하고(be communicated with), ~와 협조하고(cooperate with), 인터리빙하고(interleave), 병치하고(juxtapose), ~로 가장 근접하고(be proximate to), ~로 할 가능성이 크거나 혹은 ~와 ~할 가능성이 크고(be bound to or with), 가지고(have), 소유하고(have a property of) 등과 같은 것을 의미할 수 있다.
또한, 본 개시에서 '이상'으로 기재된 조건은 '초과', '이하'로 기재된 조건은 '미만', '이상 및 미만'으로 기재된 조건은 '초과 및 이하'로 대체될 수 있다.
본 개시에 대한 자세한 설명에 앞서, 본 명세서에서 사용되는 몇 가지 용어들에 대해 해석 가능한 의미의 예를 제시하였다. 하지만, 상기에서 제시하는 해석 예로 한정되는 것은 아님을 주의하여야 한다.
이하, 본 개시에서 제안하는 양방향(Bi-directional) 필터를 제공하는 방법, 이를 수행할 수 있는 장치에 대해 구체적으로 설명하기로 한다.
도 1은 본 개시의 일 실시 예에 따른 5GC의 구조를 도시한 도면이다.
도 1을 참조하면,　5GC는 5G 무선 접속망(next generation-radio access network, RAN)과 외부 패킷 데이터 망(packet data network) 사이에서 사용자에게 음성을 비롯한 다양한 형태의 서비스를 제공할 수 있다. 이동 통신 표준을 담당하는 3GPP에서는 5GC에 네트워크 기능 가상화(network function virtualization, NFV) 기술과 SDN(software defined networking)을 고려하여 다양한 NF(network function)을 정의하고, NF들로 5GC를 구성하도록 하는 구조를 도입하였다. 이에 따르면, 기존 4G 통신 시스템의 EPC와 다르게 기능들을 보다 유연하게 소프트웨어적으로 구현할 수 있으며, 장비 유지 및 보수 등에 따른 비용 또한 절감할 수 있다는 장점이 있다. 한편, 본 개시가 적용될 수 있는 5GC를 구성하는 NF들은 하기와 같이 예로 들 수 있다.
AMF(access and mobility management function), SMF(session management function), UPF(user plane function), PCF(policy control function), AUSF(authentication server function), UDM(unified data management function), AF(application function), NEF(network exposure function), NRF(network repository function), NSSF(network slice selection function)
상기 예로 든 NF들 중 RAN과 기능적으로 연결되어 데이터를 전송하거나 제어하는 NF는 AMF, SMF, 및 UPF이다. AMF, SMF는 제어 평면(control plane)을 처리하고, UPF는 사용자 평면(user plane)을 처리할 수 있다. 이하, SMF 및 UPF에 대해 보다 구체적으로 설명하기로 한다.
SMF는 제어 평면을 처리하는 NF로서, SMF는 단말과 외부 데이터 망간 연결 제공을 위해 단말에게　IP 주소를 할당하고 이때　UPF　또는 외부 데이터 네트워크로부터　IP　주소를 받아서 단말에 제공할 수도 있다.　SMF는 기지국과　UPF 간　NG-U 인터페이스에서　GTP　터널링(tunnelling)을 이용하여　PDU　세션 터널을 생성하고, 단말과 데이터 망 간　PDU(protocol data unit) 세션에 대한 생성 변경 해제 기능을 수행할 수 있다.　또한, SMF는 단말이 사용할　UPF를 선택하고,　UPF가 패킷들을 목적지에 전달할 수 있도록　UPF의 라우팅(routing)을 설정하며　QoS　제어를 위한 사업자 정책 수신을 위해　PCF(policy　control　function)와 인터페이스를 통해 시그널링을 송수신할 수 있다. 또한,　SMF는　UPF의 과금　데이터 수집을 위한 제어 기능을 제공하고,　UPF로부터의 과금 데이터 수집 그리고 과금 데이터를 과금 서버로 전달하기 위한 인터페이스를 지원한다. 또한, SMF는 하향 링크로의 패킷 데이터가 수신되었다는　UPF의 알림에 의한 하향 링크 데이터 알림(downlink　data　notification) 수행 및 단말 이동에 따라 세션과 서비스의 연속성을 어떻게 제공할지를 결정할 수 있으며, 세션 관리 이벤트에 대한 합법적 감청(Lawful　Interception)도 지원할 수 있다.　SMF도　AMF와 같이 5G의 서비스 기반 구조 도입에 따라　SBI(Service　Based　Interface)인　Nsmf를 인증된 다른　NF(Network　Function)들에 제공하여　SMF　Service를 활용할 수 있게 한다. SMF는 N11 인터페이스를 통해 AMF와 시그널링을 주고 받을 수 있으며, UPF와는 N4 인터페이스를 통해 시그널링을 주고 받을 수 있다.
한편, UPF는 사용자 평면을 처리하는 NF로서, 단말로부터 수신한 패킷을 데이터 네트워크로 전달하거나 데이터 네트워크로부터 수신한 패킷을 단말로 전달하기 위해 사용자 단위로 패킷을 필터링할 수 있다.　UPF는 단말이 5G 시스템 내 또는 다른 시스템으로 이동하는 경우 이동성 앵커 포인트(Mobility　Anchor　Point) 역할을 한다.　'End　Marker'를 원래의 기지국으로 전달하여 더 이상 해당 경로(path)로는 패킷이 수신되지 않는다는 것을 알린다.　UPF는　SMF의 요청으로 단말　IP 주소를 할당할 수도 있다.　UPF는　SMF로부터 제공받은 SDF(Service　Data　Flow)　Template 또는 PFD(packet flow description)　기반으로　Packet　Inspection　기능을 제공하여　Application　트래픽 감지 기능을 수행할 수 있다. 또한, UPF는　Policy에 따른 트래픽 차단(gating),　Redirection　또는　Steering을 수행하며 사용자 패킷 수집을 통한 합법적 감청(Lawful　Intercept, LI) 기능을 제공할 수 있다. UPF는　QoS　제공을 위해 상향 링크(uplink)와 하향 링크(downlink)에 대한　전송 속도　제어와　DSCP(Differentiated　Services　Code　Point)와 같은 패킷 마킹(Packet　Marking)과　Reflective　QoS　제공을 위한 하향 링크 패킷에 대한　Packet　Marking도 제공할 수 있다.　또한, UPF는　유휴(idle)　상태의 단말로 전달해야 할 패킷을 수신하면　SMF를 통해　AMF가 단말 착신을 위한 페이징(paging)을 동작하게 할 수 있다. 페이징 이후 단말이 네트워크에 접속하게 되면　UPF는 저장된 패킷을 단말에게 전송할 있다.　또한 UPF는　SMF의 제어를 받아 과금 정보를 수집하는 기능도 수행할 수 있다. UPF는 N3 인터페이스를 통해 RAN과 시그널링을 송수신할 수 있고, N6 인터페이스를 통해 DN(data network) 와 시그널링을 주고 받을 수 있으며, N4 인터페이스를 통해 SMF와 시그널링을 송수신할 수 있다.
한편, 상술한 5GC에서, 어플리케이션의 트래픽을 감지(detect)하기 위해 UPF 필터를 제공하는 방법은 크게 두 가지가 존재한다.
첫 번째 방법은, IP-CAN(IP-connectivity access network) 세션 또는 PDU(protocol data unit) 세션 생성 시 마다 UPF에 어플리케이션의 트래픽을 감지하는 동작과 관련된 규칙(예를 들어, PDR(packet detection rule)을 지칭할 수 있다.)과 함께 필터를 제공하는 방법이다. 각각의 필터는 어플리케이션의 필터로 사용될 수 있는 패킷 필터(packet filter), Flow description 등과 같은 정보(또는, AVP(attribute value-pair))을 의미할 수 있다. UPF는 제공된 필터에 기반하여, 어플리케이션의 트래픽을 감지하는 동작을 수행할 수 있다.
두 번째 방법은, UPF에 어플리케이션에 대한 복수의 필터 및 해당 어플리케이션을 지시하는 어플리케이션 식별자(ID(identifier))를 UPF에 먼저 제공하고, IP CAN 세션 또는 PDU 세션 생성 시 트래픽을 감지 하기를 원하는 어플리케이션 ID만 전달하는 방법이다. UPF는 기 제공된 복수의 필터들 중 수신된 어플리케이션 ID에 대응하는 필터들 확인하고, 이들에 기반하여 해당 어플리케이션의 트래픽을 감지하는 동작을 수행할 수 있다. 본 개시에서 두 번째 방법에 따라 UPF에 제공되는 필터는 PFD에 포함되어, PFD 관리 절차의 PFD 관리 요청 메시지를 통해 전달될 수 있다. 한편, 본 개시에서 PFD는 후술하는 바와 같이 PFD contents라고 지칭될 수 있으며, 이에 국한되지 않고, 동일 또는 유사한 의미를 가지는 용어에 의해 지칭될 수도 있다.
한편, 첫 번째 방법은 Session 생성 또는 신규 서비스가 추가될 때 마다 규칙과 함께 복수의 필터들이 UPF에 전달되어야 하므로, 이들을 전달하기 위해 요구되는 메시지의 길이가 커지고, 빈번한 메시지 송수신에 의한 시그널링 오버헤드가 발생할 수도 있다.
이와 달리, 두 번째 방법에 따르면, SMF와 UPF가 Session 생성 또는 신규 서비스가 추가되는 경우, 어플리케이션 ID만 주고받으면 되므로, SMF 및 UPF 간 송수신되는 메시지의 크기를 감소시킬 수 있어 망의 부하를 낮출 수 있는 효과를 얻을 수 있다. 이하, 본 개시에서는 SMF가 상술한 두 번째 방법에 기반하여, 어플리케이션의 트래픽을 감지하는데 사용되는 복수의 필터들을UPF에 제공하는 방법에 대해 설명하기로 한다. 한편, 본 개시가 이에 국한되는 것은 아니며, 상기 첫 번째 방법에도 본 개시가 적용될 수 있음은 통상의 기술자 입장에서 당연하다.
상술한 두 번째 방법에서, SMF가 UPF에 어플리케이션 ID와 해당 어플리케이션의 트래픽을 감지하기 위해 사용되는 복수의 필터들을 각각 포함하는 복수의 PFD들을 제공하는 일련의 과정을 PFD 관리(PFD management)라고 지칭할 수 있다. 이하, PFD 관리에 대해 구체적으로 설명하기로 한다.
한편, 본 개시에 따른 SMF는 상술한 PFD 관리 절차를 통해 UPF에 복수의 PFD들을 제공하기 전 NEF(network exposure function)로부터 상기 PFD들을 획득할 수 있다. SMF가 NEF로부터 PFD들을 획득하는 과정은 도 2a 및 도 2b를 참조하여 설명하기로 한다.
도 2a는 본 개시의 일 실시 예에 따른 SMF와 PFDF(packet flow detection function) 간 인터페이스를 도시한 도면이다.
도 2a를 참조하면, SMF와 PFDF는 N29 인터페이스를 통해 시그널링을 송수신할 수 있다. 본 개시에서 PFDF는 SMF의 요청 따라 적어도 하나의 어플리케이션에 대한 PFD들을 SMF에 제공할 수 있으며, SMF는 상기 PFD들을 PFD 관리 절차를 통해 UPF에 제공할 수 있다. 또한, SMF는 특정 어플리케이션 ID와 연관된 PFD들에 대한 변경이 있는 경우, 알림을 받을 수 있도록 PFDF를 subscribe하거나, 더 이상 알림을 받지 않도록 PFDF를 unsubscribe 할 수 있다. 이하, 도 2b를 참조하여, SMF가 PFDF로부터 어플리케이션에 대한 PFD를 획득하는 과정에 대해 구체적으로 설명하기로 한다.
도 2b는 본 개시의 일 실시 예에 따른 SMF가 PFDF로부터 PFD를 획득하는 과정을 도시한 도면이다.
Step 1에서, NF service consumer인 SMF는 적어도 하나의 어플리케이션 ID에 대한 PFD를 요청하는 메시지(예를 들어, GET request)를 전송할 수 있다.
Step 2에서, 상기 PFD 요청이 성공한 경우, SMF는 PFDF로부터 요청한 어플리케이션 ID에 대한 복수의 PFD들을 포함하는 PFD 응답을 수신할 수 있다. 한편, PFD 응답에는 Step 1의 PFD 요청이 성공하였음을 나타내는 정보가 더 포함될 수 있다. 또는, PFD 요청이 실패한 경우, SMF는 PFDF로부터 Step 1의 PFD 요청이 실패하였음을 나타내는 HTTP 상태 코드를 수신할 수도 있다.
상술한 PFDF와의 시그널링을 통해, SMF는 어플리케이션에 대한 PFD를 획득할 수 있으며, 이를 PFD 관리 절차를 통해 UPF에 제공할 수 있다.
한편, 도 2a 및 도 2b에서 SMF가 PFDF로부터 PFD를 획득하는 동작은 수행되지 않을 수도 있다. 또 다른 실시예에 따르면, SMF에 어플리케이션에 대한 복수의 필터들이 미리 설정(pre-configured)되어 있을 수도 있으며, 이러한 경우, SMF는 미리 설정된 복수의 필터들을 각각 포함하는 복수의 PFD들을 PFD 관리 절차를 통해 UPF에 제공할 수 있다. 예를 들어, SMF에 상향링크에 대한 필터가 미리 설정된 경우, SMF는 상기 필터를 포함하는 PFD를 생성(또는, 획득) 할 수 있고, 이를 PFD 관리 절차를 통해 UPF에 제공할 수 있다. 한편, 본 개시에서, PFD를 생성(또는, 획득)하는 동작은 후술하는 PFD contents의 포맷(format)(예를 들어, 표 2 또는 표 9)에 따라 필터를 포함하는 PFD를 확인하는 동작을 의미할 수 있다. 이하, 본 개시에서는 SMF가 미리 설정된 PFD들을 UPF에 제공하는 실시 예를 중심으로 설명하기로 한다.
도 3을 참조하여 SMF가 PFD 관리 절차를 통해 UPF에 어플리케이션 트래픽을 감지하기 위한 필터를 포함하는 PFD을 제공하는 방법에 대해 구체적으로 설명하기로 한다.
도 3은 본 개시의 일 실시 예에 따른 PFD 관리 절차를 도시한 도면이다.
본 개시에서 PFD 관리 절차는 제어 평면인 SMF가 적어도 하나의 어플리케이션 ID에 대해 미리 설정된 복수의 필터들을 포함하는 PFD들을 사용자 평면인 UPF에 제공하거나, 이들을 제거하도록 UPF에 요청하는 절차를 의미할 수 있다.
Step 1에서, SMF는 적어도 하나의 어플리케이션에 대한 PFD들을 UPF에 프로비저닝(provisioning)하거나, 또는 UPF가 적어도 하나의 어플리케이션에 대한 PFD들을 제거할 수 있도록 PFD 관리 절차를 트리거(또는, 개시) 할지 여부를 결정할 수 있다. 예를 들어, SMF가 PFDF로부터 새로운 PFD들을 제공받았거나, UPF에 기 제공된 PFD가 더 이상 유효한 PFD가 아니라고 판단되는 경우, SMF는 PFD 관리 절차를 트리거할 수 있다.
Step 2에서, SMF가 PFD 관리 절차를 트리거 한 경우, SMF는 UPF에 PFD 관리 요청 메시지를 전송할 수 있다. 여기에서, 상기 PFD 관리 요청 메시지는 어플리케이션 ID 및 어플리케이션 ID와 대응하는 어플리케이션에 대한 복수의 필터들을 포함하는 PFD들로 구성될 수 있다. 또는, UPF에 기 제공된 PFD가 더 이상 유효한 PFD가 아니라고 판단되는 경우, SMF는 상기 PFD 관리 요청 메시지에 어플리케이션 ID 또는 PFD들에 대한 정보를 비우고 전송할 수 있다. 한편, SMF로부터 PFD 관리 요청 메시지를 수신한 UPF는, 만약 PFD 관리 요청 메시지에 어플리케이션 ID 또는 PFD들에 대한 정보가 존재(present)하지 않는 경우, 이전의 PFD 관리 절차를 통해 제공된 모든 어플리케이션에 대한 모든 PFD들을 삭제할 수 있다. 또는, 만약 PFD 관리 요청 메시지에 적어도 하나의 PFD에 대한 정보가 존재하는 경우, 해당 어플리케이션에 대해 기 제공된 모든 PFD들을 삭제하고, 상기 PFD 요청 메시지에서 수신한 모든 PFD들을 저장할 수 있다.
이후, Step 3에서, UPF는 상술한 PFD 관리 요청 메시지에 따른 동작을 성공적으로 수행한 경우, SMF에 PFD 관리가 성공임을 나타내는 정보(예를 들어, cause "success")를 포함한 PFD 관리 응답 메시지를 전송할 수 있다.
한편, 상술한 PFD 관리 절차에서, PFD 관리 요청 메시지는 어플리케이션 별로 UPF에 전송될 수 있다. 즉, 하나의 어플리케이션 ID 마다 하나의 PFD 관리 요청 메시지가 전송될 수 있다. 구체적으로, 예를 들어 본 개시의 PFD 관리 요청 메시지는 하기 [표 1]과 같은 포맷의 정보를 포함할 수 있다.
Octet 1 and 2 Application ID's PFDs IE Type = 58 (decimal)
Octets 3 and 4 Length = n
Information elements P Condition / Comment Appl. IE Type
Sxa Sxb Sxc N4
Application ID M 이 IE는 UPF (UP function)에 제공될 어플리케이션 ID를 식별 해야 한다(This IE shall identify the Application ID for which PFDs shall be provisioned in the UP function). - X X X Application ID
PFD context C 이 IE는 PFD가 UPF에 제공되어야 하는 경우 존재한다(This IE shall be present if the PFD needs to be provisioned in the UP function.).
존재하는 경우, UPF에 제공될 될 PFD를 설명해야 한다(When present, it shall describe the PFD to be provisioned in the UP function.).
이 어플리케이션 ID에 대해 복수의 PFD들을 제공하기 위해 동일한 IE 타입을 가진 여러 IE가 있을 수 있다(Several IEs with the same IE type may be present to provision multiple PFDs for this Application ID.).

이 IE가 없으면 UPF는 이 어플리케이션 ID에 대해 이전에 수신되고 저장된 모든 PFD들을 삭제한다(When this IE is absent, the UP function shall delete all the PFDs received and stored earlier in the UP function for this Application ID.).		 - X X X PFD context
표 1에 따르면, PFD 관리 요청 메시지에는 UPF에 제공될 PFD들과 연관된 어플리케이션 ID 및 PFD context가 포함될 수 있다. 여기에서, PFD context는 상기 어플리케이션 ID에 대응하는 어플리케이션에 대한 복수의 PFD들(PFD 집합)을 의미할 수 있다. 한편, PFD context는 포함되지 않을 수도 있으며, 이러한 경우, UPF는 이전의 PFD 관리 절차를 통해 제공된 해당 어플리케이션 ID에 대한 모든 PFD를 삭제할 수 있다. 즉, 어플리케이션 ID만 포함되어 있고, 상기 어플리케이션 ID에 대한 PFD들의 PFD context는 포함되어 있지 않은 경우, 단말은 해당 어플리케이션 ID에 대해 기 제공된 모든 PFD들을 삭제할 수 있다.
본 개시의 일 실시 예에 따르면, 표 1의 PFD context은 하기 표 2과 같은 PFD contents를 포함할 수 있으며, 여기에서 PFD contents는 하나의 PFD에 포함될 수 있는 정보를 의미할 수 있다. 한편, 본 개시에서 PFD를 제공한다는 것은 PFD contents를 제공한다는 것을 의미할 수도 있으며, PFD contents의 정보(또는, 속성(property)) 들이 해당 어플리케이션의 트래픽을 감지하는데 사용될 수 있다. 예를 들어, UPF는 PFD contents의 정보들과 어플리케이션의 트래픽이 매칭하는지 여부에 기반하여, 트래픽 감지 동작을 수행할 수 있다. 즉, UPF는 인커밍 트래픽(incoming traffic)이 PFD contents의 모든 속성(property), 적어도 하나의 속성, 또는 어느 하나의 속성과 매칭하는지 여부에 기반하여 상기 인커밍 트래픽이 감지되는지 여부를 확인할 수 있다. 한편, PFD contents의 정보는 예를 들어, 하기 표 3과 같은 포맷을 가질 수 있다.
Octet 1 and 2 PFD context IE Type = 59 (decimal)
Octets 3 and 4 Length = n
Information elements P Condition / Comment Appl. IE Type
Sxa Sxb Sxc N4
PFD Contents M 이 IE는 UPF에 제공될 PFD를 설명한다(This IE shall describe the PFD to be provisioned in the UP function.). 이 PFD에 대해 복수의 contents를 제공하기 위해 동일한 IE 유형을 가진 여러 IE가 존재할 수 있다(Several IEs with the same IE type may be present to provision multiple contents for this PFD). (NOTE 1) - X X X PFD Contents
NOTE 1 CP function(예를 들어, 본 개시의 SMF)는 UPF가 PFDE 기능을 지원하는 경우, 여러 값이 있는 속성을 포함하는 PFD contents만 제공해야 한다(The CP function shall only provision a PFD Contents including a property with multiple values if the UP function supports PFDE feature.).
Bits
Octets 8 7 6 5 4 3 2 1
1 to 2 Type = 61 (decimal)
3 to 4 Length = n
5 ADNP AURL AFD DNP CP DN URL FD
6 Spare
m to (m+1) Length of Flow Description
(m+2) to p Flow Description
q to (q+1) Length of URL
(q+2) to r URL
s to (s+1) Length of Domain Name
(s+2) to t Domain Name
u to (u+1) Length of Custom PFD Content
(u+2) to v Custom PFD Content
w to (w+1) Length of Domain Name Protocol
(w+2) to x Domain Name Protocol
y to (y+1) Length of Additional Flow Description
(y+2) to z Additional Flow Description
a to (a+1) Length of Additional URL
(a+2) to b Additional URL
c to (c+1) Length of Additional Domain Name and Domain Name Protocol
(c+2) to d Additional Domain Name and Domain Name Protocol
e to (n+4) These octet(s) is/are present only if explicitly specified
표 3에서, PFD contents의 Octet 5는 PFD contents의 타입을 나타내는 플래그(Flags)이다.
구체적으로, 각 Flags는 하기와 같은 의미를 가질 수 있다.
- Bit 1 - FD(flow description): 이 Bit가 “1”로 설정되면 표 4의 Length of Flow Description 필드 및 Flow Description 필드가 존재해야 하는 것을 의미할 수 있으며, PFD contents가 Flow Description type이라는 것을 의미할 수 있다. 즉, 이러한 경우 PFD에 Flow description(필터)가 포함된다는 것을 의미할 수 있다. 또는, “0”으로 설정되면 Length of Flow Description 필드 및 Flow Description 필드가 존재하지 않는다는 것을 의미할 수 있다. 즉, 이러한 경우 PFD에 Flow description(필터)가 포함되지 않는다는 것을 의미할 수 있다.
- Bit 2 - URL(URL): 이 Bit가 “1”로 설정되면 표 4의 Length of URL 필드 및 URL 필드가 존재해야 하는 것을 의미할 수 있으며, PFD contents가 URL type이라는 것을 의미할 수 있다. 또는, “0”으로 설정되면 Length of URL 필드 및 URL 필드가 존재하지 않는다는 것을 의미할 수 있다.
- Bit 3 - DN(Domain Name): 이 Bit가 “1”로 설정되면 표 4의 Length of Domain Name 필드 및 Domain Name 필드가 존재하는 것을 의미할 수 있으며, PFD Contents가 Domain Name type이라는 것을 의미할 수 있다. 또는, “0”으로 설정되면 Length of Domain Name 필드 및 Domain Name 필드가 존재하지 않는다는 것을 의미할 수 있다.
- Bit 4 - CP(Custom PFD Content): 이 Bit가 “1”로 설정되면 표 4의 Length of Custom Content 필드 및 Custom PFD Content 필드가 존재하는 것을 의미할 수 있으며, PFD Contents가 Custom PFD Content type이라는 것을 의미할 수 있다. 또는, “0”으로 설정되면 Length of Custom Content 필드 및 Custom PFD Content 필드가 존재하지 않는다는 것을 의미할 수 있다.
- Bit 5 - DNP(Domain Name Protocol): 이 Bit가 “1”로 설정되면 표 4의 Length of Domain Name Protocol 필드 및 Domain Name Protocol 필드가 존재하는 것을 의미할 수 있으며, PFD Contents가 Domain Name Protocol type이라는 것을 의미할 수 있다. 또는, “0”으로 설정되면 Length of Domain Name Protocol 필드 및 Domain Name Protocol 필드가 존재하지 않는다는 것을 의미할 수 있다.
- Bit 6 - AFD(Additional Flow Description): 이 Bit가 “1”로 설정되면 표 4의 Length of Additional Flow Description 필드 및 Additional Flow Description 필드가 존재하는 것을 의미할 수 있으며, PFD Contents가 Additional Flow Description type이라는 것을 의미할 수 있다. 또는, “0”으로 설정되면 Length of Additional Flow Description 필드 및 Additional Flow Description 필드가 존재하지 않는다는 것을 의미할 수 있다.
- Bit 7 - AURL(Additional URL): 이 Bit가 “1”로 설정되면 표 4의 Length of Additional URL 필드 및 Additional URL 필드가 존재하는 것을 의미할 수 있으며, PFD Contents가 Additional URL type이라는 것을 의미할 수 있다. “0”으로 설정되면 Length of Additional URL 필드 및 Additional URL 필드가 존재하지 않는다는 것을 의미할 수 있다.
- Bit 8 - ADNP(Additional Domain Name and Domain Name Protocol): 이 Bit가 “1”로 설정되면 표 4의 Length of Additional Domain Name and Domain Name Protocol 필드 및 Additional Domain Name and Domain Name Protocol 필드가 존재하는 것을 의미할 수 있으며, PFD Contents가 Additional Domain Name and Domain Name Protocol type이라는 것을 의미할 수 있다. 또는, “0”으로 설정되면 Length of Additional Domain Name and Domain Name Protocol 필드 및 Additional Domain Name and Domain Name Protocol 필드가 존재하지 않는다는 것을 의미할 수 있다.
한편, 상술한 PFD 관리 절차에 대한 지원 여부는 SMF 및 UPF의 선택 사항에 해당한다. 따라서, UPF가 PFD 관리 절차를 지원할 수 있는 경우, SMF에 자신이 PFD 관리 절차를 지원할 수 있다는 것을 알려야 하며, 이는 SMF와 UPF 간 N4 Association setup 절차가 수행될 때 이루어질 수 있다. 이에 대한 구체적인 설명은 도 4를 참조하여 설명하기로 한다.
도 4는 본 개시의 일 실시 예에 따른 SMF 및 UPF 간 Association 절차를 도시한 도면이다.
본 개시에서 SMF와 UPF 간 수행되는 N4 Association setup 절차는 SMF와 UPF 간 N4 Association을 생성함으로써, SMF가 UPF의 자원을 사용하여 N4 세션을 설정할 수 있도록 하기 위해 수행되는 일련의 절차를 의미할 수 있다.
도 4를 참조하면, Step 1에서, SMF는 UPF에 N4 Association setup 요청(또는, N4 Association setup 요청 메시지, Association setup 요청, 또는 Association setup 요청 메시지 등 다양한 용어로 지칭될 수 있다.) 을 전송할 수 있다.
Step 2에서, Step 1에서 전송한 N4 Association setup 요청에 응답하여 SMF는 UPF로부터 N4 Association setup 응답(또는, N4 Association setup 응답 메시지, Association setup 응답, 또는 Association setup 응답 메시지 등 다양한 용어로 지칭될 수 있다.)을 수신할 수 있다. 한편, 상기 N4 Association setup 응답 메시지에는 UPF가 지원하는 기능(feature)들에 대한 정보가 포함될 수 있다. 예를 들어, N4 Association setup 응답 메시지는 하기 표 4와 같은 포맷을 따를 수 있다.
Bits
Octets 8 7 6 5 4 3 2 1
1 to 2 Type = 43 (decimal)
3 to 4 Length = n
5 to 6 Supported-Features
7 to 8 Additional Supported-Features 1
9 to 10 Additional Supported-Features 2
11 to (n+4) These octet(s) is/are present only if explicitly specified
표 4에서 Octets 5 - 6에 해당하는 Supported-Features 필드, Octets 7-8에 해당하는 Additional Supported-Feature 1, 및 Octets 9-10에 해당하는 Additional Supported-Feature 2에 설정된 Bit에 기반하여 UPF가 지원하는 기능이 지시될 수 있다. 예를 들어, Octets 5에 해당하는 Supported-Features 필드의 6 Bit를 “1”로 설정함으로써, UPF가 PFD 관리 절차를 수행할 수 있는 기능(PFDM Feature)을 지원한다는 것을 지시할 수 있다. 한편, 본 개시의 도 4에서는 SMF가 N4 Association setup 절차를 개시하는 것을 예로 들었으나, 본 개시가 이에 국한되는 것은 아니다. 즉, UPF가 N4 Association setup 절차를 개시할 수 있으며, 이 경우, N4 Association setup 요청 메시지에 UPF가 지원하는 기능(feature)들에 대한 정보를 포함하여 SMF에 전송할 수 있다.한편, 상술한 PFD 관리 절차에서, PFD 관리 요청 메시지 및 PFD 관리 응답 메시지는 UDP(user datagram protocol)를 기반으로 하는 PFCP(packet forwarding control protocol)을 사용한 N4 인터페이스를 통해 송수신된다. UDP 페이로드의 이론적인 최대 길이는 16 bit 최대 값인 65,535 bytes이므로, UPD에 기반한 PFCP를 사용하는 N4 인터페이스를 통해 전송되는 PFD 관리 요청 메시지의 페이로드는 이보다 짧은 약 6만 bytes 이내여야 한다는 제약이 있다. 한편, 망 운용자가 하나의 어플리케이션에 대해 수백 개 이상의 필터들을 설정하고, 상기 필터들을 각각 포함하는 PFD들을 UPF에 제공하고자 하는 경우, 상기 PFD들을 포함하는 PFD 관리 요청 메시지의 페이로드 길이는 일정 byte(예를 들어, UPD 페이로드의 이론적인 최대 길이) 미만이 될 수 있도록 해야 한다. 예를 들어, 망 운용자가 하기 표 5와 같이 패킷의 소스(Source), 목적지(Destination)를 모두 포함하는 필터를 포함하는 PFD(예를 들어, IPv6 Flow Description type PFD를 지칭할 수 있다.)를 UPF에 제공하고자 하는 경우, PFD 관리 요청 메시지에 포함될 수 있는 하나의 어플리케이션에 대한 PFD의 개수는 약 400개로 제한될 수 있다.
“permit out 17 from 2132:5678:9abc:def0:2132:5678:9abc:def0 65530-65534 to 3132:5678:9abc:def0:3132:5678:9abc:def0 65530-65534”
한편, 대부분의 경우에는 상향링크(Uplink) 방향에 대한 필터 및 하향링크(Downlink) 방향에 대한 필터를 각각 포함하는 두 개의 단일방향(single-directional) PFD가 함께 UPF에 제공된다. 예를 들어, 표 6과 같이 상향링크에 대한 필터를 포함하는 PFD 및 하향링크에 대한 필터를 포함하는 PFD가 각각 PFD 관리 요청 메시지에 포함되어 UPF에 제공될 수 있다.
Uplink: "permit in 17 from any to 10.1.1.10 8080"
Downlink: "permit out 17 from 10.1.1.10 8080 to any"
한편, 표 6의 필터들은 서로 방향만 다를 뿐, 다른 정보(IP Protocol, Source/Destination IP Address, Source/Destination Port Number)는 동일하다. 따라서, 이러한 경우, 상향링크에 대한 필터 및 하향링크에 대한 필터를 모두 UPF에 제공하는 것은 중복적인 정보의 제공일 수 있으며, 제한된 메시지의 Length 자원을 비효율적으로 사용한다고 할 수 있다.
만약, 어느 한 방향에 대한 필터를 UPF에 제공해도, UPF가 제공받은 필터에 기반하여 다른 방향에 대한 필터를 도출해낼 수 있다면, PFD 관리 요청에 포함될 수 있는 PFD의 개수를 감소시킬 수 있으며, 이에 따라 상술한 메시지 길이 제약과 같은 문제점을 해결할 수 있다. 나아가, 보다 다양하고 수많은 필터가 해당 어플리케이션에 설정될 수 있도록 하여 효과적인 어플리케이션 트래픽 감지가 수행될 수 있다. 따라서, 이하에서는 UPF가 어느 한 방향에 대한 필터를 포함하는 PFD만 수신하여도, 다른 방향에 대한 필터를 도출할 수 있는 양방향(Bi-directional) 필터를 제공하는 방법에 대해 구체적으로 설명하기로 한다. 한편, 본 개시에서 양방향 필터는 양방향 Flow description, 또는 이와 동일, 유사한 의미를 가지는 용어에 의해 지칭될 수 있으며, 후술하는 표 8의 포맷에 따른 PFD에 포함된 필터를 의미할 수 있다.
본 개시에서는, SMF는 상향링크에 대한 필터 및 하향링크에 대한 필터 각각을 포함하는 두 개의 단일방향 PFD들을 모두 UPF에 제공하는 대신 어느 한 방향에 대한 필터 및 상기 필터가 양방향으로 적용될 수 있다는 정보(예를 들어, 특정 지시자)을 포함하는 PFD를 UPF에 제공하는 방법을 제안한다. PFD를 제공받은 UPF는, PFD에 포함된 어느 하나의 방향에 대한 필터에 기반하여 반대 방향의 필터를 확인(또는, 도출) 할 수 있고, 이를 어플리케이션의 트래픽 감지 동작에 사용할 수 있다. 한편, 본 개시에서 UPF가 PFD에 포함된 어느 하나의 방향에 대한 필터에 기반하여 반대 방향의 필터를 확인(또는, 도출)하는 동작을 수행할 수 있는 기능(feature)을 BIDIR(Bi-directional) 기능이라고 지칭할 수 있다.
상술한 동작은 제어 평면의 SMF, 사용자 평면의 UPF 모두에 대한 변경 필요할 수 있다. UPF에 따라 상기 BIDIR 기능을 지원하는지 여부는 선택 사항(option)이기 때문이다. 따라서, 본 개시의 일 실시 예에 따른 UPF는 SMF에 자신이 BIDIR 기능을 지원하는지 여부를 알릴 수 있다. 이는 상술한 SMF 및 UPF 간 N4 Association setup 절차에서, UPF가 자신이 지원하는 기능에 대한 정보를 N4 Association setup 요청 메시지(N4 Association setup 절차가 UPF에 의해 개시된 경우), 또는 N4 Association setup 응답 메시지(N4 Association setup 절차가 SMF에 의해 개시된 경우)에 포함하여 SMF에 전송함으로써 이루어질 수 있다. 예를 들어, UPF는 하기 표 7과 같은 포맷(벤더 간 합의에 의해 정의될 수 있는 Vendor-Specific information element format일 수 있다.)에 따라 자신이 지원하는 기능에 대한 정보를 N4 Association setup 요청 메시지 또는 N4 Association setup 응답 메시지에 포함하여 SMF에 알릴 수 있다.
Figure pat00001
표 7에 따르면, Octets 7에 해당하는 필드의 Bit 1이 “1” 설정될 경우, UPF가 BIDIR 기능을 지원한다는 것을 지시할 수 있다.
SMF는 UPF에 제공할 필터가 양방향으로 적용될 수 있는지 확인하고, 만약 양방향으로 적용될 수 있다면 UPF가 BIDIR 기능을 지원한다는 것을 확인할 수 있다. UPF가 BIDIR 기능을 지원하는 경우, SMF는 상기 필터 및 상기 필터가 양방향으로 적용될 수 있다는 지시자를 포함하는 PFD를 UPF에 제공할 수 있다. 한편, 본 개시에서 SMF가 양방향으로 적용될 수 있는 필터를 포함하는 PFD를 UPF에 제공하는 경우, 상기 PFD에 포함될 수 있는 정보(PFD contents)는 하기 표 8과 같은 포맷에 따를 수 있다.
Figure pat00002
표 8에 따르면, Octets 5의 bit 4를 “1”로 설정하여 Custom PFD contents 필드가 존재한다는 것을 지시할 수 있고, PFD 내용이 시작되는 Octet 9의 필드에 해당 PFD에 포함된 필터가 이 양방향으로 적용될 수 있는 필터임을 나타내는 type을 지정하고, 이후의 필드에 어느 한 방향(예를 들어, 상향링크 또는 하향링크)에 대한 필터를 포함하는 PFD를 UPF에 제공할 수 있다. UPF는 수신한 PFD에 포함된 필터가 양방향으로 적용될 수 있는지 여부를 해당 PFD에 포함된 정보(예를 들어, PFD의 타입에 대한 정보, 또는 지시자)에 기반하여 확인할 수 있으며, 이에 따라 어플리케이션 트래픽 감지 동작을 수행할 수 있다. 이하, 본 개시에서 제안하는 PFD 제공 방법에 따라 동작하는 SMF 및 UPF의 동작을 도 5 내지 도 9을 참조하여 설명하기로 한다.
도 5는 본 개시의 일 실시 예에 따른 SMF의 동작을 도시한 도면이다.
도 5를 참조하면, Step 1에서, SMF는 어플리케이션에 대한 필터가 상향링크 방향, 하향링크 방향, 또는 양방향에 대한 것인지 확인하고, 상기 필터가 양방향으로 적용될 수 있는지 여부(양방향 필터인지 여부)를 확인할 수 있다. 예를 들어, 상기 필터가 양방향에 대한 것으로 미리 설정되었거나, 상향링크 방향에 대한 필터와 하향링크 방향에 대한 필터가 소스와 목적지가 반대일 뿐 다른 정보(예를 들어, IP Protocol, IP address, Port)가 동일한 경우, 상향링크 방향에 대한 필터(또는, 하향링크 방향에 대한 필터)는 양방향으로 적용될 수 있다고 확인할 수 있다. 즉, 본 개시에서 필터가 양방향으로 적용될 수 있다는 것은, 해당 필터의 정보 중 소스 및 목적지 정보만 스위칭한 결과, 반대 방향에 대한 필터와 동일한 필터가 획득될 수 있다는 것을 의미할 수 있다. 예를 들어, 상향링크 방향에 대한 필터(이하, 제1 필터로 지칭하기로 한다.)와 하향링크 방향에 대한 필터(이하, 제2 필터로 지칭하기로 한다.)가 존재하는 경우, 상기 제1 필터의 정보 중 소스 및 목적지 정보만 스위칭한 결과, 상기 제2 필터와 동일한 필터가 획득(또는, 생성)되는 경우, 상기 제1 필터는 양방향으로 적용될 수 있다고 확인할 수 있다. 이와 달리, 상기 제1 필터의 정보 중 소스 및 목적지 정보만 스위칭한 결과, 상기 제2 필터와 다른 필터가 획득되는 경우, 상기 제1 필터는 양방향으로 적용될 수 없다고 확인할 수 있다. 또한, 본 개시에서 필터가 양방향으로 적용될 수 있는지 확인하는 것은 해당 필터가 양방향 필터인지 여부를 확인하는 것을 의미할 수도 있다.
Step 2에서, SMF는 필터가 양방향으로 적용될 수 있다고 확인되는 경우, UPF가 어느 한 방향에 대한 필터로부터 다른 방향에 대한 필터를 도출할 수 있는 BIDIR 기능을 지원하는지 여부를 확인할 수 있다. 예를 들어, SMF는 UPF와의 N4 Association setup 절차에서 수신한 UPF가 지원하는 기능에 대한 정보에 기반하여, 이를 확인할 수 있다.
Step 3에서, 만약 UPF가 BIDIR 기능을 지원하지 않는 경우, SMF는 상향링크 방향에 대한 필터 및 하향링크 방향에 대한 필터 각각을 포함하는 두 개의 PFD들을 확인(또는, 생성, 획득)할 수 있다. 여기에서, PFD는 상술한 표 3과 같은 포맷에 따를 수 있다. 이와 달리, 만약 UPF가 BIDIR 기능을 지원하는 경우, SMF는 어느 한 방향에 대한 필터 및 상기 필터가 양방향으로 적용될 수 있다는 정보(예를 들어, type 정보, 지시자)를 포함하는 PFD를(또는, 생성, 획득) 확인할 수 있다. 여기에서, PFD는 상술한 표 8과 같은 포맷에 따를 수 있다.
Step 4에서, SMF는 Step 3에서 확인된 PFD를 PFD 관리 요청 메시지에 포함하여, UPF에 전송할 수 있다.
한편, 도 5의 Step 1 내지 Step 4는 동시에 수행될 수 있으며, 일부가 생략될 수도 있다.
도 6은 본 개시의 일 실시 예에 따른 SMF가 UPF에 어플리케이션의 트래픽을 감지하기 위한 필터를 포함하는 PFD를 제공하는 과정을 도시한 도면이다.
도 6을 참조하면, Step 1에서, SMF는 어플리케이션에 대한 필터가 상향링크 방향, 하향링크 방향, 또는 양방향에 대한 것인지 확인하고, 상기 필터가 양방향으로 적용될 수 있는지 여부를 확인할 수 있다. 예를 들어, 상기 필터가 양방향에 대한 것으로 미리 설정되었거나, 상향링크 방향에 대한 필터와 하향링크 방향에 대한 필터가 소스와 목적지가 반대일 뿐 다른 정보(예를 들어, IP Protocol, IP address, Port)가 동일한 경우, 상향링크 방향에 대한 필터(또는, 하향링크 방향에 대한 필터)는 양방향으로 적용될 수 있다고 확인할 수 있다. 만약, Step 1에서 필터가 양방향으로 적용될 수 없다고 확인되는 경우, Step 2에서, SMF는 상향링크 방향에 대한 필터 및 하향링크 방향에 대한 필터 각각을 포함하는 두 개의 PFD들을 확인(또는, 생성, 획득)할 수 있다. 여기에서, PFD는 상술한 표 3과 같은 포맷에 따를 수 있다.
만약 Step 1에서 필터가 양방향으로 적용될 수 있다고 확인되는 경우, Step 3에서, SMF는 UPF가 어느 한 방향에 대한 필터로부터 다른 방향에 대한 필터를 도출할 수 있는 BIDIR 기능을 지원하는지 여부를 확인할 수 있다. 예를 들어, SMF는 UPF와의 N4 Association setup 절차에서 수신한 UPF가 지원하는 기능에 대한 정보에 기반하여, 이를 확인할 수 있다.
만약 Step 3에서 UPF가 BIDIR 기능을 지원하는 것으로 확인되는 경우, Step 4에서, SMF는 어느 한 방향에 대한 필터 및 상기 필터가 양방향으로 적용될 수 있다는 정보(예를 들어, type 정보, 지시자)를 포함하는 PFD를(또는, 생성, 획득) 확인할 수 있다. 여기에서, PFD는 상술한 표 8과 같은 포맷에 따를 수 있다.
만약 Step 3에서 UPF가 BIDIR 기능을 지원하지 않는 것으로 확인되는 경우, Step 5에서, SMF는 상향링크 방향에 대한 필터 및 하향링크 방향에 대한 필터 각각을 포함하는 두 개의 PFD들을 확인(또는, 생성, 획득)할 수 있다. 여기에서, PFD는 상술한 표 3과 같은 포맷에 따를 수 있다.
Step 6에서, SMF는 상기 Step 2, Step 4, 또는 Step 5에서 확인된 PFD를 PFD 관리 요청 메시지에 포함하여, UPF에 전송할 수 있다.
한편, 도 6의 Step 1 내지 Step 6는 동시에 수행될 수 있으며, 일부가 생략될 수도 있다.
도 7은 본 개시의 일 실시 예에 따른 UPF의 동작을 도시한 도면이다.
도 7을 참조하면, Step 1에서 UPF는 SMF로부터 어플리케이션에 대한 복수의 PFD들을 포함하는 PFD 관리 요청 메시지를 수신할 수 있다.
Step 2에서, UPF는 수신된 PFD에 포함된 정보(예를 들어, type 정보, 지시자)에 기반하여 필터가 양방향으로 적용될 수 있는지 여부를 확인할 수 있다. 예를 들어, 수신된 PFD가 표 3과 같은 포맷에 따라 필터를 포함하고 있는 경우, UPF는 상기 필터가 양방향으로 적용될 수 없는 단일방향에 대한 필터임을 확인할 수 있다. 이와 달리, 수신된 PFD가 표 8과 같은 포맷에 따라 필터를 포함하고 있는 경우, UPF는 상기 필터가 양방향으로 적용될 수 있다는 점을 확인할 수 있다.
Step 1에서 수신된 필터가 양방향으로 적용될 수 있다고 확인되는 경우, Step 3에서, UPF는 어느 하나의 방향에 대한 상기 필터로부터 다른 방향에 대한 필터를 도출(또는, 획득, 생성)하고, 두 개의 필터들을 어플리케이션의 트래픽을 감지하는 필터로 적용할 수 있다. 예를 들어, 수신된 필터가 상향링크 방향에 대한 필터이고, 양방향으로 적용될 수 있다고 확인되는 경우, UPF는 상기 필터로부터 하향링크 방향에 대한 필터를 도출할 수 있고, 수신된 필터 및 도출된 필터를 어플리케이션의 트래픽을 감지하는 필터로 적용할 수 있다. 한편, 본 개시에서 어느 하나의 방향에 대한 필터로부터 다른 방향에 대한 필터를 도출하는 동작은, 필터의 소스, 목적지를 스위칭함으로써, 해당 필터와 다른 방향인 필터를 확인하는 동작을 의미할 수 있다.
Step 4에서, UPF는 Step 1에서 수신한 PFD 관리 요청 메시지에 대한 응답으로, PFD 관리가 성공하였음을 나타내는 정보를 포함한 PFD 관리 응답 메시지를 SMF에 전송할 수 있다.
이후, Step 5에서,UPF는 확인된 필터들에 기반하여 어플리케이션의 트래픽을 감지하는 동작을 수행할 수 있다. 예를 들어, UPF는 확인된 필터와 매칭(mathching)하는 어플리케이션의 트래픽이 발생하였는지 여부를 확인할 수 있다.
한편, 도 7의 Step 1 내지 Step 5는 동시에 수행될 수 있으며, 일부가 생략될 수도 있다.
도 8은 본 개시의 일 실시 예에 따른 UPF가 SMF로부터 어플리케이션의 트래픽을 감지하기 위한 필터를 포함하는 PFD를 제공받고, 필터에 기반하여 어플리케이션 트래픽 감지 동작을 수행하는 과정을 도시한 도면이다.
도 8을 참조하면. Step 1에서, Step 1에서 UPF는 SMF로부터 어플리케이션에 대한 복수의 PFD들을 포함하는 PFD 관리 요청 메시지를 수신할 수 있다.
Step 2에서, UPF는 수신된 PFD에 포함된 정보(예를 들어, type 정보, 지시자)에 기반하여 필터가 양방향으로 적용될 수 있는지 여부를 확인할 수 있다. 예를 들어, 수신된 PFD가 표 3과 같은 포맷에 따라 필터를 포함하고 있는 경우, UPF는 상기 필터가 양방향으로 적용될 수 없는 단일방향에 대한 필터임을 확인할 수 있다. 이와 달리, 수신된 PFD가 표 8과 같은 포맷에 따라 필터를 포함하고 있는 경우, UPF는 상기 필터가 양방향으로 적용될 수 있다는 점을 확인할 수 있다.
Step 1에서 수신된 필터가 단일방향(예를 들어, 상향링크 방향 또는 하향링크 방향)으로만 적용될 수 있다고 확인되거나 경우 UPF가 BIDIR 기능을 지원하지 않는 경우, Step 4에서, UPF는 단일방향의 필터를 어플리케이션의 트래픽을 감지하는 필터로 적용할 수 있다.
Step 1에서 수신된 필터가 양방향으로 적용될 수 있다고 확인되는 경우, Step 3에서, UPF는 어느 하나의 방향에 대한 상기 필터로부터 다른 방향에 대한 필터를 도출하고, 두 개의 필터들을 어플리케이션의 트래픽을 감지하는 필터로 적용할 수 있다. 예를 들어, 수신된 필터가 상향링크 방향에 대한 필터이고, 양방향으로 적용될 수 있다고 확인되는 경우, UPF는 상기 필터로부터 하향링크 방향에 대한 필터를 도출할 수 있고, 수신된 필터 및 도출된 필터를 어플리케이션의 트래픽을 감지하는 필터로 적용할 수 있다. 한편, 본 개시에서 어느 하나의 방향에 대한 필터로부터 다른 방향에 대한 필터를 도출하는 동작은, 필터의 소스, 목적지를 스위칭함으로써, 해당 필터와 다른 방향인 필터를 확인하는 동작을 의미할 수 있다.
Step 5에서, UPF는 Step 1에서 수신한 PFD 관리 요청 메시지에 대한 응답으로, PFD 관리가 성공하였음을 나타내는 정보를 포함한 PFD 관리 응답 메시지를 SMF에 전송할 수 있다.
이후, Step 6에서,UPF는 Step 3 또는 Step 4에서 확인된 필터에 기반하여 어플리케이션의 트래픽을 감지하는 동작을 수행할 수 있다. 예를 들어, UPF는 확인된 필터와 매칭(mathching)하는 어플리케이션의 트래픽이 발생하였는지 여부를 확인할 수 있다. 한편, 도 8의 Step 1 내지 Step 6는 동시에 수행될 수 있으며, 일부가 생략될 수도 있다.
도 9는 본 개시의 일 실시 예에 따른 SMF가 양방향 필터를 포함하는 PFD을 UPF에 제공하는 PFD 관리 절차의 전반적인 흐름을 도시한 도면이다.
도 9를 참조하면, Step 1에서, SMF와 UPF는 N4 Association setup 절차를 수행할 수 있다. 본 개시에서 N4 Association setup 절차는 SMF 또는 UPF에 의해 개시될 수 있으며, UPF는 자신이 지원하는 기능에 대한 정보(예를 들어, 본 개시에 따른 PFDM 기능, 또는 BIDIR 기능)를 N4 Association setup 요청 메시지(N4 Association setup 절차가 UPF에 의해 개시된 경우), 또는 N4 Association setup 응답 메시지(N4 Association setup 절차가 SMF에 의해 개시된 경우)에 포함하여 SMF에 전송할 수 있다.
Step 2에서, SMF는 어플리케이션에 대한 필터가 상향링크 방향, 하향링크 방향, 또는 양방향에 대한 것인지 확인하고, 상기 필터가 양방향으로 적용될 수 있는지 여부를 확인할 수 있다. 예를 들어, 상기 필터가 양방향에 대한 것으로 미리 설정되었거나, 상향링크 방향에 대한 필터와 하향링크 방향에 대한 필터가 소스와 목적지가 반대일 뿐 다른 정보(예를 들어, IP Protocol, IP address, Port)가 동일한 경우, 상향링크 방향에 대한 패킷 필터(또는, 하향링크 방향에 대한 패킷 필터)는 양방향으로 적용될 수 있다고 확인할 수 있다.
Step 3에서, 만약 Step 1에서 필터가 양방향으로 적용될 수 있다고 확인되는 경우, Step 3에서, SMF는 UPF가 어느 한 방향에 대한 필터로부터 다른 방향에 대한 필터를 도출할 수 있는 BIDIR 기능을 지원하는지 여부를 확인할 수 있다. 예를 들어, SMF는 UPF와의 N4 Association setup 절차에서 수신한 UPF가 지원하는 기능에 대한 정보에 기반하여, 이를 확인할 수 있다.
만약 Step 3에서 UPF가 BIDIR 기능을 지원하는 것으로 확인되는 경우, Step 4에서, SMF는 어느 한 방향에 대한 필터 및 상기 필터가 양방향으로 적용될 수 있다는 정보(예를 들어, type 정보, 지시자)를 포함하는 PFD를(또는, 생성, 획득) 확인할 수 있다. 여기에서, PFD는 상술한 표 8과 같은 포맷에 따를 수 있다.
Step 5에서, SMF는 확인된 PFD를 PFD 관리 요청 메시지에 포함하여, UPF에 전송할 수 있다.
Step 6에서, UPF는 수신된 PFD에 포함된 정보(예를 들어, type 정보, 지시자)에 기반하여 필터가 양방향으로 적용될 수 있는지 여부를 확인할 수 있다. 예를 들어, 수신된 PFD가 표 3과 같은 포맷에 따라 필터를 포함하고 있는 경우, UPF는 상기 필터가 양방향으로 적용될 수 없는 단일방향에 대한 필터임을 확인할 수 있다. 이와 달리, 수신된 PFD가 표 8과 같은 포맷에 따라 필터를 포함하고 있는 경우, UPF는 상기 필터가 양방향으로 적용될 수 있다는 점을 확인할 수 있다.
Step 7에서, 수신된 필터가 단일방향(예를 들어, 상향링크 방향 또는 하향링크 방향)으로만 적용될 수 있다고 확인되는 경우, 단일방향의 필터를 어플리케이션의 트래픽을 감지하는 필터로 적용할 수 있다. 이와 달리, 수신된 필터가 양방향으로 적용될 수 있다고 확인되는 경우, UPF는 어느 하나의 방향에 대한 상기 필터로부터 다른 방향에 대한 필터를 도출하고, 두 개의 필터들을 어플리케이션의 트래픽을 감지하는 필터로 적용할 수 있다.
Step 8에서, UPF는 Step 5에서 수신한 PFD 관리 요청 메시지에 대한 응답으로, PFD 관리가 성공하였음을 나타내는 정보를 포함한 PFD 관리 응답 메시지를 SMF에 전송할 수 있다.
이후, Step 9에서,UPF는 확인된 필터에 기반하여 어플리케이션의 트래픽을 감지하는 동작을 수행할 수 있다. 예를 들어, UPF는 확인된 필터와 매칭(mathching)하는 어플리케이션의 트래픽이 발생하였는지 여부를 확인할 수 있다.
상술한 방법에 따르면, 양방향 필터를 포함하는 PFD를 수신한 UPF가 어느 한 방향에 대한 수신된 필터로부터 다른 방향에 대한 필터를 도출할 수 있게 됨으로써, SMF의 관점에서 방향만 다를 뿐 다른 정보는 동일하여 중복적인 정보를 포함하는 필터들 UPF에 제공할 필요가 없으므로, 메시지 길이 제약 문제를 해결할 수 있다. 나아가, 망 운용자는 하나의 어플리케이션에 대해 보다 많은 개수의 필터들을 설정하고, 이들을 포함하는 PFD를 UPF에 제공할 수 있게 되어 보다 효율적인 시스템이 구현될 수 있다.
도 10은 본 개시의 일 실시 예에 따른 SMF를 수행할 수 있는 네트워크 엔티티의 구조를 도시한 도면이다.
도 10을 참조하면, 본 개시의 일 실시 예에 따른 SMF를 수행할 수 있는 네트워크 엔티티는 송수신부(1005), 제어부(1010), 및 메모리(1015)을 포함하여 구성될 수 있다.
송수신부(1005)는 다른 네트워크 엔티티와 신호를 송수신할 수 있다. 예를 들어, 송수신부(1005)는 케이블 등 네트워크 인터페이스(network interface)를 통해 다른 네트워크 엔티티와 신호를 송수신할 수 있다. 송수신부는 예를 들어, 기지국에 시스템 정보를 전송할 수 있으며, 동기 신호 또는 기준 신호를 전송할 수 있다.
제어부(1010)는 본 개시에서 제안하는 실시 예에 따른 SMF의 전반적인 동작을 제어할 수 있다.
메모리(1015)는 송수신부(1005)를 통해 송수신되는 정보 및 제어부(1010)를 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다.
도 11은 본 개시의 일 실시 예에 따른 UPF를 수행할 수 있는 네트워크 엔티티의 구조를 도시한 도면이다.
도 11을 참조하면, 본 개시의 일 실시 예에 따른 UPF를 수행할 수 있는 네트워크 엔티티는 송수신부(1105), 제어부(1110), 및 메모리(1115)을 포함하여 구성될 수 있다.
송수신부(1105)는 다른 네트워크 엔티티와 신호를 송수신할 수 있다. 예를 들어, 송수신부(1105)는 케이블 등 네트워크 인터페이스(network interface)를 통해 다른 네트워크 엔티티와 신호를 송수신할 수 있다. 송수신부는 예를 들어, 기지국에 시스템 정보를 전송할 수 있으며, 동기 신호 또는 기준 신호를 전송할 수 있다.
제어부(1110)는 본 개시에서 제안하는 실시 예에 따른 SMF의 전반적인 동작을 제어할 수 있다.
메모리(1115)는 송수신부(1105)를 통해 송수신되는 정보 및 제어부(1110)를 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다.
본 개시에서 제안하는 방법들은 발명의 본질을 해치지 않는 범위 내에서 각 실시 예에 포함된 내용의 일부 또는 전부가 조합되어 실행될 수도 있다.
한편, 본 명세서와 도면에 개시된 본 발명의 실시 예들은 본 발명의 기술 내용을 쉽게 설명하고 본 개시의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 개시의 범위를 한정하고자 하는 것은 아니다. 즉 본 개시의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 개시의 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.
또한, 본 명세서와 도면에는 본 개시의 바람직한 실시 예에 대하여 개시하였으며, 비록 특정 용어들이 사용되었으나, 이는 단지 본 발명의 기술 내용을 쉽게 설명하고 발명의 이해를 돕기 위한 일반적인 의미에서 사용된 것이지, 본 개시의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예 외에도 본 개시의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.

Claims (20)

  1. 통신 시스템에서 SMF(session management function)을 수행하는 제1 네트워크 엔티티의 방법에 있어서,
    어플리케이션과 연관된 제1 방향에 대한 제1 필터 및 제2 방향에 대한 제2 필터를 획득하는 단계;
    상기 제1 필터 및 상기 제2 필터를 비교한 결과에 기반하여, 상기 제1 필터가 양방향 필터인지 여부를 확인하는 단계;
    상기 제1 필터가 상기 양방향 필터인 경우, UPF(user plane function)을 수행하는 제2 네트워크 엔티티가 상기 제1 필터에 기반하여 상기 제2 필터를 획득하는 기능을 지원하는지 확인하는 단계; 및
    상기 제2 네트워크 엔티티가 상기 기능을 지원하는 경우, 상기 제1 필터 및 상기 제1 필터가 상기 양방향 필터라는 것을 지시하는 정보를 포함하는 메시지를 상기 제2 네트워크 엔티티에 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
  2. 제1항에 있어서,
    상기 제2 네트워크 엔티티에 association setup 요청 메시지를 전송하는 단계; 및
    상기 제1 메시지에 대한 응답으로, 상기 제2 네트워크 엔티티의 기능 정보를 포함하는 association setup 응답 메시지를 상기 제2 네트워크 엔티티로부터 수신하는 단계를 더 포함하며,
    상기 기능 정보는 상기 제2 네트워크 엔티티가 상기 기능을 지원하는지 여부에 대한 정보를 포함하는 것을 특징으로 하는 방법.
  3. 제1항에 있어서,
    상기 제1 필터 및 상기 제2 필터를 비교한 결과, 상기 제1 필터의 소스(source) 정보 및 목적지(destination) 정보에 대한 정보가 상기 제2 필터의 목적지 정보 및 소스 정보에 각각 대응하고 다른 정보는 동일한 경우, 상기 제1 필터는 상기 양방향 필터인 것으로 확인되고,
    상기 제1 필터가 상기 양방향 필터인 경우, 상기 제2 필터는 상기 제1 필터에 기반하여 상기 제2 네트워크 엔티티에 의해 획득되며,
    상기 제1 필터 및 상기 제2 필터는 상기 어플리케이션의 트래픽(traffic)을 감지(detect)하는데 사용되는 것을 특징으로 하는 방법.
  4. 제1항에 있어서,
    상기 제1 필터가 상기 양방향 필터가 아닌 경우, 상기 제1 필터 및 상기 제2 필터를 포함하는 메시지를 상기 제2 네트워크 엔티티에 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  5. 제1항에 있어서,
    상기 제2 네트워크 엔티티가 상기 기능을 지원하지 않는 경우, 상기 제1 필터 및 상기 제2 필터를 포함하는 메시지를 상기 제2 네트워크 엔티티에 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  6. 통신 시스템에서 UPF(user plane function)을 수행하는 제2 네트워크 엔티티의 방법에 있어서,
    SMF(session management function)을 수행하는 제1 네트워크 엔티티로부터, 어플리케이션과 연관된 제1 방향에 대한 제1 필터를 포함하는 메시지를 수신하는 단계;
    상기 메시지에 상기 제1 필터가 양방향 필터라는 것을 지시하는 정보가 포함되어 있는 경우, 상기 제1 필터의 정보에 기반하여 제2 방향에 대한 제2 필터를 확인하는 단계; 및
    상기 제1 필터 및 상기 제2 필터에 기반하여, 상기 어플리케이션의 트래픽(traffic)을 감지(detect)하는 단계를 포함하는 것을 특징으로 하는 방법.
  7. 제6항에 있어서,
    상기 제1 네트워크 엔티티로부터, association setup 요청 메시지를 수신하는 단계; 및
    상기 제1 메시지에 대한 응답으로, 상기 제2 네트워크 엔티티의 기능 정보를 포함하는 association setup 응답 메시지를 상기 제1 네트워크 엔티티에 전송하는 단계를 더 포함하며,
    상기 기능 정보는 상기 제2 네트워크 엔티티가 상기 제1 필터에 기반하여 상기 제2 필터를 확인하는 기능을 지원하는지 여부에 대한 정보를 포함하는 것을 특징으로 하는 방법.
  8. 제7항에 있어서,
    상기 제2 네트워크 엔티티는 상기 기능을 지원하는 것을 특징으로 하는 방법.
  9. 제6항에 있어서,
    상기 제1 필터의 소스(source) 정보 및 목적지(destination) 정보에 대한 정보는 상기 제2 필터의 목적지 정보 및 소스 정보에 각각 대응하고, 다른 정보는 동일한 것을 특징으로 하는 방법.
  10. 제6항에 있어서,
    상기 어플리케이션의 상기 트래픽을 감지하는 단계는,
    상기 제1 필터 및 상기 제2 필터 중 적어도 하나와 상기 트래픽이 매칭하는지 여부를 확인하는 단계를 포함하는 것을 특징으로 하는 방법.
  11. 통신 시스템에서 SMF(session management function)을 수행하는 제1 네트워크 엔티티에 있어서,
    송수신부; 및
    어플리케이션과 연관된 제1 방향에 대한 제1 필터 및 제2 방향에 대한 제2 필터를 획득하고,
    상기 제1 필터 및 상기 제2 필터를 비교한 결과에 기반하여, 상기 제1 필터가 양방향 필터인지 여부를 확인하고,
    상기 제1 필터가 상기 양방향 필터인 경우, UPF(user plane function)을 수행하는 제2 네트워크 엔티티가 상기 제1 필터에 기반하여 상기 제2 필터를 획득하는 기능을 지원하는지 확인하며,
    상기 제2 네트워크 엔티티가 상기 기능을 지원하는 경우, 상기 제1 필터 및 상기 제1 필터가 상기 양방향 필터라는 것을 지시하는 정보를 포함하는 메시지를 상기 제2 네트워크 엔티티에 전송하도록 상기 송수신부를 제어하는 제어부를 포함하는 것을 특징으로 하는 제1 네트워크 엔티티.
  12. 제11항에 있어서,
    상기 제어부는,
    상기 제2 네트워크 엔티티에 association setup 요청 메시지를 전송하도록 상기 송수신부를 제어하고,
    상기 제1 메시지에 대한 응답으로, 상기 제2 네트워크 엔티티의 기능 정보를 포함하는 association setup 응답 메시지를 상기 제2 네트워크 엔티티로부터 수신하도록 상기 송수신부를 제어하며,
    상기 기능 정보는 상기 제2 네트워크 엔티티가 상기 기능을 지원하는지 여부에 대한 정보를 포함하는 것을 특징으로 하는 제1 네트워크 엔티티.
  13. 제11항에 있어서,
    상기 제1 필터 및 상기 제2 필터를 비교한 결과, 상기 제1 필터의 소스(source) 정보 및 목적지(destination) 정보에 대한 정보가 상기 제2 필터의 목적지 정보 및 소스 정보에 각각 대응하고 다른 정보는 동일한 경우, 상기 제1 필터는 상기 양방향 필터인 것으로 확인되고,
    상기 제1 필터가 상기 양방향 필터인 경우, 상기 제2 필터는 상기 제1 필터에 기반하여 상기 제2 네트워크 엔티티에 의해 획득되며,
    상기 제1 필터 및 상기 제2 필터는 상기 어플리케이션의 트래픽(traffic)을 감지(detect)하는데 사용되는 것을 특징으로 하는 제1 네트워크 엔티티.
  14. 제11항에 있어서,
    상기 제어부는,
    상기 제1 필터가 상기 양방향 필터가 아닌 경우, 상기 제1 필터 및 상기 제2 필터를 포함하는 메시지를 상기 제2 네트워크 엔티티에 전송하도록 상기 송수신부를 제어하는 것을 특징으로 하는 제1 네트워크 엔티티.
  15. 제11항에 있어서,
    상기 제어부는,
    상기 제2 네트워크 엔티티가 상기 기능을 지원하지 않는 경우, 상기 제1 필터 및 상기 제2 필터를 포함하는 메시지를 상기 제2 네트워크 엔티티에 전송하도록 상기 송수신부를 제어하는 것을 특징으로 하는 제1 네트워크 엔티티.
  16. 통신 시스템에서 UPF(user plane function)을 수행하는 제2 네트워크 엔티티에 있어서,
    송수신부; 및
    SMF(session management function)을 수행하는 제1 네트워크 엔티티로부터, 어플리케이션과 연관된 제1 방향에 대한 제1 필터를 포함하는 메시지를 수신하도록 상기 송수신부를 제어하고,
    상기 메시지에 상기 제1 필터가 양방향 필터라는 것을 지시하는 정보가 포함되어 있는 경우, 상기 제1 필터의 정보에 기반하여 제2 방향에 대한 제2 필터를 확인하고,
    상기 제1 필터 및 상기 제2 필터에 기반하여, 상기 어플리케이션의 트래픽(traffic)을 감지(detect)하는 제어부를 포함하는 것을 특징으로 하는 제2 네트워크 엔티티.
  17. 제16항에 있어서,
    상기 제어부는,
    상기 제1 네트워크 엔티티로부터, association setup 요청 메시지를 수신하도록 상기 송수신부를 제어하고,
    상기 제1 메시지에 대한 응답으로, 상기 제2 네트워크 엔티티의 기능 정보를 포함하는 association setup 응답 메시지를 상기 제1 네트워크 엔티티에 전송하도록 상기 송수신부를 제어하며,
    상기 기능 정보는 상기 제2 네트워크 엔티티가 상기 제1 필터에 기반하여 상기 제2 필터를 확인하는 기능을 지원하는지 여부에 대한 정보를 포함하는 것을 특징으로 하는 제2 네트워크 엔티티.
  18. 제17항에 있어서,
    상기 제2 네트워크 엔티티는 상기 기능을 지원하는 것을 특징으로 하는 제2 네트워크 엔티티.
  19. 제16항에 있어서,
    상기 제1 필터의 소스(source) 정보 및 목적지(destination) 정보에 대한 정보는 상기 제2 필터의 목적지 정보 및 소스 정보에 각각 대응하고, 다른 정보는 동일한 것을 특징으로 하는 제2 네트워크 엔티티.
  20. 제16항에 있어서,
    상기 제어부는,
    상기 제1 필터 및 상기 제2 필터 중 적어도 하나와 상기 트래픽이 매칭하는지 여부를 확인하는 것을 특징으로 하는 제2 네트워크 엔티티.
KR1020210033158A 2021-03-15 2021-03-15 Pfd 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치 KR20220128714A (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/KR2021/003158 WO2022196837A1 (ko) 2021-03-15 2021-03-15 Pfd 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치
KR1020210033158A KR20220128714A (ko) 2021-03-15 2021-03-15 Pfd 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치
US18/368,418 US20240031257A1 (en) 2021-03-15 2023-09-14 Method and device for provisioning bidirectional filter in pfd management procedure

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020210033158A KR20220128714A (ko) 2021-03-15 2021-03-15 Pfd 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치

Publications (1)

Publication Number Publication Date
KR20220128714A true KR20220128714A (ko) 2022-09-22

Family

ID=83320505

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020210033158A KR20220128714A (ko) 2021-03-15 2021-03-15 Pfd 관리 절차에서 양방향 필터를 프로비저닝하는 방법 및 장치

Country Status (3)

Country Link
US (1) US20240031257A1 (ko)
KR (1) KR20220128714A (ko)
WO (1) WO2022196837A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230007485A1 (en) * 2021-06-30 2023-01-05 At&T Mobility Ii Llc Systems and methods for network anomalies management

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10531420B2 (en) * 2017-01-05 2020-01-07 Huawei Technologies Co., Ltd. Systems and methods for application-friendly protocol data unit (PDU) session management
KR20190132921A (ko) * 2018-05-21 2019-11-29 한국전자통신연구원 네트워크에서 멀티 액세스 네트워크를 통한 트래픽 분산 방법 및 이를 수행하는 네트워크 엔터티

Also Published As

Publication number Publication date
WO2022196837A1 (ko) 2022-09-22
US20240031257A1 (en) 2024-01-25

Similar Documents

Publication Publication Date Title
US11570827B2 (en) Network-initiated PDU session connection update method between terminal and network
US10826769B2 (en) Data processing method and device
US10966139B2 (en) Apparatus and method for routing data packet to user equipment in LTE-WLAN aggregation system
CN108476394B (zh) 移动通信***中终端通信的方法和装置
CN109863789B (zh) 在移动通信***中基于可适用网络信息将终端连接到网络的方法及设备
JP7497368B2 (ja) 無線通信システムにおいて、一対一通信サービスを提供する方法及びその装置
US9125003B2 (en) Machine to machine service management device, network device, and method processing service system
CN110547003B (zh) 用于服务协商的注册类型添加的方法和装置
KR102412288B1 (ko) 제 3자 응용 서버에서 단말의 무선 연결 타입 변경을 확인하는 방법
KR102396950B1 (ko) 5g 무선통신 네트워크 시스템에서 최고 신뢰성있는 서비스를 위한 이중 전송 방법 및 장치
KR20160106520A (ko) 무선 통신 시스템에서 서비스 제공 방법 및 장치
KR20180106804A (ko) 셀룰러망의 효율적 pdu 세션 활성화 및 비활성화 방안
US20150257182A1 (en) Mobile network communications method, communications apparatus, and communications system
US9992109B2 (en) Data transmission method, apparatus and system
EP4185009A1 (en) Packet forwarding method, apparatus and system
JP2022551708A (ja) 無線アクセスネットワーク通信システムにおけるｅ２インタフェースを介するサービス加入のための装置及び方法
US20240031257A1 (en) Method and device for provisioning bidirectional filter in pfd management procedure
WO2015018038A1 (zh) 一种隧道建立的方法及装置
KR102489245B1 (ko) 무선 통신 시스템에서 규칙 정보를 전송하는 방법 및 장치.
WO2013182049A1 (zh) 一种集群业务实现方法及其装置
KR20210055537A (ko) 무선 통신 시스템에서 로컬 프로세싱을 위한 트래픽 스티어링을 위한 방법 및 장치
US20230132454A1 (en) Method and apparatus for supporting edge computing service for roaming ue in wireless communication system
KR20200099328A (ko) Dn authorized pdu세션 재인증 지원 및 dn authorization data 변경에 따른 pdu세션 관리 방법 및 장치
WO2022033374A1 (zh) 网络共享下的网络连接方法、电子设备和存储介质
KR20220106623A (ko) 이동통신 시스템에서 세션 관리 방법 및 장치

Legal Events

Date Code Title Description
A201 Request for examination