KR102036579B1 - 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치 - Google Patents

무선 통신 시스템에서 웹 서비스 제공 방법 및 장치 Download PDF

Info

Publication number
KR102036579B1
KR102036579B1 KR1020120126859A KR20120126859A KR102036579B1 KR 102036579 B1 KR102036579 B1 KR 102036579B1 KR 1020120126859 A KR1020120126859 A KR 1020120126859A KR 20120126859 A KR20120126859 A KR 20120126859A KR 102036579 B1 KR102036579 B1 KR 102036579B1
Authority
KR
South Korea
Prior art keywords
mobile terminal
proxy cache
drx
embedded object
receiving
Prior art date
Application number
KR1020120126859A
Other languages
English (en)
Other versions
KR20140060132A (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 KR1020120126859A priority Critical patent/KR102036579B1/ko
Priority to EP13853403.7A priority patent/EP2918138B1/en
Priority to US14/076,063 priority patent/US9794320B2/en
Priority to PCT/KR2013/010131 priority patent/WO2014073902A1/en
Publication of KR20140060132A publication Critical patent/KR20140060132A/ko
Application granted granted Critical
Publication of KR102036579B1 publication Critical patent/KR102036579B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/12—Application layer protocols, e.g. WAP [Wireless Application Protocol]
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

무선 통신 시스템에서 기지국과 웹 서버 사이에 위치하며, 상기 기지국을 통해 이동 단말과 통신을 수행하는 프록시 캐쉬가 상기 이동 단말에 대한 웹 서비스 요청이 수신되면, 상기 웹 서비스 요청에 따른 웹 페이지를 분석하고, 상기 분석 결과를 근거로 상기 웹 서버로부터 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 수신하고, 상기 적어도 하나의 임베디드 객체의 크기를 근거로 상기 이동 단말을 위한 불연속 수신(Discontinuous Reception: DRX) 주기를 설정하고, 상기 설정된 DRX 주기에 대한 정보를 상기 이동 단말로 송신하고, 상기 설정된 DRX 주기가 종료되는 시점에 상기 적어도 하나의 임베디드 객체가 포함된 웹 서비스 응답을 상기 이동 단말로 송신한다.

Description

무선 통신 시스템에서 웹 서비스 제공 방법 및 장치{METHOD AND APPARATUS FOR PROVIDING A WEB SERVICE IN A WIRELESS COMMUNICATION SYSTEM}
본 발명은 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치에 관한 것이다.
무선 통신 기술이 발달함에 따라 이동 단말을 이용한 웹 서핑, 영화나 음악 등과 같은 컨텐츠 및 SNS(Social Networking Service)의 사용량이 증가되고 있다. 이러한 웹 기반 서비스의 사용량이 증가함에 따라 사용자에게 보다 원활한 서비스를 제공하기 위한 여러 가지 방안이 제안되고 있다. 상기 여러 가지 방안 중 하나로서 무선 통신 환경에서 캐쉬(cache) 서버를 사용하는 방안이 제안되고 있다. 상기 캐쉬 서버는 이동 단말과 웹 서버 사이의 기지국 단에 설치되어 운용될 수 있다.
상기 캐쉬 서버의 구체적인 동작을 살펴보면 다음과 같다. 상기 캐쉬 서버는 이동 단말의 HTTP(Hyper Text Transfer Protocol) 요청(request)에 대응한 캐쉬 미스(miss) 상황이 발생하지 않도록 HTML(Hyper Text Markup Language)로 구성된 웹 페이지를 미리 해석한다. 그리고 상기 캐쉬 서버는 상기 웹 페이지의 해석 결과를 근거로 상기 이동 단말에게 송신해야 할 임베디드 객체(embedded object)가 존재하는지 여부를 판단하고, 상기 임베디드 객체가 존재하는 경우 상기 웹 서버로부터 상기 임베디드 객체를 다운로드 받아 저장한다. 상기와 같은 캐쉬 서버의 동작은 상기 이동 단말이 해당 웹 페이지를 해석하는 동안 수행될 수 있다.
상기 캐쉬 서버는 상기 이동 단말로부터 HTTP 요청이 수신되면 상기 HTTP 요청에 대한 응답으로, 상기 저장된 임베디드 객체가 포함된 HTTP 응답을 상기 이동 단말로 송신한다. 여기서 상기 캐쉬 서버는 하나의 HTTP 요청에 대응하여 하나의 임베디드 객체를 상기 이동 단말로 송신하거나, 하나의 HTTP 요청에 대응하여 다수의 임베디드 객체(일 예로, 해당 웹 페이지에 포함된 전체 임베디드 객체 또는 그 일부)를 한번에 상기 이동 단말로 송신할 수 있다.
상기와 같은 과정에 따라 상기 이동 단말에서 전체 임베디드 객체를 수신하는 시간은 단축될 수 있다. 하지만 상기 이동 단말에서는 수신된 임베디드 객체를 해석하고 화면에 렌더링(rendering)하기 위한 시간이 요구되므로, 다수의 임베디드 객체를 한번에 수신할 경우 해당 웹 페이지를 렌더링 하기 위한 시간이 더 많이 소요되는 문제가 있다. 또한 비디오 객체의 경우 하나의 파일로 구성됨에 따라 상기와 같은 과정이 수행되더라도 객체 수신 시간을 단축시킬 수 없는 문제가 있다.
본 발명은 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치를 제안한다.
그리고 본 발명은 이동 단말의 전력 소모를 최소화하면서 사용자에게 보다 빠른 웹 서비스를 제공하는 방법 및 장치를 제안한다.
또한 본 발명은 웹 서비스를 사용하는 이동 단말에서 불연속 수신(Discontinuous Reception: DRX) 방식을 효율적으로 사용할 수 있도록 하는 방법 및 장치를 제안한다.
본 발명에서 제안하는 방법은; 무선 통신 시스템에서 기지국과 웹 서버 사이에 위치하며, 상기 기지국을 통해 이동 단말과 통신을 수행하는 프록시 캐쉬가 웹 서비스를 제공하는 방법에 있어서, 상기 이동 단말에 대한 웹 서비스 요청이 수신되면, 상기 웹 서비스 요청에 따른 웹 페이지를 분석하는 과정과, 상기 분석 결과를 근거로 상기 웹 서버로부터 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 수신하는 과정과, 상기 적어도 하나의 임베디드 객체의 크기를 근거로 상기 이동 단말을 위한 불연속 수신(Discontinuous Reception: DRX) 주기를 설정하고, 상기 설정된 DRX 주기에 대한 정보를 상기 이동 단말로 송신하는 과정과, 상기 설정된 DRX 주기가 종료되는 시점에 상기 적어도 하나의 임베디드 객체가 포함된 웹 서비스 응답을 상기 이동 단말로 송신하는 과정을 포함한다.
본 발명에서 제안하는 다른 방법은; 무선 통신 시스템에서 이동 단말이 웹 서비스를 수신하는 방법에 있어서, 웹 서비스 요청을 기지국으로 송신하는 과정과, 상기 이동 단말에 대한 불연속 수신(Discontinuous Reception: DRX) 주기에 대한 정보를 수신하는 과정과, 상기 DRX 주기 동안 슬립(sleep) 모드로 동작하는 과정과, 상기 DRX 주기가 종료되는 시점에 상기 슬립 모드에서 리스닝(listening) 모드로 천이하여, 상기 웹 서비스 요청에 대응되는 적어도 하나의 임베디드 객체가 포함된 웹 서비스 응답을 상기 기지국으로부터 수신하는 과정을 포함한다.
본 발명에서 제안하는 또 다른 방법은; 무선 통신 시스템에서 기지국과 웹 서버 사이에 위치하며, 상기 기지국을 통해 이동 단말과 통신을 수행하는 프록시 캐쉬가 웹 서비스를 제공하는 방법에 있어서, 상기 이동 단말에 대한 웹 서비스 요청이 수신되면, 상기 웹 서비스 요청에 따른 웹 페이지를 분석하는 과정과, 상기 분석 결과를 근거로 상기 웹 서버로부터 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 수신하는 과정과, 상기 적어도 하나의 임베디드 객체들을 송신하기 위해 사용할, 상기 프록시 캐쉬와 이동 단말 간 연결(connection) 개수를 결정하고, 상기 결정된 연결 개수에 대한 정보를 상기 이동 단말로 송신하는 과정과, 상기 결정된 연결 개수에 대응하는 연결을 사용하여 상기 적어도 하나의 임베디드 객체가 포함된 웹 서비스 응답을 상기 이동 단말로 송신하는 과정을 포함한다.
본 발명에서 제안하는 장치는; 무선 통신 시스템에서 기지국과 웹 서버 사이에 위치하며, 상기 기지국을 통해 이동 단말과 통신을 수행하는 프록시 캐쉬에 있어서, 송신부와, 수신부와, 상기 이동 단말에 대한 웹 서비스 요청이 수신되면, 상기 웹 서비스 요청에 따른 웹 페이지를 분석하고, 상기 분석 결과를 근거로 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 웹 서버로부터 수신하도록 상기 수신부를 제어하고, 상기 적어도 하나의 임베디드 객체의 크기를 근거로 상기 이동 단말을 위한 불연속 수신(Discontinuous Reception: DRX) 주기를 설정하고, 상기 송신부를 제어하여 상기 설정된 DRX 주기에 대한 정보를 상기 이동 단말로 송신하고, 상기 설정된 DRX 주기가 종료되는 시점에 상기 적어도 하나의 임베디드 객체가 포함된 웹 서비스 응답을 상기 이동 단말로 송신하는 제어부를 포함한다.
본 발명에서 제안하는 다른 장치는; 무선 통신 시스템에서 이동 단말에 있어서, 웹 서비스 요청을 기지국으로 송신하는 송신부와, 상기 이동 단말에 대한 불연속 수신(Discontinuous Reception: DRX) 주기에 대한 정보를 수신하는 수신부와, 상기 DRX 주기 동안 슬립 모드로 동작하도록 제어하고, 상기 DRX 주기가 종료되는 시점에 리스닝(listening) 모드로 천이하여, 상기 웹 서비스 요청에 대응되는 적어도 하나의 임베디드 객체가 포함된 웹 서비스 응답을 상기 수신부를 통해 상기 기지국으로부터 수신하는 제어부를 포함한다.
본 발명에서 제안하는 또 다른 장치는; 무선 통신 시스템에서 기지국과 웹 서버 사이에 위치하며, 상기 기지국을 통해 이동 단말과 통신을 수행하는 프록시 캐쉬에 있어서, 상기 이동 단말에 대한 웹 서비스 요청이 수신되면, 상기 웹 서비스 요청에 따른 웹 페이지를 분석하는 제어부와, 상기 분석 결과를 근거로 상기 웹 서버로부터 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 수신하는 수신부와, 상기 제어부에서 상기 적어도 하나의 임베디드 객체들을 송신하기 위해 사용할, 상기 프록시 캐쉬와 이동 단말 간 연결(connection) 개수가 결정되면, 상기 결정된 연결 개수에 대한 정보를 상기 이동 단말로 송신하고, 상기 결정된 연결 개수에 대응하는 연결을 사용하여 상기 적어도 하나의 임베디드 객체가 포함된 웹 서비스 응답을 상기 이동 단말로 송신하는 송신부를 포함한다.
본 발명은 이동 단말의 사용자에게 보다 빠른 웹 서비스를 제공할 수 있는 이점이 있다. 따라서 본 발명에서 이동 단말의 사용자는 유선 망으로 웹 서비스를 제공받는 사용자와 거의 동일한 성능으로 웹 서비스를 제공받을 수 있는 효과가 있다.
그리고 본 발명은 이동 단말에서 불연속 수신(Discontinuous Reception: DRX) 방식을 효율적으로 사용할 수 있도록 함으로써 이동 단말의 배터리 소모를 최소화 할 수 있는 이점이 있다.
또한 본 발명은 무선 채널 정보를 기반으로 웹 서비스를 제공함으로써 무선 용량을 증대시킬 수 있는 효과가 있다.
도 1은 본 발명의 실시 예에 따른 무선 통신 시스템의 구성도,
도 2a는 무선 통신 시스템에서 HTTP 요청 및 응답을 송수신하는 과정을 나타낸 신호 흐름도,
도 2b는 무선 통신 시스템에서 DRX 방식을 사용하여 HTTP 요청 및 응답을 송수신하는 과정을 나타낸 신호 흐름도,
도 3은 본 발명의 실시 예에 따른 무선 통신 시스템에서 DRX 방식을 사용하여 HTTP 요청 및 응답을 송수신하는 과정을 나타낸 신호 흐름도,
도 4a 및 도 4b는 본 발명의 실시 예에 따른 프록시 캐쉬가 DRX 주기를 설정하는 과정을 나타낸 순서도,
도 5a 및 도 5b는 본 발명의 실시 예에 따른 무선 통신 시스템에서 DRX 방식을 사용하여 PUSH 동작을 수행하는 과정을 나타낸 신호 흐름도,
도 6a는 본 발명의 실시 예에 따른 무선 통신 시스템에서 프록시 캐쉬가 DRX 방식을 사용하여 PUSH 동작을 수행하는 과정을 나타낸 순서도,
도 6b는 본 발명의 실시 예에 따른 무선 통신 시스템에서 프록시 캐쉬가 TCP 연결 수를 증가시켜 PUSH 동작을 수행하는 과정을 나타낸 순서도,
도 7a 및 도 7b는 본 발명의 실시 예에 따른 무선 통신 시스템에서 DRX 방식을 사용하여 PUSH 동작을 수행하는 과정을 나타낸 신호 흐름도,
도 8은 본 발명의 실시 예에 따른 무선 통신 시스템에서 프록시 캐쉬가 DRX 방식을 사용하여 PUSH 동작을 수행하는 과정을 나타낸 순서도,
도 9는 본 발명의 실시 예에 따른 프록시 캐쉬와 이동 단말 사이에 설정된 다수의 연결(multiple connection)을 이용한 PUSH 방식을 나타낸 도면,
도 10a 및 도 10b는 본 발명의 실시 예에 따른 이동 단말과 프록시 캐쉬 간 다수의 연결을 생성하는 과정을 나타낸 신호 흐름도,
도 11은 본 발명의 실시 예에 따른 이동 단말의 동작을 나타낸 순서도,
도 12는 본 발명의 실시 예에 따른 프록시 캐쉬의 블록 구성도,
도 13은 본 발명의 실시 예에 따른 이동 단말의 블록 구성도.
이하 첨부된 도면을 참조하여 본 발명의 동작 원리를 상세히 설명한다. 하기에서 본 발명을 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
본 발명은 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치를 제공한다. 구체적으로 본 발명은 무선 통신 시스템에서 무선 채널 정보를 기반으로 이동 단말에게 웹 서비스를 제공하고, 상기 이동 단말에서는 불연속 수신(Discontinuous Reception: DRX) 방식을 사용하여 상기 웹 서비스를 수신하도록 함으로써 무선 자원을 효율적으로 사용하고 이동 단말의 전력 소모를 최소화할 수 있도록 하는 방법 및 장치를 제공한다.
도 1은 본 발명의 실시 예에 따른 무선 통신 시스템의 구성도이다.
도 1을 참조하면, 상기 무선 통신 시스템은 이동 단말(100), 무선 노드(110) 및 코어 네트워크(Core Network)(120)를 포함한다.
상기 이동 단말(100)은 휴대 전화나 태블릿 PC 등과 같은 웹 서비스를 이용할 수 있는 장치로서, 웹 서비스를 제공받기 위한 HTTP 요청(request)을 송신한다. 상기 HTTP 요청은 URL 주소, HTTP 메소드 및 파라미터 등을 포함할 수 있다.
상기 코어 네트워크(120)는 인터넷 망과 웹 서버(116)를 포함한다. 상기 웹 서버(116)는 웹 페이지, SNS, 동영상 등과 같은 다양한 웹 서비스를 제공한다.
상기 무선 노드(110)는 기지국(112) 및 프록시 캐쉬(114)를 포함한다. 상기 기지국(112)은 LTE 등의 셀룰러(cellular) 망의 eNodeB 또는 무선 랜 액세스 포인트(Wireless LAN Access Point)가 될 수 있다. 그리고 상기 프록시 캐쉬(114)는 상기 웹 서버(116)로부터 수신한 웹 객체(일 예로, 웹 페이지에 포함된 이미지나 동영상, 데이터 등)들을 미리 저장해둘 수 있으며, 상기 이동 단말(100)의 HTTP 요청이 수신되면 상기 미리 저장된 객체들을 상기 이동 단말(100)로 송신한다. 상기 미리 저장된 객체들은 HTTP 응답(response)에 포함되는데, 상기 HTTP 응답은 해당 객체 및 해당 객체의 타입 등을 포함할 수 있다.
만약 상기 프록시 캐쉬(114)는 캐쉬 미스(cache miss)가 발생한 경우(즉, 미리 저장된 객체들이 없거나 상기 이동 단말(100)이 요청한 객체가 없는 경우), 상기 코어 네트워크(120)로 해당 객체를 요청하기 위한 HTTP 요청을 송신한 후, 상기 코어 네트워크(120)로부터 해당 객체가 포함된 HTTP 응답을 수신하여 상기 이동 단말(100)로 송신할 수 있다.
한편 상기 기지국(112)과 상기 프록시 캐쉬(114)는 논리적으로 연결된 장치(logically coupled unit)이다. 따라서 도 1에는 상기 기지국(112)과 상기 프록시 캐쉬(114)가 구분되어 도시되어 있지만, 상기 기지국(112)과 상기 프록시 캐쉬(114)는 하나의 물리적인 장치에 모듈(module) 형태로 포함되는 것도 가능하다.
상기 이동 단말(100)의 전력 소모를 줄이기 위해 DRX 방식이 사용될 수 있다. 상기 DRX 방식은 상기 이동 단말(100)이 상기 이동 단말(100)에 대한 트래픽(traffic)이 존재하는 경우에는 리스닝(listening) 또는 액티브(active) 모드로 동작하고, 그렇지 않은 경우에는 슬립(sleep) 모드로 동작하는 방식을 나타낸다. 상기 프록시 캐쉬(114)는 이동 단말(100)의 전력 소모를 줄이고 최적화된 웹 서비스 제공을 위해 DRX 방식에 따라 HTTP 요청에 따른 객체를 송신할 수 있다.
웹 서비스 제공시 DRX 방식이 사용되지 않을 경우 도 2a에 나타난 바와 같이 일반적인 파일 다운로드 과정과 유사한 과정이 수행될 수 있다.
도 2a는 무선 통신 시스템에서 HTTP 요청 및 응답을 송수신하는 과정을 나타낸 신호 흐름도이다.
도 2a를 참조하면, 200 단계에서 이동 단말(100)은 HTTP 요청 1을 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 202 단계에서 상기 HTTP 요청 1을 프록시 캐쉬(114)로 전달하고, 204 단계에서 상기 프록시 캐쉬(114)로부터 상기 HTTP 요청 1에 대한 응답으로 적어도 하나의 HTTP 응답 1을 수신한다. 그리고 상기 기지국(112)은 206 단계에서 상기 적어도 하나의 HTTP 응답 1을 상기 이동 단말(100)로 송신한다.
하나의 HTTP 요청에 대해서는 적어도 하나의 HTTP 응답이 상기 이동 단말(100)로 송신될 수 있다. 예를 들어, 상기 HTTP 요청 1이 작은 크기의 이미지 파일을 요청하기 위한 HTTP 요청인 경우, 상기 이미지 파일은 하나의 HTTP 응답에 포함되어 상기 이동 단말(100)로 송신될 수 있다. 그리고 상기 HTTP 요청 1이 대용량 비디오 파일을 요청하기 위한 HTTP 요청인 경우, 상기 비디오 파일은 다수의 HTTP 응답에 포함되어 상기 이동 단말(100)로 송신될 수 있다. 여기서 상기 비디오 파일은 분할(fragment)되어 세그먼트(segment) 형태로 다수의 HTTP 응답에 포함될 수 있다.
상기 이동 단말(100)은 208 단계에서 상기 적어도 하나의 HTTP 응답 1의 수신이 완료되면, 210 단계에서 HTTP 요청 2를 상기 기지국(112)으로 송신한다. 앞서 설명한 바와 유사하게, 상기 기지국(112)은 212 단계에서 상기 HTTP 요청 2을 상기 프록시 캐쉬(114)로 전달하고, 214 단계에서 상기 프록시 캐쉬(114)로부터 상기 제2 HTTP 요청에 대한 응답으로 적어도 하나의 제2 HTTP 응답을 수신한다. 그리고 상기 기지국(112)은 216 단계에서 상기 적어도 하나의 제2 HTTP 응답을 상기 이동 단말(100)로 송신한다. 상기 적어도 하나의 제2 HTTP 응답에 대한 수신은 218 단계에서 완료된다.
도 2a와 같은 과정이 수행되는 무선 통신 시스템에서 일반적인 DRX 방식이 사용될 경우 상기 기지국(112)은 현재 진행되고 있는 객체 또는 파일 전송의 특성을 모르기 때문에 미리 설정된 하나의 DRX 주기(interval)를 기반으로 HTTP 요청 및 응답을 송수신한다. 이에 대한 내용을 도 2b를 참조로 구체적으로 살펴보면 다음과 같다.
도 2b는 무선 통신 시스템에서 DRX 방식을 사용하여 HTTP 요청 및 응답을 송수신하는 과정을 나타낸 신호 흐름도이다.
도 2b를 참조하면, 이동 단말(100)은 220 단계에서 HTTP 요청 1을 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 222 단계에서 상기 제1 HTTP 요청을 프록시 캐쉬(114)로 송신하고, 224 단계에서 상기 프록시 캐쉬(114)로부터 상기 HTTP 요청 1에 대한 응답으로 적어도 하나의 HTTP 응답 1을 수신한다. 상기 기지국(112)은 226 단계에서 제1 DRX 주기(225)가 종료되는 시점(228)에 상기 적어도 하나의 HTTP 응답 1을 상기 이동 단말(100)로 송신한다. 이는 해당 DRX 주기 동안 슬립 모드로 동작 중인 이동 단말(100)이 해당 DRX 주기가 종료되는 시점에 웨이크 업(wake up)하여 리스닝 모드로 동작하기 때문이다.
한편, 동일한 TCP 연결(connection)이 계속적으로 사용되는 경우, 상기 적어도 하나의 HTTP 응답 1에 대한 수신이 완료된 후 HTTP 요청 2가 송신될 필요가 있다. 왜냐하면 상기 이동 단말(100)에서 상기 적어도 하나의 HTTP 응답 1의 수신이 완료되기 전에 상기 HTTP 요청 2가 송신된다면, 상기 적어도 하나의 HTTP 응답 1 중 일부와 적어도 하나의 HTTP 응답 2 중 일부가 뒤섞여 해당 파일이 복원될 수 없는 문제가 발생하기 때문이다.
이에 따라 상기 이동 단말(100)은 상기 적어도 하나의 제1 HTTP 응답의 수신이 완료된 이후의 230 단계에서 HTTP 요청 2를 상기 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 232 단계에서 상기 HTTP 요청 2를 상기 프록시 캐쉬(114)로 전달하고, 234 단계에서 상기 프록시 캐쉬(114)로부터 상기 HTTP 요청 2에 대한 응답으로 적어도 하나의 HTTP 응답 2-1를 수신한다.
하지만 237 단계에 나타난 바와 같이, 제2 DRX 주기(235)가 종료된 시점 이후의 제3 DRX 주기(245)에서 상기 HTTP 요청 2에 대한 또 다른 응답으로 HTTP 응답 2-2가 상기 프록시 캐쉬(114)로부터 송신될 수 있다. 이 경우 상기 이동 단말(100)은 238 단계에서 상기 HTTP 응답 2-2를 수신하여, 결과적으로 HTTP 응답 2 전체를 상기 제3 DRX 주기(245)가 종료되는 시점(240)에야 수신한다. 이러한 상황에 따라 상기 HTTP 요청 2에 이은 HTTP 요청 3에 대한 송신은 지연되며, 고정된 DRX 주기가 사용됨에 따라 이동 단말에서 항상 동일한 시간 간격으로 HTTP 응답을 수신할 수 밖에 없는 문제가 있다.
상기와 같은 문제를 해결하기 위하여, 본 발명의 실시 예에서는 이동 단말로 제공될 객체(또는 파일) 크기 등을 기반으로 DRX 주기를 동적으로 사용할 수 있도록 하는 방법을 제시한다.
도 3은 본 발명의 실시 예에 따른 무선 통신 시스템에서 DRX 방식을 사용하여 HTTP 요청 및 응답을 송수신하는 과정을 나타낸 신호 흐름도이다.
도 3을 참조하면, 300 단계에서 이동 단말(100)은 HTTP 요청 1을 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 302 단계에서 상기 HTTP 요청 1을 프록시 캐쉬(114)로 송신한다. 상기 프록시 캐쉬(114)는 상기 HTTP 요청 1에 따른 객체를 웹 서버(116)로부터 미리 수신하여 상기 이동 단말(100)이 요청하는 객체의 크기를 알 수 있다. 따라서 상기 프록시 캐쉬(114)는 상기 이동 단말(100)이 요청하는 객체의 크기를 근거로 상기 이동 단말(100)에서 상기 제1 HTTP 요청에 대응하는 적어도 하나의 제1 HTTP 응답의 수신이 완료되는 시점을 추정할 수 있다.
이에 따라 상기 프록시 캐쉬(114)는 304 단계에서 상기 추정된 시점을 고려하여 제1 DRX 주기(interval)(305)를 설정한다(DRX set 1). 일 예로 상기 프록시 캐쉬(114)는 상기 추정된 시점이 상기 제1 DRX 주기(305)의 종료 시점에 대응하도록 상기 제1 DRX 주기(305)를 설정할 수 있다.
상기 프록시 캐쉬(114)는 306 단계에서 상기 설정된 제1 DRX 주기(305)에 대한 정보를 상기 기지국(112)으로 송신한다. 그리고 상기 기지국(112)은 308 단계에서 상기 제1 DRX 주기(305)에 대한 정보를 상기 이동 단말(100)로 송신한다.
여기서 상기 설정된 제1 DRX 주기(305)에 대한 정보에는 상기 제1 DRX 주기(305)를 위한 제1 DRX 타이머 정보가 포함될 수 있다. 이에 따라 상기 이동 단말(100)은 상기 제1 DRX 타이머 정보에 따른 시간 동안 슬립 모드로 동작한다. 즉, 상기 이동 단말(100)은 상기 제1 DRX 주기(305)에 대한 정보가 수신된 후 상기 제1 DRX 타이머를 작동시키고, 상기 제1 DRX 타이머가 종료되기 전까지 상기 슬립 모드로 동작한다.
상기 프록시 캐쉬(114)는 310 단계에서 상기 적어도 하나의 HTTP 응답 1을 상기 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 312 단계에서 상기 적어도 하나의 HTTP 응답 1을 상기 이동 단말(100)로 송신한다. 이때 상기 기지국(112)은 상기 제1 DRX 주기(305)에 따른 시간을 고려하여, 상기 제1 DRX 주기(305)가 완료되는 시점에 상기 적어도 하나의 제1 HTTP 응답을 상기 이동 단말(100)로 송신한다.
상기 제1 DRX 주기(305)가 완료된 후, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)이 상기 적어도 하나의 HTTP 응답 1을 모두 수신하여 아이들(idle) 상태임을 판단하고, 314 단계에서 상기 제1DRX 주기보다 더 큰 주기를 갖는 제2 DRX 주기(315)를 설정한다(DRX set 2). 그리고 상기 프록시 캐쉬(114)는 316 단계에서 상기 설정된 제2 DRX 주기(315)에 대한 정보를 상기 이동 단말(100)로 송신한다. 이어 상기 기지국(112)은 318 단계에서 상기 제2 DRX 주기(315)에 대한 정보를 상기 이동 단말(100)로 송신한다.
여기서 상기 설정된 제2 DRX 주기(315)에 대한 정보에는 상기 제2 DRX 주기(315)를 위한 제2 DRX 타이머 정보가 포함될 수 있다. 이에 따라 상기 이동 단말(100)은 상기 제2 DRX 타이머 정보에 따른 시간 동안 슬립 모드로 동작한다. 즉, 상기 이동 단말(100)은 상기 제2 DRX 주기(315)에 대한 정보가 수신된 후 상기 제2 DRX 타이머를 작동시키고, 상기 제2 DRX 타이머가 종료되기 전까지 상기 슬립 모드로 동작한다.
상기 제2 DRX 주기(315) 동안, 상기 이동 단말(100)은 319 단계에서 HTTP 요청 2를 상기 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 320 단계에서 상기 HTTP 요청 2를 상기 프록시 캐쉬(114)로 송신한다. 상기 프록시 캐쉬(114)는 321 단계에서 상기 HTTP 요청 2에 대한 응답으로 적어도 하나의 HTTP 응답 2-1을 상기 기지국(112)으로 송신한다. 그리고 상기 기지국(112)은 322 단계에서 상기 제2 DRX 주기(315)가 종료되는 시점에 상기 적어도 하나의 HTTP 응답 2-1을 상기 이동 단말(100)로 송신한다. 도 3에서는 상기 HTTP 요청 2에 대한 응답인 HTTP 응답 2가 HTTP 응답 2-1, 2-2 및 2-3으로 분할되어 송신되는 것을 일 예로 설명하기로 한다.
한편 상기 제2 DRX 주기(315)가 종료된 후에도 상기 이동 단말(100)로 송신해야 할 HTTP 응답이 존재할 수 있다. 이 경우, 상기 프록시 캐쉬(114)는 324 단계에서 상기 이동 단말(100)로 송신해야 할 객체의 크기를 기반으로 제3 DRX 주기(325)를 설정한다(DRX set 3). 그리고 상기 프록시 캐쉬(114)는 326 단계에서 상기 제3 DRX 주기(325)에 대한 정보를 상기 기지국(112)으로 송신한다. 이어 상기 기지국(112)은 328 단계에서 상기 제3 DRX 주기(325)에 대한 정보를 상기 이동 단말(100)로 송신한다.
여기서 상기 설정된 제3 DRX 주기(325)에 대한 정보에는 상기 제3 DRX 주기(325)를 위한 제3 DRX 타이머 정보가 포함될 수 있다. 이에 따라 상기 이동 단말(100)은 상기 제3 DRX 타이머 정보에 따른 시간 동안 슬립 모드로 동작한다. 즉, 상기 이동 단말(100)은 상기 제3 DRX 주기(325)에 대한 정보가 수신된 후 상기 제3 DRX 타이머를 작동시키고, 상기 제3 DRX 타이머가 종료되기 전까지 상기 슬립 모드로 동작한다.
상기 프록시 캐쉬(114)는 330 단계에서 상기 이동 단말(100)에게 송신해야 할 HTTP 응답 2-2를 상기 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 332 단계에서 상기 HTTP 응답 2-2를 상기 이동 단말(100)로 송신한다. 이때 상기 기지국(112)은 상기 제3 DRX 주기(325)에 따른 시간을 고려하여, 상기 제3 DRX 주기(325)가 완료되는 시점에 상기 HTTP 응답 2-2를 상기 이동 단말(100)로 송신한다.
한편, 상기 프록시 캐쉬(114)는 상기 제3 DRX 주기(325)가 종료된 후에도 상기 이동 단말(100)로 송신해야 할 HTTP 응답이 존재하며, 상기 이동 단말(100)로 송신해야 할 HTTP 응답의 수가 임계값 미만인 경우, 334 단계에서 DRX 모드를 해제할 것을 결정할 수 있다. 이에 따라 상기 프록시 캐쉬(114)는 336 단계에서 DRX 모드를 해제할 것을 지시하는 DRX 해제 메시지를 상기 기지국(112)으로 송신한다. 그리고 상기 기지국(112)은 338 단계에서 상기 DRX 해제 메시지를 상기 이동 단말(100)로 송신한다. 그러면 상기 이동 단말(100)은 340 단계에서 상기 DRX 모드를 해제한다.
이어 상기 이동 단말(100)은 342 단계에서 상기 프록시 캐쉬(114)가 상기 기지국(112)으로 송신한 마지막 HTTP 응답 2-3을 344 단계에서 상기 기지국(112)을 통해 수신한다. 그러면 상기 이동 단말(100)은 346 단계에서 HTTP 응답 2에 대한 수신을 완료하게 된다.
한편, 도 3에서는 객체 크기를 기반으로 해당 HTTP 응답이 수신되는 시점을 추정함으로써 DRX 주기를 설정하였으나, 상기 프록시 캐쉬(114)에서의 다운로드 속도를 고려하여 상기 DRX 주기를 설정하는 것도 가능하다. 상기 DRX 주기는 DRX 타이머를 기반으로 설정되므로 하기와 같이 결정된 DRX 타이머를 기반으로 상기 DRX 주기가 설정될 수 있다.
상기 프록시 캐쉬(114)는 웹 서버(116)로부터 파일을 다운로드 하여 상기 이동 단말(100)로 송신하는데, 상기 웹 서버(116)로부터 파일을 다운로드 하는 속도가 미리 설정된 속도 보다 느리다면 다운로드가 완료될 때까지 소요되는 시간이 늘어날 수 있다. 따라서 상기 프록시 캐쉬(114)는 DRX 타이머를 임계값 이상으로 크게 설정할 수 있다. 이와 반대로, 상기 프록시 캐쉬(114)에서 상기 웹 서버로부터 파일을 다운로드 하는 속도가 미리 설정된 속도 보다 빠르다면 다운로드가 완료될 때까지 소용되는 시간이 줄어들 수 있으므로, 상기 프록시 캐쉬(114)는 상기 DRX 타이머를 임계값 보다 작게 설정할 수 있다.
상기 프록시 캐쉬(114)는 상기 이동 단말(100)의 처리량을 근거로 상기 DRX 타이머를 설정하는 것도 가능하다. 예를 들어, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)이 1초간 처리할 양만큼의 데이터를 버퍼링하고 있다면, DRX 타이머를 임계값 보다 작게 설정하여 그 다음 데이터가 상기 이동 단말(100)로 빨리 송신될 수 있도록 한다. 그리고 상기 프록시 캐쉬(114)는 상기 이동 단말(100)이 10초간 처리할 양만큼의 데이터를 버퍼링하고 있다면, 상기 DRX 타이머를 임계값 이상으로 설정하여 그 다음 데이터가 해당 DRX 주기가 종료되는 시점에 상기 이동 단말(100)로 한번에 송신될 수 있도록 한다.
추가적으로, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)로 송신해야 할 파일의 양을 고려하여 상기 DRX 타이머를 설정하는 것도 가능하다.
이하 도 4a 및 도 4b를 참조하여 DRX 주기를 설정하는 방법을 구체적으로 설명하기로 한다.
도 4a 및 도 4b는 본 발명의 실시 예에 따른 프록시 캐쉬가 DRX 주기를 설정하는 과정을 나타낸 순서도이다.
도 4a 의 408 단계, 418 단계 및 426 단계는 각각 도면부호 a, b, c를 통해 도 4b의 410 단계, 420 단계, 428 단계와 이어진다. 이와 같은 사항을 고려하여 도 4a 및 도 4b에서의 프록시 캐쉬(114)의 동작을 살펴보면 다음과 같다.
상기 프록시 캐쉬(114)는 400 단계에서 이동 단말(100)로부터 송신된 HTTP 요청을 기지국(112)을 통해 수신한다. 그리고 상기 프록시 캐쉬(114)는 402 단계에서 웹 서버(116)로부터 상기 HTTP 요청에 따른 파일을 수신한다. 상기 프록시 캐쉬(114)는 404 단계에서 상기 수신된 파일의 종류를 판단한다 일 예로, 상기 프록시 캐쉬(114)는 상기 수신된 파일이 상기 이동 단말(100)에서 처리가 필요한 데이터인지, 이미지 등과 같이 별도의 처리가 필요하지 않은 일반 파일인지, 또는 비디오인지 여부를 판단한다.
상기 프록시 캐쉬(114)는 상기 HTTP 요청에 포함된 URL 정보를 근거로 상기 파일의 종류를 판단할 수 있다. 또한 상기 프록시 캐쉬(114)는 상기 웹 서버(116)로부터 다운로드 받은 파일의 헤더(이미지나 비디오 파일의 경우 파일 헤더 등을 분석할 수 있음)나 HTTP 응답 헤더 등을 기반으로 상기 파일의 종류를 판단할 수 있다.
상기 프록시 캐쉬(114)는 상기 수신된 파일이 상기 이동 단말(100)에서 처리가 필요한 데이터인 경우, 406 단계로 진행하여 상기 HTTP 요청의 헤더에 포함된 상기 이동 단말(100)의 데이터 처리 능력(process capability)을 검출한다. 이어 상기 프록시 캐쉬(114)는 408 단계에서 상기 이동 단말(100)에서 처리되지 않은 데이터량이 어느 정도인지를 판단한다. 상기 프록시 캐쉬(114)는 상기 이동 단말(100)로부터 처리된 데이터에 대한 정보가 포함된 피드백 신호 등을 근거로 상기 이동 단말(100)에서 처리되지 않은 데이터량이 어느 정도인지를 판단할 수 있다.
상기 프록시 캐쉬(114)는 410 단계에서 상기 이동 단말(100)의 데이터 처리 능력과 상기 이동 단말(100)에서 처리되지 않은 데이터량을 근거로 상기 이동 단말(100)의 데이터 처리 완료 시간을 추정한다. 그리고 상기 프록시 캐쉬(114)는 상기 추정된 데이터 처리 완료 시간을 근거로 DRX 주기를 설정한다. 상기 프록시 캐쉬(114)는 데이터 처리 완료 시간 별 DRX 타이머 정보가 포함된 별도의 테이블을 근거로 상기 DRX 주기를 설정할 수 있다. 이어 상기 프록시 캐쉬(114)는 상기 설정된 DRX에 대한 정보를 상기 기지국(112)으로 송신함으로써 상기 설정된 DRX에 대한 정보가 상기 이동 단말(100)로 송신될 수 있도록 한다.
한편, 상기 프록시 캐쉬(114)는 상기 수신된 파일이 이미지나 별도의 처리가 필요하지 않은 단순 데이터인 경우, 416 단계로 진행하여 웹 서버에서 상기 프록시 캐쉬(114)로의 다운로드 속도를 측정한다. 이어 상기 프록시 캐쉬(114)는 418 단계에서 상기 이동 단말의 처리량을 근거로 상기 프록시 캐쉬(114)에서 상기 이동 단말(100)로의 파일 전송 완료 시간을 추정한다.
상기 프록시 캐쉬(114)는 420 단계에서 상기 추정된 파일 전송 완료 시간을 근거로 DRX 주기를 설정한다. 상기 프록시 캐쉬(114)는 파일 전송 완료 시간 별 DRX 타이머 정보가 포함된 별도의 테이블을 근거로 상기 DRX 주기를 설정할 수 있다. 이어 상기 프록시 캐쉬(114)는 422 단계에서 상기 설정된 DRX 주기에 대한 정보를 상기 기지국(112)으로 송신함으로써 상기 설정된 DRX에 대한 정보가 상기 이동 단말(100)로 송신될 수 있도록 한다.
상기 프록시 캐쉬(114)는 상기 수신된 파일이 비디오인 경우, 424 단계로 진행하여 상기 이동 단말(100)의 비디오 버퍼링 시간을 추정한다. 이어 상기 프록시 캐쉬(114)는 426 단계에서 상기 비디오 버퍼링 시간을 기반으로 상기 이동 단말(100)의 비디오 컷 오프(cut-off) 시간을 추정한다. 상기 비디오 컷 오프 시간은 상기 이동 단말(100)에서 버퍼된 데이터가 존재하지 않아 비디오가 끊기는 시간을 나타낸다.
상기 프록시 캐쉬(114)는 428 단계에서 상기 비디오 컷 오프 시간을 근거로 DRX 주기를 설정한다. 여기서 상기 프록시 캐쉬(114)는 상기 비디오 컷 오프 시간 별 DRX 타이머 정보가 포함된 별도의 테이블을 근거로 상기 DRX 주기를 설정할 수 있다. 이어 상기 프록시 캐쉬(114)는 430 단계에서 상기 설정된 DRX 주기에 대한 정보를 상기 기지국(112)으로 송신함으로써 상기 설정된 DRX에 대한 정보가 상기 이동 단말(100)로 송신될 수 있도록 한다.
상기와 같은 도 4a 및 도 4b의 과정은 해당 DRX 주기가 종료되는 시점(즉, 이동 단말(100)이 웨이크 업하는 시점)마다 반복되어 수행될 수 있다.
한편, 사용자에게 좀 더 빠른 웹 서비스를 제공하기 위하여 도 3에서 상기 이동 단말(100)이 HTTP 응답 1의 수신을 완료하는 시점과 HTTP 요청 2를 송신하는 시점 사이의 시간을 최소화할 필요가 있다.
만일 상기 프록시 캐쉬(114)가 HTTP 요청에 대해 미리 알 수 있다면, 상기 이동 단말(100)로부터 상기 프록시 캐쉬(114)로 해당 HTTP 요청을 수신하지 않아도 상기 이동 단말(100)로 해당 객체들을 전송할 수 있다. 이렇게 상기 이동 단말(100)의 HTTP 요청 없이 상기 이동 단말(100)로 객체들을 송신하는 방식을 PUSH 방식이라 한다.
웹 어플리케이션(web application)의 경우 HTML 문서를 해석하면 여러 개의 임베디드 객체들이 존재하는 경우가 많다. 따라서 상기 프록시 캐쉬(114)에 사용자 에이전트(user agent) 기능을 포함시켜 PUSH 방식이 사용될 수 있도록 한다. 상기 프록시 캐쉬(114)는 PUSH 방식이 수행될 것임을 나타내는 정보(이하 'PUSH 시작 정보'라 칭함)를 최초의 HTTP 응답에 포함시켜 상기 이동 단말(100)로 송신한다. 여기서 상기 PUSH 시작 정보는 HTTP 응답 태그(tag)의 형태로 상기 HTTP 응답에 포함될 수 있다. 상기 프록시 캐쉬(114)는 상기 최초의 HTTP 응답을 송신한 후, DRX 주기를 변경해가며 임베디드 객체들을 이동 단말(100)로 PUSH 한다. 이에 대한 구체적인 내용을 이하 도 5a 및 도 5b를 참조하여 설명하기로 한다.
도 5a 및 도 5b는 본 발명의 실시 예에 따른 무선 통신 시스템에서 DRX 방식을 사용하여 PUSH 동작을 수행하는 과정을 나타낸 신호 흐름도이다. 도 5b에 도시된 과정은 도 5a에 도시된 과정에 이어 수행되는 과정을 나타낸다.
먼저 도 5a를 참조하면, 이동 단말(100)은 500 단계에서 URL 요청을 기지국(112)으로 송신한다. 상기 URL 요청은 상기 기지국(112) 및 프록시 캐쉬(114)를 통해 웹 서버(116)로 송신된다. 여기서 상기 프록시 캐쉬(114)는 상기 URL 요청이 수신되면, 502 단계에서 DRX 주기가 설정되지 않았음을 나타내는 정보를 상기 기지국(112)을 통해 이동 단말(100)로 송신한다.
상기 웹 서버(116)는 504 단계에서 상기 URL 요청에 따른 HTML 파일을 상기 프록시 캐쉬(114)로 송신한다. 그러면 상기 프록시 캐쉬(114)는 506 단계에서 PUSH 동작이 수행될 것임을 나타내는 PUSH 시작 정보를 HTML 파일과 함께 상기 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 상기 PUSH 시작 정보 및 HTML 파일이 상기 이동 단말(100)로 송신한다.
상기 프록시 캐쉬(114)는 상기 504 단계에서 수신된 HTML 파일을 해석하여 상기 이동 단말(100)로 송신해야 할 임베디드 객체들이 존재하는지 여부를 판단한다. 상기 프록시 캐쉬(114)는 상기 임베디드 객체들이 존재하는 경우, 508, 510, 512 단계에서 각각 상기 임베디드 객체들을 제공해줄 것을 요청하기 위한 임베디드 HTTP 요청 1, 2, 3을 상기 웹 서버(116)로 송신한다. 그리고 상기 프록시 캐쉬(114)는 상기 임베디드 HTTP 요청 1의 송신이 시작되면, 제1 DRX 주기(515)를 설정한다. 상기 제1 DRX 주기(515)는 앞서 도 4a 및 도 4b에서 설명한 바와 유사한 방식으로 설정될 수 있으므로 그 상세한 설명은 생략하도록 한다.
상기 프록시 캐쉬(114)는 514 단계에서 상기 설정된 제1 DRX 주기(515)에 대한 정보를 상기 기지국(112)으로 송신한다. 그리고 상기 기지국(112)은 상기 설정된 제1 DRX 주기(515)에 대한 정보를 상기 이동 단말(100)로 송신한다. 그러면 상기 이동 단말(100)은 상기 설정된 제1 DRX 주기(515)에 대한 정보를 근거로 제1 DRX 주기(515) 동안 슬립 모드로 동작한다.
상기 이동 단말(100)이 슬립 모드로 동작하는 동안, 상기 프록시 캐쉬(114)는 516, 518, 520 단계에서 상기 웹 서버(116)로부터 상기 임베디드 HTTP 요청 1, 2, 3에 대한 응답으로 임베디드 HTTP 응답 1, 2, 3-1(HTTP 응답 3에 대한 세그먼트)을 수신한다. 그리고 상기 프록시 캐쉬(114)는 상기 임베디드 HTTP 응답 1, 2, 3-1을 상기 기지국(112)으로 송신한다. 상기 기지국(112)은 521 단계에서 상기 제1 DRX 주기(515)가 완료되는 시점에 상기 이동 단말(100)로 상기 임베디드 HTTP 응답 1, 2, 3-1을 송신한다.
상기 제1 DRX 주기(515)가 완료되면, 상기 프록시 캐쉬(114)는 520 단계에서 제2 DRX 주기(525)를 설정한다. 상기 제2 DRX 주기(525)는 앞서 도 4a 및 도 4b에서 설명한 바와 유사한 방식으로 설정될 수 있으므로 그 상세한 설명은 생략하도록 한다. 상기 프록시 캐쉬(114)는 522 단계에서 상기 설정된 제2 DRX 주기(525)에 대한 정보를 상기 기지국(112)으로 송신한다. 그리고 상기 기지국(112)은 상기 설정된 제2 DRX 주기(525)에 대한 정보를 상기 이동 단말(100)로 송신한다. 그러면 상기 이동 단말(100)은 상기 설정된 제2 DRX 주기(525)에 대한 정보를 근거로 제2 DRX 주기(525) 동안 슬립 모드로 동작한다.
상기 이동 단말(100)이 슬립 모드로 동작하는 동안, 상기 프록시 캐쉬(114)는 다음과 같은 동작을 수행한다. 즉, 상기 프록시 캐쉬(114)는 524 단계에서 상기 임베디드 요청 3에 대응하여 추가적으로 상기 이동 단말(100)로 송신되어야 할 HTTP 응답 3-2(HTTP 응답 3에 대한 세그먼트)를 상기 웹 서버(116)로부터 수신한다. 그리고 상기 프록시 캐쉬(114)는 상기 수신된 HTTP 응답 3-2를 상기 기지국(112)으로 송신한다.
상기 프록시 캐쉬(114)는 526 단계에서 임베디드 HTTP 요청 4를 상기 웹 서버(116)로 송신한다. 그리고 상기 프록시 캐쉬(114)는 528 단계에서 상기 임베디드 HTTP 요청 4에 대한 응답으로 임베디드 HTTP 응답 4-1(HTTP 응답 4에 대한 세그먼트)을 수신한다. 상기 프록시 캐쉬(114)는 상기 수신된 HTTP 응답 4-1을 상기 기지국(112)으로 송신한다. 상기 기지국(112)은 상기 제2 DRX 주기(525)가 완료되면, 530 단계에서 상기 HTTP 응답 3-2(HTTP 응답 3에 대한 세그먼트) 및 상기 HTTP 응답 4-1을 상기 이동 단말(100)로 송신한다.
이어 도 5b를 참조하면, 상기 프록시 캐쉬(114)는 532 단계에서 상기 웹 서버(116)로부터 임베디드 HTTP 응답 4-2(HTTP 응답 4에 대한 세그먼트)를 수신하여 상기 기지국(112)으로 송신한다. 그리고 상기 프록시 캐쉬(114)는 상기 이동 단말(100)로 송신해야 할 임베디드 HTTP 응답의 수가 임계값 미만인 경우, 534 단계에서 DRX 주기가 설정되지 않았음을 나타내는 정보를 상기 기지국(112)을 통해 이동 단말(100)로 송신한다.
한편, 상기 프록시 캐쉬(114)는 536 단계 및 538 단계에서 임베디드 HTTP 요청 5 및 6을 상기 웹 서버(116)로 송신하고, 540 및 542 단계에서 상기 임베디드 HTTP 응답 5 및 6을 수신한다. 그리고 상기 프록시 캐쉬(114)는 상기 임베디드 HTTP 응답 5 및 6을 상기 기지국(112)으로 송신한다. 여기서 상기 이동 단말(100)에서는 DRX 동작을 수행하기 않기 때문에 상기 기지국(112)은 상기 임베디드 HTTP 응답 5 및 6을 수신한 즉시 상기 이동 단말(100)로 송신한다.
상기와 같이 해당 HTML 파일에 포함된 임베디드 객체들이 모두 상기 이동 단말(100)로 전달되면, 상기 프록시 캐쉬(114)는 544 단계에서 PUSH 동작이 종료될 것임을 나타내는 PUSH 종료 정보를 상기 기지국(112)을 통해 상기 이동 단말(100)로 송신한다. 상기 PUSH 종료 정보는 상기 PUSH 시작 정보와 유사하게 HTTP 응답 태그의 형태로 HTTP 응답에 포함되어 송신될 수 있다.
다음으로, 도 6a를 참조하여 도 5a 및 도 5b와 같은 과정이 수행되는 경우의 상기 프록시 캐쉬(114)의 동작을 설명하기로 한다.
도 6a는 본 발명의 실시 예에 따른 무선 통신 시스템에서 프록시 캐쉬가 DRX 방식을 사용하여 PUSH 동작을 수행하는 과정을 나타낸 순서도이다.
도 6a를 참조하면, 600 단계에서 프록시 캐쉬(114)는 이동 단말(100)로부터 송신된 HTTP 요청을 수신한다. 상기 프록시 캐쉬(114)와 이동 단말(100) 간의 통신은 앞서 살펴본 바와 같이 기지국(112)을 통해 수행된다. 상기 프록시 캐쉬(114)는 602 단계에서 상기 HTTP 요청을 웹 서버(116)로 송신하고, 상기 HTTP 요청에 따라 상기 웹 서버(116)로부터 수신해야 할 임베디드 객체들이 존재하는지 판단한다. 상기 프록시 캐쉬(114)는 상기 수신해야 할 임베디드 객체들이 존재하지 않는 경우 622 단계로 진행하여 일반적인 프록시 동작을 수행한다.
그리고 상기 프록시 캐쉬(114)는 상기 수신해야 할 임베디드 객체들이 존재하는 경우, 608 단계에서 사용자 에이전트 기능을 수행할지 여부를 판단한다. 여기서 상기 사용자 에이전트 기능이란 본 발명의 실시 예에서 제안하는 동작을 수행하기 위한 기능을 나타내며, 일 예로 PUSH 동작을 수행하기 위한 기능을 나타낸다.
상기 프록시 캐쉬(114)는 상기 사용자 에이전트 기능을 수행하지 않을 경우 622 단계로 진행하여 일반적인 프록시 동작을 수행한다. 이와 달리 상기 프록시 캐쉬(114)는 상기 사용자 에이전트 기능을 수행할 경우, 610 단계로 진행하여 HTTP 응답 헤더에 PUSH 시작 정보를 포함시켜 상기 이동 단말(100)로 송신한다. 이어 상기 프록시 캐쉬(114)는 612 단계에서 상기 웹 서버(116)로 임베디드 객체들을 제공해줄 것을 요청하는 HTTP 요청을 송신한다.
그리고 상기 프록시 캐쉬(114)는 614 단계에서 DRX 주기를 설정한다. 상기 프록시 캐쉬(114)는 임베디드 객체들의 수에 비례하여 상기 DRX 타이머를 증가시킬 수 있다. 즉, 상기 프록시 캐쉬(114)는 상기 임베디드 객체들의 수가 많으면 상기 DRX 타이머를 늘려 상기 DRX 주기를 증가시키고, 상기 임베디드 객체들의 수가 적으면 상기 DRX 타이머를 줄여 상기 DRX 주기를 감소시키거나 해제한다.
다른 방법으로, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)로 송신할 임베디드 객체들의 총 파일 사이즈에 비례하도록 상기 DRX 주기를 증가시킬 수 있다. 즉, 상기 프록시 캐쉬(114)는 상기 총 파일 사이즈가 크면 상기 DRX 타이머를 늘려 상기 DRX 주기를 증가시키고, 상기 총 파일 사이즈가 작으면 상기 DRX 타이머를 줄여 상기 DRX 주기를 감소시키거나 해제한다.
또 다른 방법으로 상기 프록시 캐쉬(114)는 임베디드 객체들의 중요도에 따라 상기 DRX 주기를 설정할 수 있다. 즉, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)로 송신할 임베디드 객체들이 광고나 배너 등과 같이 중요도가 낮은 객체들인 경우, 상기 DRX 타이머를 늘려 DRX 주기를 증가시키는 것도 가능하다.
상기와 같은 방법으로 DRX 주기가 설정되면, 상기 프록시 캐쉬(114)는 상기 설정된 DRX 주기에 대한 정보를 상기 이동 단말(100)로 송신한다. 그리고 상기 프록시 캐쉬(114)는 616 단계에서 상기 웹 서버(116)로부터 임베디드 객체들을 수신하고, 618 단계에서 상기 임베디드 객체들을 PUSH 방식을 사용하여 상기 이동 단말(100)로 송신한다. 즉, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)로부터 추가적인 HTTP 요청을 수신하지 않은 상태에서, 상기 웹 서버(116)로부터 임베디드 객체들을 수신하고 상기 수신된 임베디드 객체들을 상기 DRX 주기가 종료되는 시점에 상기 이동 단말(100)에 한번에 송신되도록 하는 PUSH 동작을 수행한다.
상기 프록시 캐쉬(114)는 해당 임베디드 객체들이 모두 송신된 경우, 620 단계에서 HTTP 응답 헤더에 PUSH 종료 정보를 포함시켜 상기 이동 단말(100)로 송신하고, 사용자 에이전트 기능을 종료한다.
한편, 본 발명의 실시 예에 따라 상기 프록시 캐쉬(114)는 PUSH 동작을 수행할 때 TCP 연결(connection)의 수를 증가시키는 것을 고려해볼 수 있다. 상기 TCP 연결은 상기 이동 단말(100)과 상기 프록시 캐쉬(114) 사이의 연결 혹은 상기 이동 단말(100)과 상기 웹 서버(116) 사이의 연결이 될 수 있다. 상기 TCP 연결의 수가 증가될 경우 상기 TCP 연결의 수가 증가되기 전에 비해 보다 넓은 대역폭(bandwidth)이 사용될 수 있다. 또한 특별한 기술이 사용되지 않는 한, 하나의 TCP 연결은 한번에 하나의 임베디드 객체만을 송신하기 위해 사용될 수 밖에 없으므로 TCP 연결의 수가 증가될 경우 다수의 임베디드 객체가 한번에 송신되는 것이 가능해진다. 따라서 본 발명의 실시 예에서 프록시 캐쉬(114)는 다음 도 6b에 나타난 바와 같은 동작을 수행함으로써 네트워크 상의 트래픽 처리량이 증가될 수 있도록 한다.
도 6b는 본 발명의 실시 예에 따른 무선 통신 시스템에서 프록시 캐쉬가 TCP 연결 수를 증가시켜 PUSH 동작을 수행하는 과정을 나타낸 순서도이다.
도 6b를 참조하면, 601 단계에서 프록시 캐쉬(114)는 이동 단말(100)로부터 송신된 HTTP 요청을 수신한다. 상기 프록시 캐쉬(114)와 이동 단말(100) 간의 통신은 기지국(112)을 통해 수행될 수 있다. 상기 프록시 캐쉬(114)는 603 단계에서 상기 HTTP 요청을 웹 서버(116)로 송신하고, 상기 HTTP 요청에 따라 상기 웹 서버(116)로부터 수신해야 할 임베디드 객체들이 존재하는지 판단한다. 상기 프록시 캐쉬(114)는 상기 수신해야 할 임베디드 객체들이 존재하지 않는 경우 623 단계로 진행하여 일반적인 프록시 동작을 수행한다.
그리고 상기 프록시 캐쉬(114)는 상기 수신해야 할 임베디드 객체들이 존재하는 경우, 608 단계로 진행하여 사용자 에이전트 기능을 수행할지 여부를 판단한다. 여기서 상기 사용자 에이전트 기능이란 본 발명의 실시 예에서 제안하는 동작을 수행하기 위한 기능을 나타내며, 일 예로 PUSH 동작을 수행하기 위한 기능을 나타낸다.
상기 프록시 캐쉬(114)는 상기 사용자 에이전트 기능을 수행하지 않을 경우 623 단계로 진행하여 일반적인 프록시 동작을 수행한다. 이와 달리 상기 프록시 캐쉬(114)는 상기 사용자 에이전트 기능을 수행할 경우, PUSH 동작을 수행할 것을 결정한다. 그리고 상기 프록시 캐쉬(114)는 611 단계에서 상기 PUSH 동작을 위해 사용할 TCP 연결 개수(즉, 임베디드 객체 송신을 위해 사용할 TCP 연결 개수)를 결정한다. 이때, 상기 프록시 캐쉬(114)는 네트워크 상의 처리량 증대를 위해 TCP 연결 개수를 증가시킬 수 있다. 예를 들어, 상기 프록시 캐쉬(114)는 임베디드 객체들의 수에 비례하여 상기 TCP 연결 개수를 증가시킬 수 있다. 즉, 상기 프록시 캐쉬(114)는 상기 임베디드 객체들의 수가 많으면 상기 TCP 연결 개수를 임계값 이상 큰 값으로 결정하고, 상기 임베디드 객체들의 수가 적으면 상기 TCP 연결 개수를 임계값 미만의 작은 값으로 결정할 수 있다.
다른 방법으로, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)로 송신할 임베디드 객체들의 총 파일 사이즈에 비례하도록 상기 TCP 연결 개수를 증가시킬 수 있다. 즉, 상기 프록시 캐쉬(114)는 상기 총 파일 사이즈가 크면 TCP 연결 개수를 증가시켜, 하나의 파일을 다수의 세그먼트로 분할한 후 각 세그먼트를 다수의 TCP 연결 각각을 통해 이동 단말(100)로 송신할 수 있다. 상기 다수의 TCP 연결을 통해 송신된 각 세그먼트는 상기 이동 단말(100)에서 다시 하나의 파일로 조립될 수 있다. 상기 총 파일 사이즈가 작으면 상기 TCP 연결 개수는 작은 값으로 결정되어도 무방하다. 한편 상기 프록시 캐쉬(114)는 상기 TCP 연결 개수를 동적으로 증가시키거나 감소시킬 수 있다. 상기 프록시 캐쉬(114)는 상기 웹 서버(116)로부터 임베디드 객체를 수신할 때 기존의 예상했던 파일 사이즈 등이 변경되었는지 여부를 판단할 수 있다. 따라서 상기 프록시 캐쉬(114)는 TCP 연결 개수를 동적으로 늘리거나 줄이도록 상기 이동 단말(100)에게 요청할 수 있다.
또 다른 방법으로 상기 프록시 캐쉬(114)는 임베디드 객체들의 중요도에 따라 상기 TCP 연결 개수 결정할 수 있다. 즉, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)로 송신할 임베디드 객체들이 광고나 배너 등과 같이 중요도가 낮은 객체들인 경우, TCP 연결 개수를 임계값 미만의 작은 값으로 결정할 수 있다. 혹은 상기 프록시 캐쉬(114)는 이미 사용자가 비디오 재생시에 충분한 버퍼링이 확보가 되지 않아서 긴급히 많은 임베디드 객체들을 송신하기 위한 PUSH 동작을 수행할 필요가 있다면, 하나의 파일을 다수개의 세그먼트로 분할하여 다수의 TCP 연결을 통해 상기 이동 단말(100)로 송신할 수 있다. 이 경우 네트워크 대역폭이 확장되어 상기 이동 단말(100)로의 송신 속도는 가속화될 수 있다.
상기와 같은 방법으로 TCP 연결 개수가 결정되면, 상기 프록시 캐쉬(114)는 613 단계에서 HTTP 응답 헤더에 PUSH 시작 정보와 함께, 상기 결정된 TCP 연결 개수에 대한 정보를 포함시켜 상기 이동 단말(100)로 송신한다. 그러면 상기 이동 단말(100)은 상기 PUSH 동작이 시작됨을 인지함과 아울러, 상기 TCP 연결 개수에 대응되는 수만큼의 TCP 연결을 생성하기 위한 동작을 수행할 수 있다.
한편, 상기 프록시 캐쉬(114)는 상기 HTTP 응답 헤더에 상기 프록시 캐쉬(114)의 레플리카(replica) 프록시 캐쉬의 IP 정보를 추가적으로 포함시켜 상기 이동 단말(100)로 송신할 수 있다. 상기 레플리카 프록시 캐쉬는 상기 프록시 캐쉬(114)와 협력하여 상기 이동 단말(100)로 웹 서비스를 제공하는 프록시 캐쉬를 나타낸다. 상기 레플리카 프록시 캐쉬는 상기 프록시 캐쉬(114)에 접속한 이동 단말이 임계값 이상 많은 경우 사용되거나, 상기 프록시 캐쉬(114)와 이동 단말(100) 간 혼합(congestion)이 생기거나, 여러 네트워크 경로를 이용하여 최대 네트워크 대역폭을 이용하고자 하는 경우 사용될 수 있다. 그리고 상기 레플리카 프록시 캐쉬는 상기 프록시 캐쉬(114)와 상이한 IP 주소를 가지며 다수개가 존재할 수 있다.
예를 들어 2개의 레플리카 프록시 캐쉬가 존재하고 상기 TCP 연결 개수가 6개로 결정된 경우, 상기 프록시 캐쉬(114)는 총 6개의 TCP 연결 중 2개는 상기 프록시 캐쉬(114)의 IP 주소(일 예로, 30.4.5.6)를 기반으로 생성하고, 상기 6개의 TCP 연결 중 다른 2개는 제1레플리카 프록시 캐쉬의 IP 주소(일 예로, 10.1.2.3)를 기반으로 생성하고, 상기 6개의 TCP 연결 중 나머지 2개는 제2레플리카 프록시 캐쉬의 IP 주소(일 예로, 20.30.40.50)를 기반으로 생성하도록, 상기 HTTP 응답 헤더에 상기 제1 및 제2 레플리카 프록시 캐쉬의 IP 주소에 대한 정보를 포함시켜 상기 이동 단말(100)로 송신한다.
그러면 상기 이동 단말(100)은 상기 HTTP 응답 헤더에 포함된 정보를 근거로, PUSH 동작이 시작됨을 판단함과 아울러 상기 프록시 캐쉬(114) 및 상기 제1 및 제2 레플리카 프록시 캐쉬의 IP 주소를 사용하여 상기 결정된 TCP 연결 개수만큼 TCP 연결을 생성할 수 있게 된다.상기 프록시 캐쉬(114)는 615 단계에서 상기 웹 서버(116)로부터 임베디드 객체들을 수신하고, 617 단계에서 상기 임베디드 객체들을 PUSH 방식을 사용하여 상기 이동 단말(100)로 송신한다. 이때 상기 프록시 캐쉬(114)와 함께 상기 제1 및 제2 레플리카 프록시 캐쉬도 상기 임베디드 객체들을 PUSH 방식을 사용하여 상기 이동 단말(100)로 송신할 수 있다. 일 예로, 상기 제1 및 제2 레플리카 프록시 캐쉬는 상기 프록시 캐쉬(114)가 지정한 임베디드 객체들을 PUSH 방식을 사용하여 상기 이동 단말(100)로 송신할 수 있다. 여기서, 상기 임베디드 객체들은 상기 TCP 연결 개수에 대응되는 수만큼의 TCP 연결을 사용하여 송신되어 상기 이동 단말(100)은 좀 더 빠르게 웹 서비스를 제공받을 수 있게 된다.
상기 프록시 캐쉬(114)는 해당 임베디드 객체들이 모두 송신된 경우, 621 단계에서 HTTP 응답 헤더에 PUSH 종료 정보를 포함시켜 상기 이동 단말(100)로 송신하고, 사용자 에이전트 기능을 종료한다.
도 7a 및 도 7b는 본 발명의 실시 예에 따른 무선 통신 시스템에서 DRX 방식을 사용하여 PUSH 동작을 수행하는 또 다른 과정을 나타낸 신호 흐름도이다.
먼저 도 7a 및 도 7b에서 기지국(112)과 프록시 캐쉬(114) 사이의 과정을 제외한 나머지 과정은 도 5a 및 도 5b에 도시된 과정과 동일하므로 그 상세한 설명은 생략하도록 한다. 도 7a 및 도 7b에서는 상기 기지국(112)이 상기 이동 단말(100)로 HTTP 응답을 송신하는 것과 유사하게, 상기 프록시 캐쉬(114)는 DRX 주기가 종료되는 시점을 고려하여 상기 기지국(112)으로 다수의 HTTP 응답을 한번에 송신한다.
구체적으로, 700 단계에서 상기 프록시 캐쉬(114)는 제1 DRX 주기(515)가 종료되는 시점을 고려하여, 웹 서버(116)로부터 수신한 임베디드 HTTP 응답 1, 2, 3-1을 하나로 묶어 상기 기지국(112)으로 송신한다. 그리고 710 단계에서 상기 프록시 캐쉬(114)는 제2 DRX 주기(525)가 종료되는 시점을 고려하여, 상기 웹 서버(116)로부터 수신한 임베디드 HTTP 응답 3-2, 4-1을 하나로 묶어 상기 기지국(112)으로 송신한다.
이처럼 다수의 HTTP 응답을 한 번에 송신하도록 하기 위해서는 큰 용량의 메모리가 필요하다. 상기 프록시 캐쉬(114)에서는 하드 디스크와 같은 큰 용량의 메모리가 사용될 수 있으므로, 상기 프록시 캐쉬(114)는 도 7a 및 도 7b에 나타난 바와 같이 다수의 HTTP 응답을 한 번에 송신하는 동작을 수행하는데 적합하다.
이하 도 8을 참조하여 도 7a 및 도 7b와 같은 과정이 수행되는 경우의 상기 프록시 캐쉬(114)의 동작을 설명하기로 한다.
도 8은 본 발명의 실시 예에 따른 무선 통신 시스템에서 프록시 캐쉬가 DRX 방식을 사용하여 PUSH 동작을 수행하는 또 다른 과정을 나타낸 순서도이다.
도 8을 참조하면, 상기 프록시 캐쉬(114)는 800 단계에서 기지국(112)으로부터 이동 단말(100)의 DRX 주기(DRX 타이머)에 대한 정보를 수신한다. 앞서 설명한 바와 같이 상기 DRX 주기는 상기 프록시 캐쉬(114)가 결정하여 상기 기지국(112)으로 송신하지만, 상기 기지국(112)이 상기 DRX 주기를 그대로 사용한다는 보장이 없기 때문에(예를 들어, 상기 기지국(112)에서 화상 통화 트래픽을 송신하는 중이라면, DRX 주기는 다른 값으로 설정될 것임), 상기 프록시 캐쉬(114)는 기지국(112)으로부터 이동 단말(100)의 DRX 주기에 대한 정보를 수신한다.
상기 프록시 캐쉬(114)는 802 단계에서 웹 서버(116)로부터 임베디드 객체들을 수신하고, 804 단계에서 상기 DRX 주기가 종료되었는지 여부를 판단한다. 상기 프록시 캐쉬(114)는 상기 DRX 주기가 종료된 경우, 804 단계로 진행하여 상기 이동 단말(100)의 채널 상태 정보를 상기 기지국(112)으로부터 수신한다. 그리고 상기 프록시 캐쉬(114)는 808 단계에서 상기 수신된 채널 상태 정보를 기반으로 상기 이동 단말(100)의 채널 상태가 임계값 이상인지 여부를 판단한다.
상기 프록시 캐쉬(114)는 상기 이동 단말(100)의 채널 상태가 임계값 이상인 경우, 810 단계로 진행하여 상기 수신된 임베디드 객체들을 상기 기지국(112)으로 송신한다. 그리고 상기 프록시 캐쉬(114)는 상기 이동 단말(100)의 채널 상태가 임계값 미만인 경우, 804 단계로 되돌아가 다음 DRX 주기의 종료 시점을 판단한다.
도 8에 도시된 바와 같이, DRX 주기의 종료 시점이 되었더라도 상기 이동 단말(100)의 채널 상태가 좋지 않은 경우 해당 임베디드 객체들을 송신하지 않고 다음 DRX 주기의 종료 시점을 기다릴 경우 자원의 효율성은 높아지게 된다. 예를 들어 해당 임베디드 객체가 비디오인 경우, 상기 프록시 캐쉬(114)는 상기 비디오에 대한 프레임 정보(frame information)를 확인할 수 있으므로 이동 단말(100)의 버퍼량을 기반으로 프레임 송신 동작을 수행할 수 있다.
만약 상기 이동 단말(100)의 버퍼에 미리 설정된 값 이상의 프레임이 버퍼링되어 있다면, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)의 채널 상태가 좋은 경우에만 프레임 송신 동작을 수행할 수 있다. 이와 반대로 상기 이동 단말(100)의 버퍼에 미리 설정된 값 미만의 프레임이 버퍼링되어 있다면, 상기 프록시 캐쉬(114)는 상기 이동 단말(100)의 채널 상태가 나쁘더라도 프레임 송신 동작을 수행하는 것이 바람직하다.
상기 이동 단말(100)의 채널 상태를 고려하여 해당 DRX 주기에 임베디드 객체의 송신을 스킵(skip)하는 동작은 상기 이동 단말(100)에서 제공되고 있는 웹 서비스(일 예로, 비디오)가 중지되지 않는 조건 하에 수행될 수 있으며, 다음과 같은 각 상황에 따라 다르게 수행될 수 있다.
(1) 해당 DRX 주기의 종료 시점이 되었더라도 이동 단말(100)의 채널 상태가 나쁜 경우 임베디드 객체의 송신을 스킵한다.
(2) 비디오의 경우에는 이동 단말(100)의 재생 시간(playtime)을 고려한 버퍼량이 적은 경우(일 예로, 상기 버퍼량이 1초 재생 가능한 분량인 경우), 상기 이동 단말(100)의 채널 상태가 나쁘더라도 임베디드 객체를 송신한다. 그리고 상기 이동 단말(100)의 재생 시간을 고려한 버퍼량이 많은 경우(일 예로, 상기 버퍼량이 10초 재생 가능한 분량인 경우), 상기 이동 단말(100)의 채널 상태가 나쁘면 임베디드 객체의 송신을 스킵하고 상기 이동 단말(100)의 채널 상태가 좋으면 임베디드 객체를 송신한다.
(3) 임베디드 객체 송신 중에 송신 완료 시점이 얼마 남지 않은 것이 판단되면 상기 이동 단말(100)의 채널 상태가 나빠도 임베디드 객체를 송신함으로써 송신 완료 시점이 지연되지 않도록 한다.
(4) 상기 이동 단말(100)의 처리 능력을 알고 있다면 특정 파일들을 처리 하는 데에 어느 정도 시간이 걸리는지 추정할 수 있다. 따라서 상기 이동 단말(100)이 예를 들어 1초간 처리할 분량의 파일을 버퍼링 하고 있다면 상기 이동 단말(100)의 채널 상태가 나빠도 임베디드 객체를 송신하고, 상기 이동 단말(100)이 예를 들어 10초간 처리할 분량의 파일을 버퍼링 하고 있다면 상기 이동 단말(100)의 채널 상태가 나쁘면 임베디드 객체의 송신을 스킵하고 채널 상태가 좋아진 경우 임베디드 객체를 송신한다.
도 9는 본 발명의 실시 예에 따른 프록시 캐쉬와 이동 단말 사이에 설정된 다수의 연결(multiple connection)을 이용한 PUSH 방식을 나타낸 도면이다.
도 9를 참조하면, 프록시 캐쉬(114)가 웹 서버(116)와 3개의 연결(즉, 제1연결(Connection 1)(900), 제2연결(Connection 2)(902) 및 제3연결(Connection 3) (904))을 사용하여 통신을 수행하고, 상기 프록시 캐쉬(114)와 상기 이동 단말(100) 간에는 오직 하나의 연결(Original Connection)(906)이 사용되는 경우, 상기 웹 서버(116)로부터 수신한 객체들을 상기 이동 단말(100)로 송신하기 위해서는 멀티플렉싱(multiplexing) 과정이 수행되어야 한다. 그러나 상기 프록시 캐쉬(114)와 상기 웹 서버(116) 간 연결 개수만큼 상기 프록시 캐쉬(114)와 상기 이동 단말(100) 사이에 연결(Add Connection 1(908), Add Connection 2(910))을 추가한다면, 멀티플렉싱 과정 없이 상기 웹 서버(116)로부터 수신한 객체들을 상기 이동 단말(100)로 송신할 수 있다.
상기 프록시 캐쉬(114)는 사용자 에이전트 기능을 수행한다는 것을 상기 이동 단말(100)에게 알려주기 때문에, 상기 이동 단말(100)은 다수의 연결을 미리 만들어 놓을 수 있다. 구체적으로 상기 프록시 캐쉬(114)는 사용자 에이전트 기능을 수행한다는 것을 상기 이동 단말(100)에게 알려주는 시점에 다수의 연결을 생성할 것을 지시하는 정보를 상기 이동 단말(100)로 송신할 수 있다.
즉, 상기 프록시 캐쉬(114)는 상기 HTTP 응답 헤더에 PUSH 시작 정보와 상기 다수의 연결을 생성할 것을 지시하는 정보를 포함시켜 상기 이동 단말(100)로 송신한다. 상기 다수의 연결을 생성할 것을 지시하는 정보는 상기 이동 단말(100)에서 생성해야 할 연결의 개수를 포함할 수 있으며, 태그 형태로 상기 HTTP 응답 헤더에 포함될 수 있다.
상기 이동 단말(100)은 상기 PUSH 시작 정보와 상기 다수의 연결을 생성할 것을 지시하는 정보가 포함된 HTTP 응답 정보가 수신되면, 해당 정보에 따라 다수의 연결을 생성하기 위한 동작을 수행한다. 도 9에서는 일 예로, 상기 이동 단말(100)과 프록시 캐쉬(114) 사이에 기본적으로 사용되던 기본 연결(Original Connection (906)) 이외에 2 개의 연결(Add Connection 1(908), Add Connection 2(910))이 추가되어 총 3개의 연결이 생성된 것을 보이고 있다.
상기와 같이 3개의 연결이 생성되면, 상기 프록시 캐쉬(114)와 상기 웹 서버(116) 간의 3개의 연결(제1연결(Connection 1)(900), 제2연결(Connection 2)(902) 및 제3연결(Connection 3)(904))은 상기 프록시 캐쉬(114)와 상기 이동 단말(100) 간의 3개의 연결(기본 연결(Original Connection)(906), 제1추가 연결(Add Connection 1(908)) 및 제2추가 연결(Add Connection 2(910))은 각각 일대일로 대응하여 사용될 수 있다.
즉, 상기 프록시 캐쉬(114)에서 상기 제1연결(Connection 1)(900)을 통해 수신된 객체 1의 세그먼트(Object 1 segment)(912)은 상기 기본 연결(Original Connection)(906)을 통해 상기 이동 단말(100)로 송신되며, 상기 프록시 캐쉬(114)에서 상기 제2연결(Connection 2)(902)을 통해 수신된 객체 2의 마지막 세그먼트(Object 2 segment end)(914) 및 객체 3의 시작 세그먼트(Object 3 segment begin)(916)는 상기 제1추가 연결(Add Connection 1(908)을 통해 상기 이동 단말(100)로 송신되며, 상기 프록시 캐쉬(114)에서 상기 제3연결(Connection 3)(904)을 통해 수신된 객체 4의 마지막 세그먼트(Object 4 segment end)(918), 객체 5(Object 5 segment)(920) 및 객체 6의 시작 세그먼트(Object 6 segment begin)(922)는 상기 제2추가 연결(Add Connection 2(910)을 통해 상기 이동 단말(100)로 송신된다.
도 10a 및 도 10b는 본 발명의 실시 예에 따른 이동 단말과 프록시 캐쉬 간 다수의 연결을 생성하는 과정을 나타낸 신호 흐름도이다. 도 10b에 도시된 과정은 도 10a에 도시된 과정에 이어 수행되는 과정을 나타낸다.
먼저 도 10a를 참조하면, 1000 단계에서 이동 단말(1000)은 HTTP 요청을 기지국(112)으로 송신한다. 그러면 상기 기지국(112)은 상기 HTTP 요청을 상기 프록시 캐쉬(114)로 송신하고, 상기 프록시 캐쉬(114)는 상기 HTTP 요청을 웹 서버(116)로 송신한다.
상기 프록시 캐쉬(114)는 상기 웹 서버(116)로부터 HTTP 응답이 수신되면, 1002 단계에서 상기 HTTP 응답 헤더에 PUSH 시작 정보와 다수의 연결을 생성할 것을 지시하는 연결 정보를 포함시켜 상기 기지국(112)으로 송신한다. 그리고 상기 기지국(112)은 상기 PUSH 시작 정보와 상기 연결 정보가 포함된 헤더를 포함하는 HTTP 응답을 상기 이동 단말(100)로 송신한다.
상기 연결 정보에는 생성해야 할 연결의 개수 정보가 포함되어 있기 때문에, 상기 이동 단말(100)은 1003 단계에서 상기 개수 정보를 근거로 다수의 연결을 생성하기 위한 동작을 수행한다. 상기 다수의 연결을 생성하는 동작은 일반적인 TCP 연결 동작과 유사하므로 그 상세한 설명은 생략하도록 한다.
상기 이동 단말(100)과 상기 프록시 캐쉬(114) 간에 생성된 다수의 연결 연결은 상기 프록시 캐쉬(114)와 상기 웹 서버(116) 간의 연결과 동일한 개수가 될 수 있다. 이는 각 장치 간 연결이 일대일로 대응될 경우 트래픽 송수신에 따른 효율이 높아지기 때문이다.
한편, 상기 프록시 캐쉬(114)는 상기 HTTP 요청에 따라 상기 웹 서버(116)로 요청해야 할 임베디드 객체들이 존재하는지 여부를 판단한다. 상기 프록시 캐쉬(114)는 상기 HTTP 요청에 따라 상기 웹 서버(116)로 요청해야 할 임베디드 객체들이 존재하는 경우 1004, 1006, 1008 단계에서 상기 웹 서버(116)로 상기 임베디드 객체들을 제공해줄 것을 요청하기 위한 임베디드 HTTP 요청 1, 2, 3을 각각 송신한다.
그리고 상기 프록시 캐쉬(114)는 1010 단계에서 상기 웹 서버(116)로부터 상기 임베디드 HTTP 요청 1에 대응되는 임베디드 HTTP 응답 1을 수신한다. 이어 상기 프록시 캐쉬(114)는 1011 단계에서 다수의 연결을 통한 PUSH 동작을 수행함으로써 상기 임베디드 HTTP 응답 1이 상기 이동 단말(100)로 송신될 수 있도록 한다. 앞서 설명한 바와 같이 상기 PUSH 동작은 DRX 주기에 따라 수행될 수 있다.
한편, 상기 DRX 주기 동안 상기 프록시 캐쉬(114)는 1012 단계에서 상기 웹 서버(116)로부터 상기 임베디드 HTTP 요청 2에 대응되는 임베디드 HTTP 응답 2를 수신한다. 그리고 상기 프록시 캐쉬(114)는 1014 단계에서 상기 웹 서버(116)로 상기 임베디드 HTTP 요청 4를 송신하고, 1016 단계에서 상기 웹 서버(116)로부터 상기 임베디드 HTTP 요청 3에 대응되는 임베디드 HTTP 응답 3을 수신한다. 이어 상기 프록시 캐쉬(114)는 1018 단계에서 다수의 연결을 통한 PUSH 동작을 수행함으로써 상기 임베디드 HTTP 응답 2 및 3이 해당 DRX 주기가 종료되는 시점에 상기 이동 단말(100)로 송신될 수 있도록 한다.
이어 도 10b를 참조하면, 다음 DRX 주기 동안 상기 프록시 캐쉬(114)는 1020 단계에서 상기 웹 서버(116)로부터 상기 임베디드 HTTP 요청 4에 대응되는 임베디드 HTTP 응답 4를 수신하고, 1022 및 1024단계에서 각각 상기 임베디드 HTTP 요청 5 및 6을 상기 웹 서버(116)로 송신한다. 이어 상기 프록시 캐쉬(114)는 1026 단계에서 상기 웹 서버(116)로부터 상기 임베디드 HTTP 요청 5에 대응되는 임베디드 HTTP 응답 5를 수신한다. 그리고 상기 프록시 캐쉬(114)는 1028 단계에서 다수의 연결을 통한 PUSH 동작을 수행함으로써 상기 임베디드 HTTP 응답 4 및 5가 해당 DRX 주기가 종료되는 시점에 상기 이동 단말(100)로 송신될 수 있도록 한다.
그 다음 DRX 주기 동안 상기 프록시 캐쉬(114)는 1030 단계에서 상기 웹 서버(116)로부터 상기 임베디드 HTTP 요청 6에 대응되는 임베디드 HTTP 응답 6을 수신한다. 그리고 상기 프록시 캐쉬(114)는 1032 단계에서 다수의 연결을 통한 PUSH 동작을 수행함으로써 상기 임베디드 HTTP 응답 6이 해당 DRX 주기가 종료되는 시점에 상기 이동 단말(100)로 송신될 수 있도록 한다.
한편, 임베디드 객체들이 모두 상기 이동 단말(100)로 송신되었거나 미리 설정된 개수보다 적은 임베디드 객체들이 상기 이동 단말(100)로 송신되어야 한다면, 상기 프록시 캐쉬(114)는 544 단계에서 PUSH 동작이 종료될 것임을 나타내는 PUSH 종료 정보가 상기 임베디드 HTTP 응답 6(혹은 별도의 HTTP 응답)에 포함될 수 있다. 이 경우, 1036 단계에서 PUSH 동작이 종료되어 그 이후에 송신되는 HTTP 응답은 DRX 주기와 관계없이 바로 상기 이동 단말(100)로 송신되게 된다.
한편 TCP 수신 버퍼(TCP receiving buffer)는 제한된 용량(일 예로 64KB)을 가지기 때문에, 상기 이동 단말(100)은 더 큰 용량의 임베디드 객체들을 한번에 수신하기 위하여 상기 TCP 수신 버퍼를 일시적으로 늘리거나, 추가적으로 TCP 연결을 생성하는 것도 가능하다.
도 11은 본 발명의 실시 예에 따른 이동 단말의 동작을 나타낸 순서도이다.
도 11을 참조하면, 이동 단말(100)은 1100 단계에서 HTTP 요청을 기지국(112)으로 송신한다. 그리고 상기 이동 단말(100)은 상기 기지국으로부터 HTTP 응답을 수신하고, 1104 단계에서 HTTP 응답 헤더에 PUSH 시작 정보 및 연결 정보가 포함되었는지 여부를 판단한다.
상기 이동 단말(100)은 상기 HTTP 응답 헤더에 PUSH 시작 정보 및 연결 정보가 포함되지 않은 경우, 1114 단계로 진행하여 일반적인 HTTP 요청 및 응답 송수신 과정을 수행한다. 그리고 상기 이동 단말(100)은 상기 HTTP 응답 헤더에 PUSH 시작 정보 및 연결 정보가 포함된 경우, 1106 단계로 진행하여 다수의 연결을 생성한다. 즉, 상기 이동 단말(100)은 상기 연결 정보에 포함된 연결 개수만큼 추가적인 연결을 생성한다. 그리고 상기 이동 단말(100)은 1108 단계에서 상기 다수의 연결을 통해 해당 DRX 주기가 종료되는 시점에 HTTP 응답을 수신한다.
이어 상기 이동 단말(100)은 1110 단계에서 상기 HTTP 응답에 PUSH 종료 정보가 포함되었는지 여부를 판단하고, 상기 HTTP 응답에 PUSH 종료 정보가 포함된 경우 1112 단계에서 DRX 주기에 관계없이 HTTP 요청 및 응답을 송수신한다.
도 12는 본 발명의 실시 예에 따른 프록시 캐쉬의 블록 구성도이다.
도 12를 참조하면, 상기 프록시 캐쉬(114)는 제어부(1200), 송신부(1202), 수신부(1204) 및 메모리(1206)를 포함한다.
상기 송신부(1202) 및 수신부(1204)는 기지국(112) 및 웹 서버(116)와 통신을 수행한다. 그리고 상기 메모리(1206)는 상기 프록시 캐쉬(114)의 동작에 따라 생성되는 다양한 정보 및 송수신되는 신호 등을 저장한다.
상기 제어부(1200)는 상기 송신부(1202), 수신부(1204) 및 메모리(1206)를 제어하며, 특히 앞서 설명한 상기 프록시 캐쉬(114)의 동작(일 예로, DRX 주기를 설정하는 동작, PUSH 동작(사용자 에이전트 기능) 및 상기 이동 단말(100)에서 다수의 연결을 생성하도록 하는 동작 등)이 수행되도록 상기 구성부들을 제어한다.
도 13은 본 발명의 실시 예에 따른 이동 단말의 블록 구성도이다.
도 13을 참조하면, 상기 이동 단말(100)은 제어부(1300), 송신부(1302), 수신부(1304) 및 메모리(1306)를 포함한다.
상기 송신부(1302) 및 수신부(1304)는 기지국(112)과 통신을 수행한다. 그리고 상기 메모리(1306)는 상기 이동 단말(100)의 동작에 따라 생성되는 다양한 정보 및 송수신되는 신호 등을 저장한다.
상기 제어부(1300)는 상기 송신부(1302), 수신부(1304) 및 메모리(1306)를 제어하며, 특히 앞서 설명한 상기 이동 단말(100)의 동작(일 예로, DRX 주기에 따라 동작 모드를 변경하는 동작, 다수의 연결을 생성하는 동작 등)이 수행되도록 상기 구성부들을 제어한다.
전술한 바와 같은 본 발명의 실시 예에 따를 경우, 이동 단말은 배터리 전력을 최소로 하면서 보다 빠른 웹 서비스를 제공받을 수 있게 된다. 또한 프록시 캐쉬가 사용자 에이전트 기능을 수행할 경우, PUSH 동작이 수행됨에 따라 상기 이동 단말이 다수의 HTTP 응답을 한번에 수신할 수 있으므로 송신 효율은 향상될 수 있다. 그리고 상기 프록시 캐쉬가 웹 객체들을 미리 다운로드 받아 상기 이동 단말에게 전달하므로, 상기 이동 단말의 사용자는 유선 망 사용자와 거의 동일한 성능으로 웹 서비스를 제공받을 수 있다. 또한 상기 프록시 캐쉬와 상기 이동 단말 간 다수의 연결을 생성함으로써 상기 이동 단말의 연결에 대한 수신 버퍼량이 제한되어 있는 문제는 해결될 수 있다.
한편 본 발명의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 발명의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 발명의 범위는 설명된 실시 예에 국한되어 정해져서는 안되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (34)

  1. 무선 통신 시스템에서 프록시 캐쉬에 의해 웹 서비스를 제공하기 위한 방법에 있어서,
    이동 단말의 상기 웹 서비스를 위한 웹 페이지와 연관된 정보를 수신하는 단계;
    웹 서버로부터 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 수신하는 단계; 및
    상기 적어도 하나의 임베디드 객체의 크기에 기초하여 상기 이동 단말에 대한 위한 불연속 수신(Discontinuous Reception: DRX) 주기를 설정하는 단계를 포함하고,
    상기 DRX 주기에 기초하여 DRX 타이머가 종료되는 경우, 상기 적어도 하나의 임베디드 객체는 상기 이동 단말로 송신되는,
    무선 통신 시스템에서 프록시 캐쉬에 의해 웹 서비스를 제공하기 위한 방법.
  2. 제1항에 있어서,
    상기 DRX 주기를 설정하기 전에, PUSH 동작이 수행될 것을 나타내는 정보가 상기 이동 단말로 송신되고, 상기 PUSH 동작은 상기 적어도 하나의 임베디드 객체가 상기 이동 단말로부터의 요청의 수신 없이 상기 이동 단말로 전송되는 동작이고,
    상기 임베디드 객체의 송신이 완료되는 경우, 상기 PUSH 동작이 종료되는 것을 나타내는 정보가 상기 이동 단말로 송신되는,
    무선 통신 시스템에서 프록시 캐쉬에 의해 웹 서비스를 제공하기 위한 방법.
  3. 제1항에 있어서,
    상기 웹 페이지와 연관된 정보가 수신되면, 상기 이동 단말과 상기 프록시 캐쉬 사이에 추가적인 연결을 설정할 것을 지시하기 위한 메시지가 상기 이동 단말로 송신되고, 상기 이동 단말과 상기 프록시 캐쉬 사이의 연결들의 개수는 상기 프록시 캐쉬와 상기 웹 서버 사이의 접속들의 수와 동일한,
    무선 통신 시스템에서 프록시 캐쉬에 의해 웹 서비스를 제공하기 위한 방법.
  4. 제1항에 있어서,
    상기 이동 단말로부터 수신된 채널 상태 정보에 기초하여 상기 DRX 타이머가 종료되는 경우, 상기 적어도 하나의 임베디드 객체는 상기 이동 단말로 송신되고, 그리고 상기 웹 페이지와 연관된 정보는 상기 웹 페이지에 대한 URL(uniform resource locator) 정보를 포함하는,
    무선 통신 시스템에서 프록시 캐쉬에 의해 웹 서비스를 제공하기 위한 방법.
  5. 무선 통신 시스템에서 이동 단말에 의해 웹 서비스를 수신하기 위한 방법에 있어서,
    프록시 캐쉬를 포함하는 네트워크 엔티티로 웹 서비스를 위한 웹 페이지와 연관된 정보를 송신하는 단계;
    상기 네트워크 엔티티로부터 불연속 수신(DRX)와 연관된 정보를 수신하는 단계;
    DRX 타이머에 따른 주기 동안 슬립 모드에서 동작하는 단계;
    상기 DRX 타이머가 종료되는 경우, 상기 슬립 모드로부터 리스닝(listening) 모드로 전이(transition)하는 단계; 및
    상기 네트워크 엔티티로부터 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 수신하는 단계를 포함하고,
    상기 DRX 타이머는 DRX 주기에 기초하여 설정되고, 그리고
    상기 DRX 주기는 상기 적어도 하나의 임베디드 객체의 크기에 기초하여 상기 네트워크 엔티티에 의해 결정되는,
    무선 통신 시스템에서 이동 단말에 의해 웹 서비스를 수신하기 위한 방법.
  6. 제5항에 있어서,
    상기 네트워크 엔티티로부터, PUSH 동작이 수행될 것을 나타내는 정보를 수신하는 단계 ― 상기 PUSH 동작은 상기 적어도 하나의 임베디드 객체가 상기 이동 단말로부터의 요청의 수신 없이 상기 이동 단말로 전송되는 동작임 ―; 및
    상기 적어도 하나의 임베디드 객체의 수신이 완료되는 경우, 상기 프록시 캐쉬로부터 상기 PUSH 동작이 종료되는 것을 나타내는 정보를 수신하는 단계를 더 포함하는,
    무선 통신 시스템에서 이동 단말에 의해 웹 서비스를 수신하기 위한 방법.
  7. 제5항에 있어서,
    상기 웹 페이지와 연관된 정보를 송신한 이후, 상기 네트워크 엔티티로부터 상기 이동 단말과 상기 프록시 캐쉬 사이에 추가적인 연결을 설정할 것을 지시하기 위한 메시지를 수신하는 단계를 더 포함하고,
    상기 이동 단말과 상기 프록시 캐쉬 사이의 연결들의 개수는 상기 프록시 캐쉬와 웹 서버 사이의 접속들의 수와 동일하고,
    상기 적어도 하나의 임베디드 객체는 상기 웹 서버로부터 상기 프록시 캐쉬로 송신되는,
    무선 통신 시스템에서 이동 단말에 의해 웹 서비스를 수신하기 위한 방법.
  8. 제5항에 있어서,
    상기 적어도 하나의 임베디드 객체를 수신하는 단계는:
    상기 이동 단말의 채널 상태 정보를 상기 네트워크 엔티티로 송신하는 단계; 및
    상기 채널 상태 정보에 기초하여 상기 DRX 타이머가 종료되는 경우 상기 적어도 하나의 임베디드 객체를 수신하는 단계를 포함하고,
    상기 웹 페이지와 연관된 정보는 상기 웹 페이지에 대한 URL(uniform resource locator) 정보를 포함하는,
    무선 통신 시스템에서 이동 단말에 의해 웹 서비스를 수신하기 위한 방법.
  9. 무선 통신 시스템에서의 프록시 캐쉬에 있어서,
    이동 단말의 웹 서비스를 위한 웹 페이지와 연관된 정보를 수신하고; 그리고
    웹 서버로부터 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 수신하도록 구성되는,
    수신기; 및
    상기 적어도 하나의 임베디드 객체의 크기에 기초하여 상기 이동 단말에 대한 위한 불연속 수신(Discontinuous Reception: DRX) 주기를 설정하도록 구성되는 프로세서를 포함하고,
    상기 DRX 주기에 기초하여 DRX 타이머가 종료되는 경우, 상기 적어도 하나의 임베디드 객체는 상기 이동 단말로 송신되는,
    프록시 캐쉬.
  10. 제9항에 있어서,
    상기 DRX 주기를 설정하기 전에, PUSH 동작이 수행될 것을 나타내는 정보가 상기 이동 단말로 송신되고, 상기 PUSH 동작은 상기 적어도 하나의 임베디드 객체가 상기 이동 단말로부터의 요청의 수신 없이 상기 이동 단말로 전송되는 동작이고,
    상기 임베디드 객체의 송신이 완료되는 경우, PUSH 동작이 종료되는 것을 나타내는 정보가 상기 이동 단말로 송신되는,
    프록시 캐쉬.
  11. 제9항에 있어서,
    상기 웹 페이지와 연관된 정보가 수신되면, 상기 이동 단말과 상기 프록시 캐쉬 사이에 추가적인 연결을 설정할 것을 지시하기 위한 메시지가 상기 이동 단말로 송신되고, 상기 이동 단말과 상기 프록시 캐쉬 사이의 연결들의 개수는 상기 프록시 캐쉬와 상기 웹 서버 사이의 접속들의 수와 동일한,
    프록시 캐쉬.
  12. 제9항에 있어서,
    상기 이동 단말로부터 수신된 채널 상태 정보에 기초하여 상기 DRX 타이머가 종료되는 경우, 상기 적어도 하나의 임베디드 객체는 상기 이동 단말로 송신되고, 그리고 상기 웹 페이지와 연관된 정보는 상기 웹 페이지에 대한 URL(uniform resource locator) 정보를 포함하는,
    프록시 캐쉬.
  13. 무선 통신 시스템에서의 이동 단말에 있어서,
    프록시 캐쉬를 포함하는 네트워크 엔티티로 웹 서비스를 위한 웹페이지와 연관된 정보를 송신하고; 그리고
    상기 네트워크 엔티티로부터 불연속 수신(DRX)와 연관된 정보를 수신하도록 구성되는,
    송수신기; 및
    상기 이동 단말이 DRX 타이머에 따른 주기 동안 슬립 모드에서 동작하도록 제거하고;
    상기 DRX 타이머가 종료되는 경우, 상기 이동 단말이 상기 슬립 모드로부터 리스닝(listening) 모드로 전이(transition)하고; 그리고
    상기 네트워크 엔티티로부터 상기 웹 페이지에 포함된 적어도 하나의 임베디드 객체(embedded object)를 수신하도록 상기 송수신기를 제어하도록 구성되는,
    제어기를 포함하고,
    상기 DRX 타이머는 DRX 주기에 기초하여 설정되고, 그리고
    상기 DRX 주기는 상기 적어도 하나의 임베디드 객체의 크기에 기초하여 상기 네트워크 엔티티에 의해 결정되는,
    이동 단말.
  14. 제13항에 있어서,
    상기 송수신기는:
    상기 네트워크 엔티티로부터, PUSH 동작이 수행될 것을 나타내는 정보를 수신하고 ― 상기 PUSH 동작은 상기 적어도 하나의 임베디드 객체가 상기 이동 단말로부터의 요청의 수신 없이 상기 이동 단말로 전송되는 동작임 ―; 그리고
    상기 적어도 하나의 임베디드 객체의 수신이 완료되는 경우, 상기 프록시 캐쉬로부터 상기 PUSH 동작이 종료되는 것을 나타내는 정보를 수신하도록 구성되는,
    이동 단말.
  15. 제13항에 있어서,
    상기 제어기는, 상기 웹 페이지와 연관된 정보를 송신한 이후, 상기 네트워크 엔티티로부터 상기 이동 단말과 상기 프록시 캐쉬 사이에 추가적인 연결을 설정할 것을 지시하기 위한 메시지를 수신하기 위해 상기 송수신기를 제어하도록 구성되고,
    상기 이동 단말과 상기 프록시 캐쉬 사이의 연결들의 개수는 상기 프록시 캐쉬와 웹 서버 사이의 접속들의 수와 동일하고,
    상기 적어도 하나의 임베디드 객체는 상기 웹 서버로부터 상기 프록시 캐쉬로 송신되는,
    이동 단말.
  16. 제13항에 있어서,
    상기 제어기는 상기 송수신기가:
    상기 이동 단말의 채널 상태 정보를 상기 네트워크 엔티티로 송신하고; 그리고
    상기 채널 상태 정보에 기초하여 상기 DRX 타이머가 종료되는 경우 상기 적어도 하나의 임베디드 객체를 수신하기 위해 상기 송수신기를 제어하도록 구성되고,
    상기 웹 페이지와 연관된 정보는 상기 웹 페이지에 대한 URL(uniform resource locator) 정보를 포함하는,
    이동 단말.
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
  31. 삭제
  32. 삭제
  33. 삭제
  34. 삭제
KR1020120126859A 2012-11-09 2012-11-09 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치 KR102036579B1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020120126859A KR102036579B1 (ko) 2012-11-09 2012-11-09 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치
EP13853403.7A EP2918138B1 (en) 2012-11-09 2013-11-08 Method and apparatus for providing web service in wireless communication system
US14/076,063 US9794320B2 (en) 2012-11-09 2013-11-08 Method and apparatus for providing web service in wireless communication system
PCT/KR2013/010131 WO2014073902A1 (en) 2012-11-09 2013-11-08 Method and apparatus for providing web service in wireless communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020120126859A KR102036579B1 (ko) 2012-11-09 2012-11-09 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치

Publications (2)

Publication Number Publication Date
KR20140060132A KR20140060132A (ko) 2014-05-19
KR102036579B1 true KR102036579B1 (ko) 2019-10-28

Family

ID=50682774

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020120126859A KR102036579B1 (ko) 2012-11-09 2012-11-09 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치

Country Status (4)

Country Link
US (1) US9794320B2 (ko)
EP (1) EP2918138B1 (ko)
KR (1) KR102036579B1 (ko)
WO (1) WO2014073902A1 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103188653B (zh) * 2011-12-27 2016-06-08 华为终端有限公司 接收数据的方法、发送数据的方法、移动终端和服务器
KR20150084307A (ko) * 2014-01-13 2015-07-22 삼성전자주식회사 네트워크에서 웹 로딩 시간 제어 방법 및 장치
CN104159249B (zh) * 2014-07-30 2018-05-18 华为技术有限公司 一种业务数据管理的方法、装置及系统
US9813465B2 (en) * 2014-12-19 2017-11-07 Intel Corporation Network proxy for energy efficient video streaming on mobile devices
US10999795B2 (en) * 2016-10-06 2021-05-04 Qualcomm Incorporated Independent wakeups from deep sleep for broadcast and unicast service
CN108064443B (zh) * 2017-09-30 2021-08-06 达闼机器人有限公司 一种代理转发方法和装置、代理服务器和多级代理网络
WO2020000412A1 (en) * 2018-06-29 2020-01-02 Intel Corporation Transport layer connections for mobile communication networks

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090219844A1 (en) 2008-03-03 2009-09-03 Qualcomm Incorporated Access point with proxy functionality for facilitating power conservation in wireless client terminals
WO2011116819A1 (en) 2010-03-25 2011-09-29 Telefonaktiebolaget Lm Ericsson (Publ) Caching in mobile networks
WO2012037332A1 (en) 2010-09-16 2012-03-22 Qualcomm Incorporated Power conservation in wireless client terminals using proxy device

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7058691B1 (en) * 2000-06-12 2006-06-06 Trustees Of Princeton University System for wireless push and pull based services
US6820116B1 (en) * 2001-12-21 2004-11-16 Nokia Corporation Mobile browsing booster system
US6941310B2 (en) * 2002-07-17 2005-09-06 Oracle International Corp. System and method for caching data for a mobile application
US7953820B2 (en) 2002-09-11 2011-05-31 Hughes Network Systems, Llc Method and system for providing enhanced performance of web browsing
US20040255008A1 (en) 2003-04-21 2004-12-16 International Business Machines Corporation System for low power operation of wireless LAN
PL2090124T3 (pl) * 2006-10-27 2018-07-31 Interdigital Technology Corporation Sposób i urządzenie do usprawniania nieciągłego odbioru w systemach bezprzewodowych
JP4932521B2 (ja) * 2007-02-09 2012-05-16 株式会社エヌ・ティ・ティ・ドコモ 移動通信システムで使用される基地局装置及び方法
US9268871B2 (en) 2008-10-16 2016-02-23 Qualcomm Incorporated Methods and apparatus for obtaining content with reduced access times
US8886164B2 (en) * 2008-11-26 2014-11-11 Qualcomm Incorporated Method and apparatus to perform secure registration of femto access points
US8335175B2 (en) * 2010-04-07 2012-12-18 Qualcomm Incorporated Systems and methods for page delivery to a wireless client device in idle state
US9730037B2 (en) 2010-06-16 2017-08-08 Microsoft Corporation Cellular data communication for mobile devices
EP2398210B1 (en) * 2010-06-17 2016-11-16 Huawei Technologies Co., Ltd. Targeted mobile advertising via user proxy at femto AP
KR20120067856A (ko) * 2010-12-16 2012-06-26 한국전자통신연구원 단말의 저전력 운용을 위한 무선 통신 시스템 및 무선 통신 시스템의 동작 방법
EP2469789A1 (en) * 2010-12-22 2012-06-27 Research In Motion Limited Method and system for selectively performing proxy services
ES2556381T3 (es) * 2011-06-04 2016-01-15 Alcatel Lucent Un concepto de planificación
US9872332B2 (en) * 2011-11-22 2018-01-16 Telefonaktiebolaget L M Ericsson (Publ) Energy efficient operation for wireless access nodes in a low-load service area within a dense deployment of wireless access nodes
US20140334371A1 (en) * 2012-01-27 2014-11-13 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data by using plurality of carriers in mobile communication systems
CN103391549B (zh) * 2012-05-10 2018-04-06 中兴通讯股份有限公司 一种不连续接收的动态配置方法、终端和基站
JP6094297B2 (ja) * 2013-03-21 2017-03-15 富士通株式会社 無線端末装置、通信制御装置、及び無線通信方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090219844A1 (en) 2008-03-03 2009-09-03 Qualcomm Incorporated Access point with proxy functionality for facilitating power conservation in wireless client terminals
WO2011116819A1 (en) 2010-03-25 2011-09-29 Telefonaktiebolaget Lm Ericsson (Publ) Caching in mobile networks
WO2012037332A1 (en) 2010-09-16 2012-03-22 Qualcomm Incorporated Power conservation in wireless client terminals using proxy device

Also Published As

Publication number Publication date
US9794320B2 (en) 2017-10-17
EP2918138A4 (en) 2016-10-05
WO2014073902A1 (en) 2014-05-15
EP2918138B1 (en) 2018-10-31
US20140136604A1 (en) 2014-05-15
EP2918138A1 (en) 2015-09-16
KR20140060132A (ko) 2014-05-19

Similar Documents

Publication Publication Date Title
KR102036579B1 (ko) 무선 통신 시스템에서 웹 서비스 제공 방법 및 장치
US10587544B2 (en) Message processing method, processing server, terminal, and storage medium
EP2727416B1 (en) Technique for managing streaming media traffic at a network entity
US9338674B2 (en) Systems, structures and associated processes for optimization of state transitions within wireless networks
US8717890B2 (en) Application, usage and radio link aware transport network scheduler
KR102020363B1 (ko) 적응형 스트리밍을 이용한 미디어 세그먼트 송수신 방법 및 장치
US20160080529A1 (en) Method and device for sending requests
CN108063769B (zh) 一种内容服务的实现方法、装置及内容分发网络节点
US9866356B2 (en) Data distribution method and device
JP6132116B2 (ja) ビデオ品質のユーザ体験値を評価するための方法、デバイス、及びシステム
CN103125108B (zh) 建立发射控制协议连接的系统和方法
US10694503B2 (en) Tethering over a wireless communication channel
US10404774B2 (en) Mobile device and method for controlling transmission to web server in mobile device
CN104469394A (zh) 一种视频资源获取方法、后台服务器、视频客户端及系统
CN110572851A (zh) 一种数据上传方法、系统、装置及计算机可读存储介质
WO2015106524A1 (zh) 业务套餐使用情况的通知/发送方法及装置、服务器
US20150288734A1 (en) Adaptive leveraging of network information
WO2014194526A1 (zh) 移动网络数据资源获取方法、设备及系统
WO2014000506A1 (zh) 业务信息提供方法、装置及网络系统
EP2997489B1 (en) Method and device for efficient mobile data transmission
CN107786954B (zh) 一种无线传输中的方法和装置
KR100925644B1 (ko) 오브젝트 전송 시스템 및 그 제어방법
WO2016172967A1 (zh) 一种媒体流传输方法及装置
EP3043529A1 (en) System, method, and server for keeping wireless local area network terminal online all the time
KR101366031B1 (ko) 캐시 서버 관리 방법 및 그 장치

Legal Events

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