KR20140094306A - 무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법 - Google Patents

무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법 Download PDF

Info

Publication number
KR20140094306A
KR20140094306A KR1020130006959A KR20130006959A KR20140094306A KR 20140094306 A KR20140094306 A KR 20140094306A KR 1020130006959 A KR1020130006959 A KR 1020130006959A KR 20130006959 A KR20130006959 A KR 20130006959A KR 20140094306 A KR20140094306 A KR 20140094306A
Authority
KR
South Korea
Prior art keywords
http
client
server
proxy
http client
Prior art date
Application number
KR1020130006959A
Other languages
English (en)
Other versions
KR102090493B1 (ko
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 KR1020130006959A priority Critical patent/KR102090493B1/ko
Priority to US14/161,115 priority patent/US9877264B2/en
Priority to ES14152111T priority patent/ES2763416T3/es
Priority to EP14152111.2A priority patent/EP2757756B1/en
Publication of KR20140094306A publication Critical patent/KR20140094306A/ko
Application granted granted Critical
Publication of KR102090493B1 publication Critical patent/KR102090493B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/122—Avoiding congestion; Recovering from congestion by diverting traffic away from congested entities
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명은 무선 통신 네트워크에서 HTTP 프로토콜의 전송 지연과 HTTP 서버의 프로세싱 부하를 줄이는 장치 및 방법에 관한 것으로, 본 발명의 무선 통신 네트워크에서 HTTP(HyperText Transfer Protocol) 프록시 장치의 무선 연결 관리 및 제어 방법은 상기 무선 통신 네트워크의 임의의 노드로부터, HTTP 통신을 수행하고 있는 HTTP 클라이언트의 무선 연결 해제 또는 상기 HTTP 클라이언트의 IP(Internet Protocol) 주소 변경에 대한 정보를 수신하는 단계, 및 상기 수신된 정보에 기반하여 HTTP 서버와의 연결을 해제 또는 유지하는 단계를 포함하는 것을 특징으로 한다.

Description

무선 통신 네트워크에서 HTTP 프로토콜의 전송 지연과 HTTP 서버의 프로세싱 부하를 줄이는 장치 및 방법{Device and method of HTTP Proxy to reduce the HTTP protocol transmission delay and the HTTP processing load in Mobile Communication Networks}
본 발명은 무선 통신 네트워크에 관한 것으로, 보다 구체적으로 무선 통신 네트워크에서 HTTP(HyperText Transfer Protocol) 프로토콜의 전송 지연과 HTTP 서버의 프로세싱 부하를 줄이는 장치 및 방법에 관한 것이다.
일반적으로 무선 통신 시스템은 사용자의 활동성을 보장하면서 음성 서비스를 제공하기 위해 개발되었다. 그러나 무선 통신 시스템은 점차로 음성뿐 아니라 데이터 서비스까지 영역을 확장하고 있으며, 현재에는 고속의 데이터 서비스를 제공할 수 있는 정도까지 발전하였다. 그러나 현재 서비스가 제공되고 있는 무선 통신 시스템에서는 자원의 부족 현상 및 사용자들이 보다 고속의 서비스를 요구하므로, 보다 발전된 무선 통신 시스템이 요구되고 있다.
일반적인 무선 통신 기술에 대한 네트워크 구조가 도 1에서 도시된다. 본 발명에서는 무선 또는 이동 통신 네트워크를 중심으로 설명하지만, 유선 통신 네트워크에 대해서도 동일하게 적용이 가능하다.
도 1에서 도시되는 바와 같이, 이동통신 단말에서 전송하는 IP(Internet Protocol) 통신 메시지는 해당 단말(110)의 IP통신을 종단하는 이동통신 장치와 연결된다. 해당 장치에 대해서, 도 1에서는 4세대 통신망인 LTE(Long Term Evolution)을 가정하여 PGW(PDN Gateway)(120)가 사용되는 것으로 설명하였다. 이후 해당 단말(110)과 인터넷의 통신장치와의 모든 IP메시지 교환은 해당 PGW(120)를 통하여 이루어 진다. 따라서, HTTP를 기반으로 하는 클라이언트 소프트웨어가 구동하는 경우에 대해서, 해당 HTTP 기반 서비스의 메시지는 모두 PGW(120)를 경유하게 된다.
기존의 기술에서 해당 PGW(120)와 HTTP 서비스를 실질적으로 제공하는 HTTP 서버(HTTP Server)(140) 사이에는 이동통신 네트워크에 보다 향상된 성능의 HTTP 서비스를 제공하기 위하여 HTTP 프록시(HTTP Proxy)(130) 장치가 사용된다. HTTP Proxy 장치(130)는 일반적으로 HTTP 트래픽에 대한 압축을 통한 전송 속도 향상, 불법적이거나 악의적인 공격으로부터의 HTTP 사용자 혹은 HTTP Server 보호 등 보안 강화, 그리고 자주 접근되는 HTTP Server의 콘텐트를 저장하였다가 HTTP 사용자에 빨리 전달하는 캐싱(caching) 등을 제공하여 HTTP 서비스의 사용자 만족도를 올리는 역할을 수행한다.
기존 기술에서의 HTTP Proxy 장치(130)의 내부 구성도가 도 2에 도시된다.
기존의 HTTP Proxy 장치(130)는 일반적으로 한쪽 방향은 HTTP Client들이 연결되고, 다른 방향으로는 HTTP Server가 연결된다. HTTP Proxy는 양쪽의 TCP 등 4계층 통신을 종단하므로, 왼쪽과 오른쪽을 매칭하는 기능을 필요로 하게 된다.
이를 위하여 HTTP Proxy(430)는 HTTP Client가 연결된 라우터(210) 방향을 위하여 라우터 트래픽 처리장치(Router Traffic Handler)(220)를 가지며, HTTP Server(140) 방향을 위하여 서버 트래픽 처리장치(Server Traffic Handler)(260)를 가지게 된다. 그리고 이들을 매칭하는 작업을 수행하는 HTTP 베어러 처리장치(HTTP Bearer Processor)(230)를 가진다. HTTP 베어러 처리장치(230)는 HTTP Client(110)들과 HTTP Server(140)와의 연결을 제대로 매칭하기 위하여, HTTP Client(110)들과의 4계층 연결 등 정보와 HTTP Server(140)와의 4계층 연결 정보 등을 HTTP 세션 데이터베이스(HTTP Session Database)(250)에 저장하며, 해당 정보를 기반으로 하여, HTTP 베어러 처리장치(230)가 HTTP Client(110)와 HTTP Server(140)와의 세션을 매칭하도록 하는 HTTP 세션 매니저(240)가 동작하도록 한다.
따라서 HTTP 세션 매니저(240)는 HTTP 세션 데이터베이스 정보(250)를 기반으로 하여, HTTP 베어러 처리장치(230)가 HTTP Client(110)와 HTTP Server(140)간의 세션을 제대로 매칭하도록 제어한다.
여기서, 상기한 종래 기술에 대한 문제점을 하기와 같이 4가지로 정의하기로 한다.
첫째로, 종래 기술에 따른 HTTP Client(110)가 하나의 전송 제어 프로토콜 (Transmission Control Protocol, TCP) 연결을 통해서 복수의 HTTP 요청(Request) 메시지들을 HTTP Server(140)에게 전송하는 경우, HTTP Server(140)는 HTTP Request들에 대한 응답인 HTTP Response 메시지들을 HTT Request들과 동일한 순서로 HTTP Client(110)에게 전송해야 한다. 이로 인한 문제점으로, HTTP Response 중 하나에 대한 생성 혹은 전송이 늦어지면, 후속 HTTP Response들은 모두 Client로의 전송 지연이 발생할 우려가 있다.
둘째로 종래 기술에서는 원래 HTTP 표준 규격에서 정의한 Persistent HTTP 모드 혹은 최근 개선된 안으로 제안되고 있는 SPDY처럼 HTTP Client(110)와 HTTP Server(140)간에 한번의 연결 접속을 가진 후, 이후의 재접속을 신속하게 수행하기 위하여 하나의 TCP세션을 오랜 기간 유지하도록 한다. 이때 HTTP Client(110)가 정상적으로 HTTP Server(140)와의 TCP연결 해제를 수행하지 못하면 스스로 알아서 해당 TCP세션을 제거해야 한다. 이로 인한 현재 기술의 문제점으로, 이동통신 네트워크에서 단말의 무선접속이 불안정하여 HTTP Client(110)와 HTTP Server(140)간의 TCP연결이 비정상적으로 종료되거나, 단말이 위치를 이동하여 핸드오버를 수행함으로써 IP주소가 바뀌면, 기존 TCP연결은 정상적으로 동작할 수 없게 되지만 HTTP Server(140)가 이를 파악하기는 어려운 문제를 가진다. 만약 해당 단말의 이동을 파악하기 위하여 HTTP Server(140)와 HTTP Client(110)에 주기적인 메시지 송수신을 하여 비정상 종료를 검출하고자 하는 경우에 대해서도 무선의 트래픽 낭비가 발생하며, HTTP Server(140)가 비정상적으로 종료된 TCP연결을 일정시간 유지하게 되면 서버의 프로세싱 부하가 불필요 하게 발생한다.
셋째로 종래 기술에서 앞서 두 번째 문제점에서 지적한 Persistent HTTP 혹은 SPDY처럼 HTTP Client(110)와 HTTP Server(140)간에 재접속을 신속하게 수행하기 위하여 하나의 TCP세션을 오랜 기간 유지하는 경우에 대해서, 해당 HTTP Client(110)가 이동통신 단말이기에 무선에서의 핸드오버로 인하여 IP주소가 바뀌는 경우는 HTTP Server(140)가 이를 알 수 없다. 이로 인한 종래 기술의 문제점으로, 이동통신 네트워크에서 단말이 이동하는 등으로 기지국을 변경하는 경우, 단말이 지금까지 사용하던 IP주소를 사용하지 못하고 변경하여야 하는 경우가 발생 가능하다. 예를 들어, 무선랜(Wireless Local Area Network: WLAN)에서 액세스포인트(Access Point: AP) 변경 시 혹은 LTE 네트워크에서 PGW 변경과 같은 경우, 해당 단말의 IP주소가 변경되면 HTTP Server(140) 와 HTTP Client(110)간의 TCP연결이 비정상적으로 종료되어, 상기 두 번째 문제점이 그대로 발생하며, 이 경우 해당 단말에 부여되었던 IP주소가 무용하게 되고, 이와 더불어 단말과의 TCP연결의 단절로 인하여 지금까지 수행하던 통신서비스는 비정상적으로 중지되게 된다.
네 번째로 현재 기술에서 앞서 두 번째와 세 번째에서 언급한 Persistent HTTP 혹은 SPDY처럼 HTTP Server(140) 가 HTTP Client(110)에게 푸쉬(Push) 메시지를 보내기 위하여 하나의 TCP세션을 오랜 기간 유지하는 경우에 대해서, 단말이 IP와 TCP세션을 HTTP Server(140)에 대해서 지속적으로 유지하고 있어야 한다. 이로 인한 현재 기술의 문제점으로, 이동통신 네트워크에서는, 단말이 더 이상 송수신할 정보가 없는 경우 무선접속을 해지하고 IP를 반납하거나, 이동통신 네트워크에서 해당 단말의 트래픽을 모니터링 하여 송수신하는 정보가 없는 경우 IP연결을 해제하도록 되어 있다. 하지만 단말의 IP가 상기의 경우처럼 해제되면 HTTP Server(140)에서는 해당 단말로의 HTTP 푸쉬(Push)가 불가능하게 되며, 이에 대한 해결책으로 주기적인 메시지를 단말에게 송신하여 연결을 유지하고자 하기도 하지만, 이를 위해서는 단말의 무선 데이터 통신 연결이 계속 유지되어야 하기에 단말의 통신 비용 부담, 배터리 사용 증가 등 문제가 있다. 또한, 이동통신 네트워크에서도 해당 단말에 IP가 지속적으로 할당됨으로 인하여, 해당 IP 세션을 유지하기 위한 프로세싱 및 메모리 부하가 발생한다.
본 발명은 상기와 같은 문제점들을 해결하기 위해 안출된 것으로, 인터넷 서비스를 제공하기 위하여 사용하는 핵심 통신 프로토콜인 HTTP(Hyper Text Transport Protocol)을 개선하는 것을 목적으로 한다.
보다 구체적으로, 본 발명은 개선된 HTTP 프로토콜을 통하여, HTTP를 기반으로 하여 만들어진 서비스의 사용자가 보다 빠른 응답시간을 경험하게 하며, HTTP 서비스를 제공하는 서버의 CPU(Central Processing Unit)/메모리의 부하(load)를 보다 적게 쓰면서도 기존 보다 개선된 서비스를 제공할 수 있는 방법 및 장치를 제공하는 것을 그 목적으로 한다. 또한, 본 발명은 무선통신 네트워크에서 HTTP 프로토콜을 사용하는 경우에는 무선단말의 무선통신이 단절된 경우에도 사용자가 HTTP 서비스를 지속적으로 받을 수 있도록 한다.
이를 위하여, 본 발명에서는 기존의 HTTP 프로토콜의 성능 개선을 위하여 사용되는 HTTP 프록시 장치의 기능을 개선하며, 이를 위하여 HTTP 프로토콜의 변경을 수행한다. 아울러, HTTP 프로토콜의 변경에 따른 HTTP Server와 HTTP Client 등의 변경을 수행하며, 추가적으로 이동통신에 특화된 HTTP 성능 개선을 위하여 기존의 이동통신 장치의 기능 개선을 수행한다.
상기와 같은 문제점을 해결하기 위한 본 발명의 해결책에 대해, 하기의 4가지 기술을 제안한다.
첫 번째 문제점의 해결을 위한 제안기술로써, HTTP Request(메시지)와 HTTP Response(메시지)에 "HTTP Sequence 번호 (혹은 HTTP Transaction 식별자)"를 새로운 필드로 포함한다. 이를 위하여, HTTP Client는 HTTP Request 전송 시에 해당 메시지를 구분할 수 있는 번호를 HTTP Sequence 필드에 기록하여 HTTP Server에 전송한다. HTTP Server는 HTTP Response를 생성시, HTTP Response에 대응하는 HTTP Request의 HTTP Sequence 번호를 포함시킨다. HTTP Server는 수신한 HTTP Request들의 순서와 상관없이 HTTP Response들을 HTTP Client에게 전달한다. HTTP Client는 전송한 HTTP Request들의 순서와 상관없이 HTTP Server로부터 수신되는 HTTP Response 메시지를 받는 대로 수신하여 응용프로그램에 전달한다.
두 번째 문제점의 해결을 위한 제안기술로써, 이동통신 네트워크의 HTTP Proxy가 단말에 IP주소를 부여하는 장비(예를 들어 LTE의 PGW)와 연계하여 단말의 IP연결 종료를 검출하고 이를 HTTP Server에 알려주도록 한다. 이를 위하여 이동통신 네트워크의 단말은 디폴트로 HTTP Proxy에 연결하여 HTTP Server와의 통신을 수행하는 경우를 가정한다. HTTP Proxy는 이동통신 단말의 IP주소를 할당하는 장치와 연결을 유지하여, 단말의 IP연결 해제 여부를 알고 있도록 한다. 단말의 정상/비정상 IP해제로 HTTP통신이 불가능한 경우, HTTP Proxy는 해당 단말과 연결된 HTTP Server에 해당 HTTP Client와의 연결해제를 단말 대신 수행한다.
세 번째 문제점의 해결을 위한 제안기술로써, 이동통신 네트워크에 존재하는 HTTP Proxy가 이동통신 단말에 IP주소를 부여하는 장비와 연계하여 단말의 IP주소 변경을 검출하고 이를 HTTP Server에 투명하게 처리한다. 이를 위하여 이동통신 네트워크의 단말은 디폴트로 HTTP Proxy에 연결하여 HTTP Server와의 통신을 수행하는 것을 가정한다. HTTP Proxy는 이동통신 단말의 IP주소를 할당하는 장치와 연결을 유지하여, 단말의 IP주소 변동 여부를 알고 있도록 한다. 단말의 IP주소가 변경되는 경우 HTTP Proxy는 해당 IP주소 변경이 HTTP Client 와 HTTP Proxy 사이에만 영향을 주도록 하고, HTTP Proxy 와 HTTP Server 사이에는 영향을 주지 않도록 하여, IP주소 변경에 따른 영향이 HTTP Client와 Server간에 발생하지 않도록 한다.
네 번째 문제점의 해결을 위한 제안기술로써, HTTP Push를 희망하는 HTTP Client 혹은 Server는 HTTP 연결 설정 시점에서 "HTTP를 지속적으로 희망”한다는 의사를 주고 받도록 한다. 상기 의사표시는 HTTP Proxy에서 인식하게 되어, 이후 단말의 IP연결이 해제되어도 HTTP Proxy 차원의 Push를 지원하도록 하게 된다. HTTP Client에 대한 무선 연결과 함께 IP주소가 해제된 후에도 HTTP Proxy는 해당 HTTP Client에 대한 세션 정보를 유지한다. 세션 정보를 유지하는 시간은 Permanent하거나, 사전에 HTTP 연결 시에 HTTP Client 혹은 HTTP Server가 정의한 시간 값을 활용한다. HTTP Client의 IP해제 후, HTTP Server에서 HTTP 메시지를 단말에게 송신 하는 경우는 HTTP Proxy에 정상적인 HTTP Push 메시지를 전송하며, HTTP Proxy는 해당 HTTP Client에게 해당 HTTP Push 메시지를 전송한다. 따라서 무선연결을 해제하여 IP주소를 갖고 있지 않은 단말에 대한 HTTP Push 전송은 HTTP Server에 투명하게 처리된다. HTTP Push를 받은 단말의 이후 동작은 여타 기존 기술에서 단말의 무선 페이징 관련 기술들에 따르는 것으로 하여 본 특허와 무관하므로 자세한 설명은 생략하기로 한다.
구체적으로, 본 발명의 무선 통신 네트워크에서 HTTP(HyperText Transfer Protocol) 프록시 장치의 무선 연결 관리 및 제어 방법은 상기 무선 통신 네트워크의 임의의 노드로부터, HTTP 통신을 수행하고 있는 HTTP 클라이언트의 무선 연결 해제 또는 상기 HTTP 클라이언트의 IP(Internet Protocol) 주소 변경에 대한 정보를 수신하는 단계, 및 상기 수신된 정보에 기반하여 HTTP 서버와의 연결을 해제 또는 유지하는 단계를 포함하는 것을 특징으로 한다.
또한, 본 발명의 무선 통신 네트워크에서 무선 연결을 관리 및 제어하는 HTTP(HyperText Transfer Protocol) 프록시 장치는 상기 무선 통신 네트워크에 위치한 임의의 노드들과 통신을 수행하는 인터페이스부, 및 상기 무선 통신 네트워크의 임의의 노드로부터, HTTP 통신을 수행하고 있는 HTTP 클라이언트의 무선 연결 해제 또는 상기 HTTP 클라이언트의 IP(Internet Protocol) 주소 변경에 대한 정보를 수신하고, 상기 수신된 정보에 기반하여 HTTP 서버와의 연결을 해제 또는 유지하도록 제어하는 제어부를 포함하는 것을 특징으로 한다.
본 발명에 따르면 상술한 각각의 문제점 대비 하기의 4가지 효과를 거둘 수 있다.
첫 번째 문제점의 해결을 통해서, HTTP Server에서 특정 HTTP Response가 지연되어 후속의 HTTP Response 전송이 늦어 지는 경우에 대해서, 지연된 HTTP Response는 천천히 보내지만 먼저 만들어진 HTTP Response들을 지연 없이 전송함으로써, HTTP Client를 사용하는 사용자가 겪는 HTTP 서비스 지연 시간을 축소하여 사용자의 만족도를 개선한다.
두 번째 문제점의 해결을 통해서, 단말이 정상적으로 HTTP Server와의 HTTP통신을 하지 못하는 경우, HTTP Server에서 해당 단말과 연결된 TCP 세션을 빠른 시간에 해제함으로써, 서버의 부하를 줄인다. 또한 HTTP Client의 정상 동작을 확인하기 위한 별도의 메시지를 HTTP Client와 HTTP Server간에 주고받지 않아도 되어, HTTP Client를 사용하는 사용자의 통신비가 절감되며, 이동통신 네트워크에서도 소량의 간헐적인 트래픽의 송수신에 따른 페이징 등의 부하를 제거할 수 있다.
세 번째 문제점의 해결을 통해서, 이동통신 네트워크에서 단말이 위치를 이동하여 IP주소의 변경이 발생하더라도 진행중인 HTTP 서비스에 영향을 주지 않아 이동과 무관한 끊김 없는(Seamless) 서비스가 가능하다.
네 번째 문제점의 해결을 통해서, 이동통신 네트워크에서 단말의 무선연결이 해제되고 IP주소가 없더라도 HTTP Server의 Push 서비스에 영향을 주지 않아 끊김 없는(Seamless) 푸쉬 서비스가 가능하다.
도 1은 일반적인 무선 통신 기술에 대한 네트워크 구조를 도시하는 도면.
도 2는 종래 기술에 따른 HTTP Proxy 장치의 내부 구조를 도시하는 도면.
도 3은 본 발명의 실시예에 따라 본 발명 지원을 위한 네트워크 구조를 도시하는 도면.
도 4는 본 발명에서 제안하기 기술을 지원하기 위한 HTTP Proxy 장치(340)의 내부 구조를 도시하는 도면.
도 5는 본 발명의 일 실시예에 따른 단일 TCP세션을 통한 HTTP 메시지의 비동기 전송의 동작 과정을 도시하는 도면.
도 6은 본 발명의 실시예에서 사용하는 각 메시지에 적용되는 데이터 베이스 구조를 도시하는 도면.
도 7은 도 5의 순서도를 통해 도시된 동작 시나리오에 대한 도 6의 데이터베이스의 관리 과정을 도시하는 도면.
도 8은 본 발명의 일 실시예에 따른 무선 통신이 해제된 단말에 대한 HTTP Server(840)로의 TCP세션 해제 동작 시나리오를 도시하는 도면.
도 9는 도 8의 동작 시나리오에 대한 HTTP Proxy가 관리하는 데이터베이스의 관리 과정을 도시하는 도면.
도 10은 본 발명의 일 실시예에 적용되는 도 6 데이터 베이스의 확장된 구조를 도시하는 도면.
도 11은 본 발명의 일 실시예에 따른 , 무선 단말의 이동에 따른 핸드 오버에 대해서, 유휴(Idle) 핸드 오버 시의 동작 시나리오를 도시하는 도면.
도 12는 도 11의 동작 시나리오에 대한 HTTP Proxy(1130)의 세션 데이터베이스에 대한 예제를 도시하는 도면.
도 13은 본 발명의 일 실시예에 따른 무선 단말의 이동에 따른 핸드 오버에 대해서, 세션 중 핸드 오버 시의 첫 번째 동작 시나리오를 도시하는 도면.
도 14는 도 13의 동작 시나리오에 대한 HTTP Proxy의 세션 데이터베이스 관리 예제를 도시하는 도면.
도 15는 본 발명의 일 실시예에 따른 무선 단말의 이동에 따른 핸드 오버에 대해서, 세션 중 핸드 오버 시의 두 번째 동작 시나리오를 도시하는 도면.
도 16은 도 15의 동작 시나리오에 대한 HTTP Proxy(1130)의 세션 데이터베이스 관리 예제를 도시하는 도면.
도 17은 본 발명의 일 실시예에 따른 무선 단말의 이동에 따른 핸드 오버에 대해서, 세션 중 핸드 오버 시의 세 번째 동작 시나리오를 도시하는 도면.
도 18은 도 17의 동작 시나리오에 대한 HTTP Proxy(1130)의 세션 데이터베이스를 관리하는 예제를 도시하는 도면.
도 19는 본 발명의 일 실시예에 따른 유휴(Idle) 단말에 대한 HTTP 푸쉬(Push) 서비스의 동작 시나리오를 도시하는 도면.
도 20은 도 19의 동작 시나리오에 대한 HTTP Proxy의 세션 데이터베이스를 관리하는 예제를 도시하는 도면.
본 발명의 실시예들을 구체적으로 설명함에 있어서 LTE(Long Term Evolution) 시스템을 주된 대상으로 예시할 것이지만, 본 발명의 주요한 요지는 유사한 기술적 배경을 가지는 여타의 통신 시스템에도 본 발명의 범위를 크게 벗어나지 아니하는 범위에서 약간의 변형으로 적용 가능하며, 이는 본 발명의 기술분야에서 숙련된 기술적 지식을 가진 자의 판단으로 가능할 것이다.
예를 들어, 본 발명의 LTE 시스템의 기지국 엔티티인 eNB, 코어 네트워크 상의 엔티티들인 PGW, MME 등이 본 발명의 실시예에 따라 수행하는 기능들은 여타의 다른 통신 시스템에 대한 임의의 엔티티(Entity)들에 의해 수행될 수도 있는 것임에 유의해야 할 것이다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예들을 상세히 설명한다. 이 때, 첨부된 도면에서 동일한 구성 요소는 가능한 동일한 부호로 나타내고 있음에 유의해야 한다. 또한 본 발명의 요지를 흐리게 할 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략할 것이다.
도 3은 본 발명의 실시예에 따라 본 발명 지원을 위한 네트워크 구조를 도시하는 도면이다.
앞서 언급한 것처럼, 본 발명은 설명의 용이성과 이동통신 네트워크에서 차별화된 추가 기술을 설명하기 위하여 이동통신 네트워크를 기반으로 설명하고 있지만, 유선통신 네트워크에서도 동일하게 적용이 가능하다.
도 3에서 도시되는 바와 같이, 본 발명에서 제안하는 HTTP Proxy 장치(340)는 기존과 다르게 이동통신 네트워크의 PGW(330)와 사용자 단말의 IP 프로토콜 정보 등을 주고 받기 위한 시그널링 인터페이스(Signaling Interface)를 가진다. 아울러, 이동통신 단말의 위치 정보를 관리하고 페이징 등을 통하여 이동통신 단말을 찾는 MME(Mobility Management Entity) 장치(320)와의 시그널링 인터페이스를 가진다.
본 발명에서 제안하기 기술을 지원하기 위한 HTTP Proxy 장치(340)의 내부 구조가 도 4에서 도시된다.
도 4에서 도시되는 바와 같이, 본 발명의 실시예에 따른 HTTP Proxy 장치(340)는 기존의 라우터 트래픽 처리장치와 유사한 장치인 PGW 트래픽 처리장치(PGW Traffic Handler)(410)가 존재한다. 라우터 트래픽 처리장치가 아닌 PGW 트래픽 처리장치로 명명한 이유는, 앞서의 세 번째와 네 번째 목적에서 정의한, 이동통신에 특화된 기능을 제공하고자 하는 목적을 위해서 이다.
아울러 HTTP Server(350)와의 통신을 위한 Server 트래픽 처리장치(Server Traffic Handler)(420)도 기존 장치와 동일하게 정의한다.
본 발명을 위하여 HTTP Proxy 장치(340)에 신규 추가되는 장치로서 PGW 시그널링 처리장치 (PGW Signal Handler)(430)는 PGW가 관리하는 무선단말의 IP프로토콜 관련 정보를 주고 받기 위한 용도로 정의된다. 예를 들어, PGW가 단말의 IP정보가 해제 혹은 변경되는 정보를 HTTP Proxy가 접근하기 위한 용도 등을 지원하기 위함이다. 즉, 해당 장치를 통하여 HTTP Proxy(340)는 PGW(330)로부터 HTTP Client 단말(310)의 무선 연결해제, IP 주소 할당, IP 변경 등의 정보를 송수신하게 된다.
UE 페이징 처리장치(UE Paging Handler)(430)는 HTTP Client 단말(310)이 IP 해제 한 경우, HTTP Push의 전송을 위한 페이징 처리 등을 위한 목적으로 정의한다. 이동통신 단말의 IP프로토콜 정보 변경을 감안하여 HTTP Client(310)와 HTTP Server(350)간의 세션 매칭을 위하여 HTTP 세션 매니저 (HTTP Session Manager)(440)는 무선 단말의 정보를 추가로 제어/관리하기 위하여 확장된다. 이를 토대로, HTTP 트래픽을 처리하기 위하여 HTTP 베어러 처리장치(HTTP Bearer Processor)(450)도 확장되며, HTTP 세션 데이터베이스 (HTTP Session Database)(460)도 추가적인 정보를 제어/관리하기 위하여 확장된다.
한편, 상기 설명 및 도 4에서는 HTTP 프록시 장치가 여러가지 구성 요소로 구비되는 실시예에 대해서 기술하였지만 반드시 이에 한정되는 것은 아니다. 예를 들어, HTTP 프록시 장치는 무선 통신 네트워크의 임의의 노드들과 통신을 수행하는 인터페이스부, 및 본 발명의 실시예에 따른 기능들을 수행하는 제어부로 구현될 수도 있는 것임에 유의해야 한다. 이 경우, 상기 제어부가 수행하는 구체적인 기능들에 대해서는 하기에서 설명될 것이다.
이하에서는 본 발명에서 제기한 네 가지 문제점을 해결하기 위한 각각의 해결 방안에 대해 구체적으로 기술하도록 한다.
우선, 본 발명에서 제공하는 첫 번째 기여기술로서, 단일 TCP세션을 통한 HTTP 메시지의 비동기 전송의 동작 시나리오 예제를 도 5를 통해 설명하도록 한다.
시퀀스에 대한 설명에 앞서, HTTP Client(310)는 IP주소 #1, HTTP Proxy(340)는 IP주소 #2, HTTP Server(350)는 IP주소 #3를 가지는 것으로 가정한다.
아울러, S5150 단계에서, HTTP Client(310)와 HTTP Proxy(340) 사이에는 HTTP Client(310)의 세션을 위한 TCP 연결이 사전에 설정되어 있는 것으로 가정하며, 이는 번호 #A를 가지는 것으로 가정한다. 더불어 HTTP Proxy(340)와 HTTP Server(350)는 해당 HTTP Client(310)의 TCP 연결을 위하여 TCP 번호 #X를 가지는 것으로 가정한다.
도 5에 도시되는, 각각의 메시지 시퀀스에 대한 설명은 다음과 같다.
우선, S520 단계에서 HTTP Client(310)가 HTTP Request #1을 HTTP Server(350)로 전송하면, 이를 HTTP Proxy(340)가 수신한다. 이어서, S530 단계에서 HTTP Client(310)가 HTTP Request #2을 HTTP Server(350)로 전송하면, 이를 HTTP Proxy(340)가 수신한다.
그러면, HTTP Proxy(340)는 상기 S520 단계의 전송에 대한 HTTP Request를 HTTP Server(350)에 보내면서, HTTP Client(310)가 보낸 HTTP Request #1에 매칭되는 새로운 번호로서 HTTP 시퀀스 넘버 #10을 결정하고, S540 단계에서 상기 결정된 HTTP 시퀀스 넘버를 삽입한 HTTP Request #10을 HTTP Server(350)로 전송한다.
이어서, HTTP Proxy(340)는 상기 S530 단계의 전송에 대한 HTTP Request를 HTTP Server(350)에 보내면서, HTTP Client(310)가 보낸 HTTP Request #2에 매칭되는 새로운 번호로서 HTTP 시퀀스 넘버 #20을 결정하고, S550 단계에서 상기 결정된 HTTP 시퀀스 넘버를 삽입한 HTTP Request #20을 HTTP Server(350)로 전송한다.
이후, S560 단계에서, HTTP Proxy(340)는 HTTP Server(350)로부터, 상기 상기 S540 단계의 응답보다 S550 단계의 응답을 먼저 수신한다. 그리고 HTTP Proxy(340)는 S570 단계에서, S540 단계의 응답을 수신한다.
그러면, HTTP Proxy(340)는 S580 단계에서, HTTP Server(350)에서 응답이 온 순서대로 상기 S560 단계의 응답을 먼저 HTTP Client(310)에게 전달한다.
이어서, HTTP Proxy(340)는 S590 단계에서, HTTP Server(350)에서 응답이 온 순서대로 상기 S570 단계의 응답을 HTTP Client(310)에게 전달한다.
상기한 도 5의 순서도에서, HTTP Proxy(340)가 왼쪽의 HTTP Client(310)와 오른쪽의 HTTP Server(350)의 세션간을 매칭하기 위하여 도 6에서 도시되는 데이터 베이스를 이용한다. HTTP Proxy(340)는 상기 도 6에서 도시되는 데이터 베이스를 HTTP 세션 데이터베이스(460)를 통해서 관리한다.
이하에서는 도 6에서 도시된 데이터베이스의 각 필드에 대하여 설명하기로 한다.
클라이언트 IP 어드레스(Client IP Address, 610)는 HTTP Client(310)의 IP주소 번호를 의미한다.
클라이언트 TCP 넘버(Client TCP Number, 620)는 HTTP Client(310)가 HTTP Proxy(340)와 통신하기 위하여 사용한 TCP 포트 번호를 의미한다.
클라이언트 HTTP 시퀀스 넘버(Client HTTP Sequence Number, 630)는 HTTP Client(310)가 HTTP Proxy(340)를 통하여 HTTP Server(350)로 전송하는 HTTP Request의 HTTP 시퀀스 번호를 의미한다.
서버 IP 어드레스(Server IP Address, 640)는 HTTP Server(350)의 IP주소 번호를 의미한다.
서버 TCP 넘버(Server TCP Number, 650)는 HTTP Proxy(340)가 HTTP Server(350)와 통신하기 위하여 사용한 TCP 포트 번호를 의미한다.
서버 HTTP 시퀀스 넘버(Server HTTP Sequence Number, 660)는 HTTP Proxy(340)가 HTTP Server(350)로 전송하는 HTTP Request의 HTTP 시퀀스 번호를 의미한다.
상태(Status, 670)는 HTTP 세션 처리 상태를 의미한다. HTTP Proxy(340)의 상태를 의미하는 Status가 ‘ReqQueued’인 경우는 HTTP Client(310)에서 HTTP Request를 수신한 상태이며, ‘Wait4Res’는 HTTP Request를 HTTP Proxy(340)로 전달한 상태, ‘ResQueued’는 HTTP Proxy(340)에서 HTTP Response를 수신한 상태, ‘Closed’는 HTTP Client(310)에게 HTTP Response를 전달하여 HTTP Session을 종료한 상태를 의미한다.
도 5의 순서도를 통해 도시된 동작 시나리오에 대한 도 6의 데이터베이스의 관리 과정이 도 7을 통해 도시된다.
도 7을 설명함에 있어, 도 5에서 도시되는 A, B, C, D 각 지점에서의 데이터베이스 관리 상태를 설명하기로 한다.
우선, A 단계에서는 HTTP Client(310)로부터, TCP #A를 통해서, HTTP Server(350)의 IP가 #3로 해서, 각각 HTTP Sequence 번호가 #1이고 #2인 HTTP Request 가 HTTP Proxy에 도착하였다. 그리고 해당 HTTP Server(350)는 현재 HTTP Proxy(340)와 TCP #X를 통해서 연결되어 있다.
하지만, 아직 해당 메시지가 HTTP Proxy(340)에서 HTTP Server(350)로 전달되지 않아서, HTTP Server(350)로의 HTTP 시퀀스 는 할당되어 있지 않다.
B 단계에서는 상기 A단계의 HTTP Request가 각각 HTTP 시퀀스 넘버 #10과 #20에 매칭되어 HTTP Server(350)로 전달된다.
이후 HTTP Server(350)로부터 HTTP Response가 도착하면, C 단계와 같이 HTTP Proxy(340)에서 해당 세션의 상태를 ‘ResQeueued’로만 바꾸고, 다른 정보는 변경하지 않는다.
이후 해당 HTTP Response를 각각 HTTP Sequence #1과 #2로 HTTP Client(310)에게 전달하게 되면, D 단계에서와 같이 HTTP Proxy(340)에서 해당 세션은 Closed 상태로 전환된다.
본 발명에서 제공하는 두 번째 기여기술로서, 무선 통신이 해제된 단말에 대한 HTTP Server(840)로의 TCP세션 해제 동작 시나리오가 도 8에서 도시된다.
도 8에 도시된 각 메시지의 송수신 절차에 대해 기술하면 하기와 같다.
우선, S810 단계에서, HTTP Client(810)가 구동중인 단말에서 정상 또는 비정상적으로 무선 연결이 해제된 것을 이동통신의 IP할당 장치의 예인 PGW(820)가 수신한다. 도 8에서는 본 발명의 실시예에 따른 기능을 수행하는 PGW를 개선된 PGW(Evoloved PGW)라고 칭할 수 있다.
그러면, PGW(820)는 S820 단계에서, HTTP Client가 구동중인 단말이 사용하던 IP#0가 더 이상 해당 단말에 할당되지 않고 회수 될 것이므로 HTTP Proxy(830)에게 알려준다.
HTTP Proxy(830)는 HTTP Client(810)가 구동하던 단말의 IP가 더 이상 유효하지 않다는 정보를 내부적으로 기록하고, S830 단계에서 해당 HTTP Client(810)가 사용하던 HTTP Server(840)와의 TCP연결을 해제한다.
두 번째 기여기술을 위해서 도 6의 상태(Status) 종류에 ‘AirClosed’가 추가된다. 상기 AirClosed’ 상태는 HTTP Client의 IP가 해제되고 HTTP Server와의 TCP도 해제한 상태로 정의될 수 있다.
도 9는 도 8의 동작 시나리오에 대한 HTTP Proxy가 관리하는 데이터베이스의 관리 과정을 도시하는 도면이다.
도 9를 설명함에 있어, 도 8에서 도시되는 A, B 각 지점에서의 데이터베이스 관리 상태를 설명하기로 한다.
우선, A 단계에서는 도 9에서 도시되는 바와 같이, HTTP Client(810)와 HTTP Server(840)간의 세션 정보가 저장된다.
그러나, 무선 단말의 무선 접속이 종료되면, 해당 무선 단말의 모든 IP프로토콜 정보가 없어지고, 관련 TCP 연결 정보도 모두 없어진 후, B단계와 같이 모든 정보가 제거된다.
이어서, 본 발명의 세 번째와 네 번째 기여기술을 위하여 도 6에 도시된 데이터베이스 구조를 확장하여, 도 10에서와 같이 정의한다.
도 6에 도시되는 데이터베이스를 기준으로, 추가된 필드는 UE (User Equipment) ID (Identifier) 필드이다. 상기 UE ID 필드는 단말을 무선통신 네트워크에서 식별 할 수 있는 식별자로서, 예를 들면 MAC주소, IMEI(International Machine Equipment Identifier) 등을 사용할 수 있다.
본 발명에서 제공하는 세 번째 기여기술에서, 무선 단말의 이동에 따른 핸드 오버에 대해서, 유휴(Idle) 핸드 오버시의 동작 시나리오가 도 11에 도시된다.
도 11에 도시된 각각의 메시지 송수신 과정에 대해 설명하면 하기와 같다.
우선, S1110 단계에서, HTTP Client(1110)는 IP#0를 사용하여 HTTP 통신을 수행하고 있다.
그러던 중, S1120 단계에서 HTTP Client(1110)가 설치된 단말이 위치 이동을 하여 IP주소를 변경하게 되며, 이때 종래 IP#0 대신 신규 IP#9를 사용하게 되었음을 가정한다.
그러면, PGW(1120)는 S1130 단계에서, 해당 단말의 IP주소 변경 여부를 HTTP Proxy(1130)에게 전달한다. 이때 HTTP Proxy(1130)는 자신의 HTTP 세션 관리 테이블에 해당 단말의 IP주소 정보를 갱신한다.
그리고, S1140 단계에서, HTTP Proxy(1130)는 HTTP Client(1110)와의 사이에 새롭게 TCP세션을 설정한다. 이때 HTTP Proxy(1130)는 상기 설정된 정보 및 종래 정보를 그대로 활용하여, HTTP Server(1140)가 단말의 IP정보 변경에 대한 사항을 모르는 상태로 유지되도록 한다.
도 12는 도 11의 동작 시나리오에 대한 HTTP Proxy(1130)의 세션 데이터베이스에 대한 예제를 도시하는 도면이다.
도 12를 설명함에 있어, 도 11에서 도시되는 A, B 각 지점에서의 데이터베이스 관리 상태를 설명하기로 한다.
우선, A 단계에서 HTTP Client(1110)는 UE ID가 0x1004이고, HTTP Client(1110)의 IP주소는 #0이다. 그리고 HTTP Client(1110)와 HTTP Proxy(1130)는 TCP 번호 #B를 가지는 것으로 가정한다.
그러던 중, HTTP Client(1110)가 핸드 오버를 하면, B 단계에서 HTTP Client(1110)의 IP주소가 #9로 바뀌고, HTTP Client(1110)와 HTTP Proxy(1130)간의 TCP 번호는 #C로 변경된 것을 알 수 있다.
하지만, HTTP Server(1140)는 핸드오버 사실을 알지 못하며, 따라서 HTTP Server(1140)에 대한 정보는 변경되지 않는 것을 볼 수 있다.
본 발명에서 제공하는 세 번째 기여기술에서, 무선 단말의 이동에 따른 핸드 오버에 대해서, 세션 중 핸드 오버 시의 첫 번째 동작 시나리오가 도 13에서 도시된다.
도 13에서 도시되는 각각의 메시지 송수신 과정에 대한 설명은 하기와 같다.
S1310 단계에서, HTTP Client(1110)는 IP#0를 사용하여 HTTP Request를 HTTP Proxy(1130)에게 전달한다. 그러면 HTTP Proxy(1130)는 S1320 단계에서, Client에서 수신한 HTTP Request를 HTTP Server(1140)로 전달한다.
그러던 중, S1330(3) HTTP Client(1110)가 있는 단말이 위치 이동을 하여 IP주소를 변경하게 되며, 이 때 기존)IP#0 대신 신규)IP#9를 사용하게 되었다고 가정한다.
그러면 PGW(1120)는 S1340 단계에서 해당 단말의 IP주소 변경 여부를 HTTP Proxy(1130)에게 전달한다. 이때 HTTP Proxy(1130)는 본인의 HTTP 세션 관리 테이블에 이동 단말의 IP주소 정보를 갱신한다.
그러면, HTTP Proxy(1130)는 HTTP Client(1110)와 HTTP Proxy(1130) 사이에 새롭게 TCP세션을 설정하며, 이때 상기 S1340 단계의 정보를 그대로 활용하여, HTTP Server(1140)가 단말의 IP정보 변경에 대한 사항을 모르는 상태로 유지되도록 한다.
이 후, S1360 단계에서, HTTP Server(1140)로부터 상기 S1320 단계의 응답으로 HTTP Response가 HTTP Proxy(1130)에 도착한다. 그러면, S1370 단계에서, HTTP Proxy(1130)는 상기 응답을 신규한 상기 S1350 단계의 TCP 연결에 기반하여 HTTP 클라이언트(1110)에 전달한다.
도 14는 도 13의 동작 시나리오에 대한 HTTP Proxy의 세션 데이터베이스 관리 예제를 도시하는 도면이다.
도 14를 설명함에 있어, 도 13에서 도시되는 A, B, C, D 각 지점에서의 데이터베이스 관리 상태를 설명하기로 한다.
우선, A 단계에서 HTTP Client(1110)는 IP주소를 #0을 사용하며, HTTP Client(1110)와 HTTP Proxy(1130)와의 TCP 연결은 #B를 사용하고 있다.
B 단계에는 HTTP Client(1110)의 IP주소는 #9로 변경되었으나, 아직 TCP 연결은 HTTP Client(1110)와 HTTP Proxy(1130) 사이에 설정되지 않았기에 빈칸으로 되어 있다.
C 단계에서는 HTTP Client(1110)와 HTTP Proxy(1130) 사이에 TCP 연결이 새롭게 설정되어 데이터베이스에 TCP 번호가 #C로 변경된 것을 확인할 수 있다. 특히 A, B, C단계는 HTTP Server(1140)에 HTTP Request가 전송되었으나, 아직 HTTP Response는 오지 않은 관계로 상태(Status)는 ‘Wait4Res’를 유지한다.
D 단계에서는 HTTP Response가 HTTP Server(1140)에서 수신되어 HTTP Client(1110)에게 전달된 후, ‘Closed’로 상태가 변경된다.
본 발명에서 제공하는 세 번째 기여기술에서, 무선 단말의 이동에 따른 핸드 오버에 대해서, 세션 중 핸드 오버 시의 두 번째 동작 시나리오가 도 15에서 도시된다.
도 15에서 도시되는 각각의 메시지 송수신 과정에 대한 설명은 하기와 같다.
우선, S1510 단계에서, HTTP Client(1110)는 IP#0를 사용하여 HTTP Request를 HTTP Proxy(1130)에게 전달한다. 그러면, HTTP Proxy(1130)는 S1520 단계에서, HTTP Client(1110)로부터 수신한 HTTP Request를 HTTP Server(1140)로 전달한다.
이 후, S1530 단계에서, HTTP Client(1110)가 있는 단말이 위치 이동을 하여 IP주소를 변경하게 되며, 이때 기존)IP#0 대신 신규)IP#9를 사용하게 된다. 그러면, PGW(1120)는 S1540 단계에서 해당 단말의 IP주소 변경 여부를 HTTP Proxy(1130)에게 전달한다. 이때 HTTP Proxy(1130)는 본인의 HTTP 세션 관리 테이블에 이동 단말의 IP주소 정보를 갱신한다.
한편, S1550 단계에서, HTTP Server(1140)로부터 상기 S1520 단계의 응답으로 HTTP Response가 HTTP Proxy(1130)에 도착 후 대기 상태로 저장된다.
그러면, HTTP Proxy(1130)는 S1560 단계에서, HTTP Client(1110)와 HTTP Proxy(1130) 사이에 새롭게 TCP세션을 설정하며, 이때 상기 S1540의 정보를 그대로 활용하여, HTTP Server(1140)가 단말의 IP정보 변경에 대한 사항을 모르는 상태로 유지되도록 한다.
이후, HTTP Proxy(1130)는 S1570 단계에서, 상기 S1550 단계의 응답을 상기 신규 설정된 TCP연결에 기반하여 HTTP Client(1110)에게 전달한다.
도 16은 도 15의 동작 시나리오에 대한 HTTP Proxy(1130)의 세션 데이터베이스 관리 예제를 도시하는 도면이다.
도 16을 설명함에 있어, 도 15에서 도시되는 A, B, C, D 각 지점에서의 데이터베이스 관리 상태를 설명하기로 한다.
A 단계에서, HTTP Client(1110)는 IP주소를 #0을 사용하며, HTTP Client(1110)와 HTTP Proxy(1130)와의 TCP 연결은 #B를 사용하고 있다.
B 단계에서, HTTP Client(1110)의 IP주소는 #9로 변경되었으나, 아직 TCP 연결은 HTTP Client(1110)와 HTTP Proxy(1130) 사이에 설정되지 않았기에 빈칸으로 되어 있다.
C 단계에서, HTTP Client(1110)와 HTTP Proxy(1130)에 간에 TCP 연결이 새롭게 설정되어 데이터베이스에 TCP 번호가 #C로 변경된 것을 볼 수 있다. 특히 A, B 단계는 HTTP Server(1140)에 HTTP Request가 전송되었으나, 아직 HTTP Response는 오지 않은 관계로 상태(Status)는 ‘Wait4Res’를 유지한다.
C 단계에서, HTTP Response가 도착하였으나, TCP연결이 아직 HTTP Client(1110)와 HTTP Proxy(1130) 사이에 설정되지 않은 관계로, HTTP Response가 HTTP Proxy에 저장되어 있게 되며, 따라서 HTTP 세션의 상태는 ‘ResQueued’로 변경된다.
D 단계에서는 HTTP Response가 HTTP Server에서 수신되어 HTTP Client(1110)에게 전달된 후, ‘Closed’로 상태가 변경된다.
본 발명에서 제공하는 세 번째 기여 기술에서, 무선 단말의 이동에 따른 핸드 오버에 대해서, 세션 중 핸드 오버 시의 세 번째 동작 시나리오가 도 17에서 도시된다.
도 17에서 도시되는 각각의 메시지 송수신 과정에 대한 설명은 하기와 같다.
우선, HTTP Client(1110)는 S1710 단계에서, IP#0를 사용하여 HTTP Request를 HTTP Proxy(1130)에게 전달한다. 그러면, HTTP Proxy(1130)는 S1720 단계에서, HTTP Client(1110)로부터 수신한 HTTP Request를 HTTP Server(1140)로 전달한다.
이 후, S1730 단계에서, HTTP Server(1140)로부터 상기 S1720 단계의 응답으로 HTTP Response가 HTTP Proxy(1130)에 도착 후 전송 대기 상태로 저장된다.
이 후, HTTP Client(1110)가 있는 단말이 위치 이동을 하여 IP주소를 변경하게 되며, 이때 기존)IP#0 대신 신규)IP#9를 사용하게 된다.
그러면, PGW(1120)는 S1750 단계에서 해당 단말의 IP주소 변경 여부를 HTTP Proxy(1130)에게 전달한다. 이때 HTTP Proxy(1130)는 본인의 HTTP 세션 관리 테이블에 이동 단말의 IP주소 정보를 갱신한다.
이후, HTTP Proxy(1130)는 HTTP Client(1110)와 HTTP Proxy(1130) 사이에 새롭게 TCP세션을 설정하며, 이때 상기 S1750 의 정보를 그대로 활용하여, HTTP Server(1140)가 단말의 IP정보 변경에 대한 사항을 모르는 상태로 유지되도록 한다.
이 후, 상기 S1730의 응답을 상기의 신규 설정된 TCP연결에 기반하여 HTTP Client(1110)에게 전달한다.
도 18은 도 17의 동작 시나리오에 대한 HTTP Proxy(1130)의 세션 데이터베이스를 관리하는 예제를 도시하는 도면이다.
도 18을 설명함에 있어, 도 17에서 도시되는 A, B 각 지점에서의 데이터베이스 관리 상태를 설명하기로 한다.
우선, A 단계에서 HTTP Client는 IP주소를 #0을 사용하며, HTTP Client(1110)와 HTTP Proxy(1130)와의 TCP 연결은 #B를 사용하고 있다.
B 단계에서는 HTTP Response가 HTTP Server(1140)로부터 수신되어 HTTP Client(1110)에게 전달된 후, ‘Closed’로 상태가 변경된다. 더불어 HTTP Client(1110)의 IP주소가 #9로 바뀌고, TCP 번호도 #C로 변경된 것을 확인할 수 있다.
본 발명에서 제공하는 네 번째 기여기술로서, 유휴(Idle) 단말에 대한 HTTP 푸쉬(Push) 서비스의 동작 시나리오가 도 19에서 도시된다.
도 19에 도시된 각 메시지의 송수신 절차에 대해 기술하면 하기와 같다.
우선, S1910 단계에서, HTTP Client(1910)가 동작 중인 단말이 무선 채널을 해제하면서 IP 주소를 반납한다. 그러나 HTTP Client (혹은 HTTP Server)는 사전에 또는 연결 해제 시점에서 HTTP Push를 지원하고 싶다고 요청한다.
그러면, 상기의 HTTP PUSH 서비스 지원 요청을 HTTP Proxy(1930)가 PGW(1920)로부터 수신하여 상태 정보로 보관한다. 이때 HTTP Proxy(1930)와 HTTP Server(1940)는 SPDY 프로토콜을 사용하는 것으로 가정한다.
이 후, S1930 단계에서, HTTP 서버(1940)에서 IP가 없는 단말에 대한 HTTP Push 전송 요청을 HTTP Proxy로 전송한다. 그러면, HTTP Proxy(1930)는 S1940 단계에서, PGW(1920)에 단말 페이징을 요청하며, 이때 상기 S1920 단계에서 보관하고 있는 단말의 식별자(UE ID)를 사용하여 PGW(1920)에 단말을 찾아줄 것을 요청한다.
이후, S1960 단계 내지 S1990 단계는 종래 이동 통신 시스템에서의 페이징 절차를 사용하여, 유휴(Idle) 상태의 단말이 무선 페이징을 통해서, 다시 새로운 IP#9와 새로운 TCP 연결 #C를 획득하게 되는 과정을 도시한다.
이후, S19950 단계에서, HTTP Proxy(1930)는 HTTP 서버(1940)로부터 전달받은 메시지를 HTTP Client(1910)에게 전달한다.
도 20은 도 19의 동작 시나리오에 대한 HTTP Proxy의 세션 데이터베이스를 관리하는 예제를 도시하는 도면이다.
우선, A 단계에서는 HTTP Client(1910)가 동작하는 이동 단말이 정상적으로 통신을 수행하고 있기에, 데이터베이스의 모든 필드가 채워져 있는 것을 볼 수 있다.
그러나 B 단계에서는 이동 단말이 무선접속을 해제함으로써, HTTP Client(1910) 방향의 모든 필드는 비워져 있는 것을 볼 수 있다. 하지만, 이 경우 HTTP Client(1910)가 무선 접속을 해제하면서 HTTP Push를 요청하는 정보를 HTTP Proxy(1930)에게 전달하였기에 HTTP Proxy(1930)는 HTTP Server(1940) 방향의 통신은 유지한다. 이와 동시에, HTTP Proxy(1930)는 HTTP Server 정보는 제거하지 않고, 해당 HTTP 세션의 상태를 ‘PushEnable’로 변경한다.
C 단계는 이동 단말의 무선 접속과 IP 통신이 해제된 상태에서 해당 단말로의 HTTP Push가 수신된 상태이다. 이때 세션의 상태는 ‘Wait4Push’로 변경된다.
D 단계는 HTTP Push를 위하여 무선 접속이 새롭게 복원된 상태를 의미하며, 따라서 HTTP Client(1910)의 모든 정보가 다시 새로운 정보로 업데이트된 것을 볼 수 있다.
본 명세서와 도면에 개시된 본 발명의 실시예들은 본 발명의 기술 내용을 쉽게 설명하고 본 발명의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시예들 이외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.

Claims (20)

  1. 무선 통신 네트워크에서 HTTP(HyperText Transfer Protocol) 프록시 장치의 무선 연결 관리 및 제어 방법에 있어서,
    상기 무선 통신 네트워크의 임의의 노드로부터, HTTP 통신을 수행하고 있는 HTTP 클라이언트의 무선 연결 해제 또는 상기 HTTP 클라이언트의 IP(Internet Protocol) 주소 변경에 대한 정보를 수신하는 단계; 및
    상기 수신된 정보에 기반하여 HTTP 서버와의 연결을 해제 또는 유지하는 단계를 포함하는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  2. 제1항에 있어서,
    상기 HTTP 프록시 장치가 상기 무선 통신 네트워크의 임의의 노드들과 송수신하는 메시지에는, 메시지 송신 순서에 따라 HTTP 시퀀스 넘버가 설정되는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  3. 제1항에 있어서,
    상기 HTTP 프록시 장치가 HTTP 클라이언트의 무선 연결 해제에 대한 정보를 수신한 경우, 상기 HTTP 클라이언트가 사용하던 상기 HTTP 서버와의 TCP(Transmission Control Protocol) 연결을 해제하는 단계를 더 포함하는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  4. 제1항에 있어서,
    상기 HTTP 프록시 장치가 HTTP 클라이언트의 IP 주소 변경에 대한 정보를 수신한 경우, HTTP 세션 관리 테이블에 상기 HTTP 클라이언트의 IP 주소 정보를 갱신하는 단계; 및
    상기 HTTP 클라이언트와 신규 TCP 연결을 설정하는 단계를 더 포함하는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  5. 제4항에 있어서,
    상기 HTTP 서버가 상기 HTTP 클라이언트로 전송하는 메시지를 수신하는 단계; 및
    상기 신규 설정된 TCP 연결에 기반하여 상기 HTTP 서버로부터 수신한 메시지를 상기 HTTP 클라이언트로 전송하는 단계를 더 포함하는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  6. 제4항에 있어서,
    상기 HTTP 클라이언트의 IP 주소 변경에 대한 정보는 상기 HTTP 서버에 전달되지 않는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  7. 제1항에 있어서,
    상기 HTTP 프록시 장치가 HTTP 클라이언트의 무선 연결 해제에 대한 정보를 수신하는 경우, 상기 HTTP 클라이언트로부터 HTTP 푸쉬 서비스 지원 요청을 수신하는 단계를 더 포함하는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  8. 제7항에 있어서,
    상기 HTTP 서버로부터 IP 주소를 구비하지 않은 HTTP 클라이언트에 대한 HTTP 푸쉬 전송 요청을 수신하는 단계; 및
    상기 임의의 노드에 상기 HTTP 클라이언트에 대한 페이징을 요청하고, 상기 HTTP 클라이언트에 대한 신규 IP 주소 및 TCP 연결을 설정하는 단계를 더 포함하는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  9. 제7항에 있어서,
    상기 HTTP 클라이언트의 무선 연결 해제 시, 상기 HTTP 서버와의 연결은 유지하는 단계를 더 포함하는 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  10. 제1항에 있어서, 상기 임의의 노드는,
    PGW(PDN Gateway)인 것을 특징으로 하는 HTTP 프록시 장치의 무선 연결 관리 및 제어 방법.
  11. 무선 통신 네트워크에서 무선 연결을 관리 및 제어하는 HTTP(HyperText Transfer Protocol) 프록시 장치에 있어서,
    상기 무선 통신 네트워크에 위치한 임의의 노드들과 통신을 수행하는 인터페이스부; 및
    상기 무선 통신 네트워크의 임의의 노드로부터, HTTP 통신을 수행하고 있는 HTTP 클라이언트의 무선 연결 해제 또는 상기 HTTP 클라이언트의 IP(Internet Protocol) 주소 변경에 대한 정보를 수신하고, 상기 수신된 정보에 기반하여 HTTP 서버와의 연결을 해제 또는 유지하도록 제어하는 제어부를 포함하는 것을 특징으로 하는 HTTP 프록시 장치.
  12. 제11항에 있어서,
    상기 HTTP 프록시 장치가 상기 무선 통신 네트워크의 임의의 노드들과 송수신하는 메시지에는, 메시지 송신 순서에 따라 HTTP 시퀀스 넘버가 설정되는 것을 특징으로 하는 HTTP 프록시 장치.
  13. 제11항에 있어서, 상기 제어부는,
    상기 HTTP 프록시 장치가 HTTP 클라이언트의 무선 연결 해제에 대한 정보를 수신한 경우, 상기 HTTP 클라이언트가 사용하던 상기 HTTP 서버와의 TCP(Transmission Control Protocol) 연결을 해제하도록 제어하는 것을 특징으로 하는 HTTP 프록시 장치.
  14. 제11항에 있어서, 상기 제어부는,
    상기 HTTP 프록시 장치가 HTTP 클라이언트의 IP 주소 변경에 대한 정보를 수신한 경우 HTTP 세션 관리 테이블에 상기 HTTP 클라이언트의 IP 주소 정보를 갱신하고, 상기 HTTP 클라이언트와 신규 TCP 연결을 설정하도록 제어하는 것을 특징으로 하는 HTTP 프록시 장치.
  15. 제14항에 있어서, 상기 제어부는,
    상기 HTTP 서버가 상기 HTTP 클라이언트로 전송하는 메시지 수신 시, 상기 신규 설정된 TCP 연결에 기반하여 상기 HTTP 서버로부터 수신한 메시지를 상기 HTTP 클라이언트로 전송하도록 제어하는 것을 특징으로 하는 HTTP 프록시 장치.
  16. 제14항에 있어서, 상기 제어부는,
    상기 HTTP 클라이언트의 IP 주소 변경에 대한 정보는 상기 HTTP 서버에 전달되지 않도록 제어하는 것을 특징으로 하는 HTTP 프록시 장치.
  17. 제11항에 있어서, 상기 제어부는,
    상기 HTTP 프록시 장치가 HTTP 클라이언트의 무선 연결 해제에 대한 정보를 수신하는 경우, 상기 HTTP 클라이언트로부터 HTTP 푸쉬 서비스 지원 요청을 수신하는 것을 특징으로 하는 HTTP 프록시 장치.
  18. 제17항에 있어서, 상기 제어부는,
    상기 HTTP 서버로부터 IP 주소를 구비하지 않은 HTTP 클라이언트에 대한 HTTP 푸쉬 전송 요청 수신 시, 상기 임의의 노드에 상기 HTTP 클라이언트에 대한 페이징을 요청하고, 상기 HTTP 클라이언트에 대한 신규 IP 주소 및 TCP 연결을 설정하도록 제어하는 것을 특징으로 하는 HTTP 프록시 장치.
  19. 제17항에 있어서, 상기 제어부는,
    상기 HTTP 클라이언트의 무선 연결 해제 시, 상기 HTTP 서버와의 연결은 유지하도록 제어하는 것을 특징으로 하는 HTTP 프록시 장치.
  20. 제11항에 있어서,
    상기 임의의 노드는,
    PGW(PDN Gateway)인 것을 특징으로 하는 HTTP 프록시 장치.
KR1020130006959A 2013-01-22 2013-01-22 무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법 KR102090493B1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020130006959A KR102090493B1 (ko) 2013-01-22 2013-01-22 무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법
US14/161,115 US9877264B2 (en) 2013-01-22 2014-01-22 Apparatus and method for reducing transmission delay of HTTP protocol and processing load of HTTP server in wireless communications network
ES14152111T ES2763416T3 (es) 2013-01-22 2014-01-22 Aparato y procedimiento para reducir el retraso de transmisión del protocolo HTTP y la carga de procesamiento del servidor HTTP en la red de comunicaciones inalámbricas
EP14152111.2A EP2757756B1 (en) 2013-01-22 2014-01-22 Apparatus and method for reducing transmission delay of HTTP protocol and processing load of HTTP server in wireless communications network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020130006959A KR102090493B1 (ko) 2013-01-22 2013-01-22 무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법

Publications (2)

Publication Number Publication Date
KR20140094306A true KR20140094306A (ko) 2014-07-30
KR102090493B1 KR102090493B1 (ko) 2020-03-18

Family

ID=50028782

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020130006959A KR102090493B1 (ko) 2013-01-22 2013-01-22 무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법

Country Status (4)

Country Link
US (1) US9877264B2 (ko)
EP (1) EP2757756B1 (ko)
KR (1) KR102090493B1 (ko)
ES (1) ES2763416T3 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8099764B2 (en) * 2007-12-17 2012-01-17 Microsoft Corporation Secure push and status communication between client and server
US11956204B1 (en) * 2022-12-23 2024-04-09 Plume Design, Inc. IPv4-in-IPv6 relaying systems and methods to preserve IPv4 public addresses

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010096151A (ko) * 2000-04-17 2001-11-07 이상철 무선 인터넷 연결 유지 시스템 및 그 방법
US20030218996A1 (en) * 2001-07-24 2003-11-27 Hiromitsu Sumino Connection cutting method and associated link cut reporting method
US6877036B1 (en) * 1999-09-24 2005-04-05 Akamba Corporation System and method for managing connections between a client and a server
US20110075675A1 (en) * 2009-09-26 2011-03-31 Rajeev Koodli Providing services at a communication network edge
US20110119357A1 (en) * 2006-12-08 2011-05-19 Fredrik Lindholm Methods and Apparatuses for Terminating an IP Multimedia Subsystem Service When IP Address is No Longer Allocated to the User
US20110137973A1 (en) * 2009-12-07 2011-06-09 Yottaa Inc System and method for website performance optimization and internet traffic processing
WO2012125467A1 (en) * 2011-03-11 2012-09-20 Qualcomm Incorporated Remote access and administration of device content and configuration using http protocol

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6857009B1 (en) * 1999-10-22 2005-02-15 Nomadix, Inc. System and method for network access without reconfiguration
US7003799B2 (en) * 2001-01-30 2006-02-21 Hewlett-Packard Development Company, L.P. Secure routable file upload/download across the internet
EP1891822B1 (en) * 2005-06-11 2010-03-31 Telefonaktiebolaget LM Ericsson (publ) Apparatus and method for selecting a visited network
WO2007096555A2 (fr) * 2006-02-24 2007-08-30 France Telecom Procede de gestion de charge d'un serveur
CN101682724A (zh) * 2007-05-21 2010-03-24 汤姆逊许可公司 产生电子服务指南的方法和设备
US20110219135A1 (en) * 2008-11-26 2011-09-08 Takeaki Minamizawa Information processing device, communication address providing system, method and program used for same
US8213915B1 (en) 2009-02-12 2012-07-03 Sprint Communications Company, L.P. HTTP session management
US8467768B2 (en) * 2009-02-17 2013-06-18 Lookout, Inc. System and method for remotely securing or recovering a mobile device
US8984164B2 (en) * 2010-11-09 2015-03-17 Usablenet Inc. Methods for reducing latency in network connections and systems thereof
EP2661863B1 (en) * 2011-01-04 2016-07-20 Thomson Licensing Apparatus and method for transmitting live media content
US9344514B2 (en) * 2011-10-26 2016-05-17 Viagenie Method and proxy for transporting IP payloads over a delay-tolerant network (DTN)
US10397294B2 (en) * 2011-12-15 2019-08-27 Dolby Laboratories Licensing Corporation Bandwidth adaptation for dynamic adaptive transferring of multimedia

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6877036B1 (en) * 1999-09-24 2005-04-05 Akamba Corporation System and method for managing connections between a client and a server
KR20010096151A (ko) * 2000-04-17 2001-11-07 이상철 무선 인터넷 연결 유지 시스템 및 그 방법
US20030218996A1 (en) * 2001-07-24 2003-11-27 Hiromitsu Sumino Connection cutting method and associated link cut reporting method
US20110119357A1 (en) * 2006-12-08 2011-05-19 Fredrik Lindholm Methods and Apparatuses for Terminating an IP Multimedia Subsystem Service When IP Address is No Longer Allocated to the User
US20110075675A1 (en) * 2009-09-26 2011-03-31 Rajeev Koodli Providing services at a communication network edge
US20110137973A1 (en) * 2009-12-07 2011-06-09 Yottaa Inc System and method for website performance optimization and internet traffic processing
WO2012125467A1 (en) * 2011-03-11 2012-09-20 Qualcomm Incorporated Remote access and administration of device content and configuration using http protocol

Also Published As

Publication number Publication date
EP2757756A1 (en) 2014-07-23
ES2763416T3 (es) 2020-05-28
EP2757756B1 (en) 2019-11-27
KR102090493B1 (ko) 2020-03-18
US20140207960A1 (en) 2014-07-24
US9877264B2 (en) 2018-01-23

Similar Documents

Publication Publication Date Title
CN109792663B (zh) 使用隧道协议服务移动通信设备的方法和装置
US8104081B2 (en) IP security with seamless roaming and load balancing
KR102056416B1 (ko) 무선 네트워크에서 디바이스들 간의 터널 다이렉트 링크 설정(tdls) 세션을 확립하는 방법들 및 장치들
EP2514159B1 (en) Method and apparatus for multipath communication
US8175091B2 (en) Communication system
US20160080529A1 (en) Method and device for sending requests
US10630530B2 (en) Cache method, cache edge server, cache core server, and cache system
WO2018099291A1 (zh) 数据传输方法、装置及系统、存储介质
JP2020532204A (ja) トラフィックオフロード方法およびローミングシナリオにおける関連するデバイス
JP2008028996A (ja) 通信システム、通信方法、およびプログラム
JP2019536355A (ja) ノードタイプに基づくデータストリーミングの支援制御
WO2019096306A1 (zh) 一种处理请求的方法以及相应实体
JP2023516037A (ja) エッジコンピューティングのための分散アンカーのアプリケーショントリガセットアップ
WO2022033346A1 (zh) 网络切片管理系统、应用服务器和终端设备
WO2018113504A1 (zh) 一种用户面锚点选择方法及装置
KR20180051621A (ko) 전기통신 네트워크와 적어도 하나의 사용자 장비 간의 적어도 하나의 통신 교환의 개선된 핸들링을 위한 방법, 전기통신 네트워크, 사용자 장비, 시스템, 프로그램 및 컴퓨터 프로그램 제품
EP2919509B1 (en) Method and device for hosting application by access node
KR102090493B1 (ko) 무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법
JP4806364B2 (ja) ルータ切替方法、およびルータ装置
US20190037025A1 (en) Transmission control protocol (tcp) synchronize (syn) signaling passthrough for tcp proxy servers
CN114071790B (zh) 通信方法、装置、设备及存储介质
CN111405615B (zh) 一种通信数据的传输方法、装置及存储介质
CN109788520A (zh) 网络切换方法、amf和ran节点
JP6251210B2 (ja) 端末装置、通信セッション確立方法、及び、プログラム
EP3107352B1 (en) Information transfer method, system and apparatus

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant