KR102141444B1 - 모바일 콘텐트 네트워크에서 데이터 전송 및 수신 장치 및 방법 - Google Patents

모바일 콘텐트 네트워크에서 데이터 전송 및 수신 장치 및 방법 Download PDF

Info

Publication number
KR102141444B1
KR102141444B1 KR1020130068180A KR20130068180A KR102141444B1 KR 102141444 B1 KR102141444 B1 KR 102141444B1 KR 1020130068180 A KR1020130068180 A KR 1020130068180A KR 20130068180 A KR20130068180 A KR 20130068180A KR 102141444 B1 KR102141444 B1 KR 102141444B1
Authority
KR
South Korea
Prior art keywords
user terminal
message
content
add
receiving
Prior art date
Application number
KR1020130068180A
Other languages
English (en)
Other versions
KR20140145716A (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 KR1020130068180A priority Critical patent/KR102141444B1/ko
Priority to EP14172400.5A priority patent/EP2814220B1/en
Priority to US14/304,476 priority patent/US9609684B2/en
Publication of KR20140145716A publication Critical patent/KR20140145716A/ko
Application granted granted Critical
Publication of KR102141444B1 publication Critical patent/KR102141444B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/20—Communication route or path selection, e.g. power-based or shortest path routing based on geographic position or location

Abstract

본 발명은 모바일 콘텐트 네트워크(mobile content network)에서 사용자 단말기의 데이터 수신 방법에 있어서, 제1 디지털 유닛(Digital Unit: DU)으로 콘텐트를 요구하는 요구(Request) 메시지를 송신하는 과정과, 상기 제1 DU로부터 상기 콘텐트를 캐쉬(cache)하고 있는 DU인 제2DU에 대한 정보를 포함하는 인터넷 프로토콜(Internet Protocol: IP) 추가(IP_ADD) 메시지를 수신하는 과정과, 상기 IP_ADD 메시지에 포함되어 있는 상기 제2DU에 대한 정보를 기반으로 스트림 제어 송신 프로토콜(Stream Control Transmission Protocol: SCTP) 연결(connection)을 업데이트(update)하는 과정과, 상기 업데이트한 SCTP 연결을 사용하여 상기 제2DU로부터 데이터를 수신하는 과정을 포함함을 특징으로 한다.

Description

모바일 콘텐트 네트워크에서 데이터 전송 및 수신 장치 및 방법{APPARATUS AND METHOD FOR DELIVERING AND RECEIVING DATA IN MOBILE CONTENT NETWORK}
본 발명은 모바일 콘텐트 네트워크(mobile content network)에서 데이터를 전송 및 수신하는 장치 및 방법에 관한 것이다.
인터넷(internet)이 발전해나감에 따라 다양한 방식들이 제안된바 있었으며, 그 중 대표적인 방식이 콘텐트 전송 네트워크(Content Delivery Network) 방식이다. 그러면 여기서 상기 콘텐트 전송 네트워크 방식에 대해서 설명하면 다음과 같다.
먼저, 상기 콘텐트 전송 네트워크 방식을 사용할 경우 사용자 디바이스(user device)가 콘텐트를 요청할 경우, 콘텐트를 캐쉬하고 있는 노드(node)를 검색해야 한다. 상기 콘텐트를 캐쉬하고 있는 노드를 검색하기 위해서 http 리다이렉션(http redirection, 이하 “http redirection”라 칭하기로 한다) 방식을 사용하며, 상기 http redirection 방식에 대해서 설명하면 다음과 같다.
상기 http redirection 방식을 사용할 경우, 상기 사용자 디바이스는 해당 노드로 http 요구(http request, 이하 “http request”라 칭하기로 한다) 메시지를 송신한다. 여기서, 상기 http request 메시지는 상기 http request 메시지를 송신한 주체가 콘텐트를 요구하고 있음을 나타낸다. 상기 http request 메시지를 수신한 해당 노드는 상기 해당 노드 자신이 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과 상기 해당 노드 자신이 콘텐트를 캐쉬하고 있지 않을 경우 상기 콘텐트를 요청한 사용자 디바이스로 http redirection 메시지를 송신한다. 여기서, 상기 http redirection 메시지는 상기 http redirection 메시지를 송신하는 노드가 콘텐트를 캐쉬하고 있지 않으므로 다른 노드로 콘텐트를 요구할 것을 나타내는 메시지로서, 상기 http redirection 메시지를 송신한 노드가 연결되어 있는 서버(server)에 대한 정보를 포함한다. 상기 서버에 대한 정보는 서버의 인터넷 프로토콜(Internet Protocol: IP, 이하 “IP”라 칭하기로 한다) 어드레스(address)와 같은 다양한 정보를 포함할 수 있으며, 여기서는 그 상세한 설명을 생략하기로 한다.
상기 사용자 디바이스는 상기 해당 노드로부터 수신한 http redirection 메시지에 포함되어 있는 서버에 대한 정보를 검출하고, 상기 검출한 서버에 대한 정보에 해당하는 서버를 다시 검색한다. 그리고 나서, 상기 사용자 디바이스는 상기 검색한 서버로 접속한다. 그리고 나서, 상기 사용자 디바이스는 상기 접속한 서버로 다시 콘텐트를 요구하는 http request 메시지를 송신한다.
상기 사용자 단말기는 콘텐트를 캐쉬하고 있는 노드를 검색할 때 까지 상기에서 설명한 바와 같은 동작, 즉 특정 노드로 http request 메시지를 송신하는 동작과, 상기 특정 노드로부터 http redirection 메시지를 수신하는 동작과, 상기 http redirection 메시지에 포함되어 있는 서버에 대한 정보를 검출하여 해당 서버로 접속하는 동작과, 상기 접속한 서버로 다시 http request 메시지를 송신하는 동작을 반복한다.
상기와 같은 동작을 통해 콘텐트를 캐쉬하고 있는 노드는 상기 사용자 디바이스로 해당 노드가 캐쉬하고 있는 콘텐트를 전송하고, 이에 따라 상기 사용자 노드는 해당 노드에서 전송한 콘텐트를 수신할 수 있게 된다.
그런데, 상기에서 설명한 바와 같은 http redirection 방식을 사용할 경우, 해당 노드들이 http 메시지를 송신하기에 앞서 송신 제어 프로토콜(Transmission Control Protocol: TCP, 이하 “TCP”라 칭하기로 한다) 연결(connection)을 성립하는 절차가 선행되어야만 한다. 즉, 상기 http redirection 방식을 사용하여 새로운 호스트(host)에 접속할 때마다, 상기 새로운 호스트와 사용자 단말기는 TCP 연결을 새로 설정하고, 상기 TCP 연결이 설정된 후에야 상기 사용자 단말기가 http request 메시지를 송신하는 것이 가능하게 된다.
이와 같은 새로운 호스트와의 TCP 연결 설정은 상기 모바일 콘텐트 네트워크 및 사용자 단말기 모두에 오버헤드(overhead)가 될 뿐만 아니라, 서비스 지연을 초래하는 원인으로 작용하게 된다. 특히, 이미지(image)와 같이 비교적 작은 용량을 가지는 파일(file)들이 송신될 경우에는 상기 TCP 연결 설정으로 인한 오버헤드가 실제 데이터 송신보다 더 크게 된다.
따라서, 모바일 콘텐트 네트워크에서 사용자 단말기가 새로운 호스트 검색 시마다 TCP 연결을 새로 설정할 필요가 없이 콘텐트를 전송받을 수 있는 방안에 대한 필요성이 대두되고 있다.
본 발명은 모바일 콘텐트 네트워크에서 데이터를 전송 및 수신하는 장치 및 방법을 제공한다.
또한, 본 발명은 모바일 콘텐트 네트워크에서 사용자 단말기가 새로운 호스트 검색 시마다 TCP 연결을 새로 설정할 필요가 없이 콘텐트를 전송 및 수신하는 것이 가능한 장치 및 방법을 제공한다.
본 발명에서 제안하는 장치는; 모바일 콘텐트 네트워크(mobile content network)에서 사용자 단말기에 있어서, 제1 디지털 유닛(Digital Unit: DU)으로 콘텐트를 요구하는 요구(Request) 메시지를 송신하는 송신 유닛과, 상기 제1 DU로부터 상기 콘텐트를 캐쉬(cache)하고 있는 DU인 제2DU에 대한 정보를 포함하는 인터넷 프로토콜(Internet Protocol: IP) 추가(IP_ADD) 메시지를 수신하는 수신 유닛과, 상기 IP_ADD 메시지에 포함되어 있는 상기 제2DU에 대한 정보를 기반으로 스트림 제어 송신 프로토콜(Stream Control Transmission Protocol: SCTP) 연결(connection)을 업데이트(update)하는 제어 유닛을 포함하고, 상기 수신 유닛은 상기 업데이트한 SCTP 연결을 사용하여 상기 제2DU로부터 데이터를 수신함을 특징으로 한다.
본 발명에서 제안하는 다른 장치는; 모바일 콘텐트 네트워크(mobile content network)에서 제1 디지털 유닛(Digital Unit: DU)에 있어서, 사용자 단말기로부터 콘텐트를 요구하는 요구(Request) 메시지를 수신하는 수신 유닛과, 상기 제1DU 자신이 상기 사용자 단말기가 요구한 콘텐트를 캐쉬(cache)하고 있는지 여부를 검사하는 제어 유닛과, 상기 검사 결과 상기 제1DU 자신이 상기 사용자 단말기가 요구한 콘텐트를 캐쉬(cache)하고 있지 않을 경우, 상기 사용자 단말기가 요구한 콘텐트를 캐쉬하고 있을 것으로 예상되는 DU인 제2DU로 상기 Request 메시지를 라우팅(routing)하고, 상기 사용자 단말기로 상기 제2DU에 대한 정보를 포함하는 인터넷 프로토콜(Internet Protocol: IP) 추가(IP_ADD) 메시지를 송신하는 송신 유닛을 포함함을 특징으로 한다.
본 발명에서 제안하는 또 다른 장치는; 모바일 콘텐트 네트워크(mobile content network)에서 제2 디지털 유닛(Digital Unit: DU)에 있어서, 사용자 단말기로부터 콘텐트를 요구하는 요구(Request) 메시지를 수신한 제1 DU로부터 상기 Request 메시지를 수신하는 수신 유닛과, 상기 제2 DU 자신이 상기 사용자 단말기가 요구한 콘텐트를 캐쉬(cache)하고 있는지 여부를 검사하는 제어 유닛과, 상기 검사 결과 상기 제2DU 자신이 상기 사용자 단말기가 요구한 콘텐트를 캐쉬(cache)하고 있을 경우, 상기 사용자 단말기로 상기 사용자 단말기가 요구한 콘텐트를 전송하는 송신 유닛을 포함함을 특징으로 한다.
본 발명에서 제안하는 방법은; 모바일 콘텐트 네트워크(mobile content network)에서 사용자 단말기의 데이터 수신 방법에 있어서, 제1 디지털 유닛(Digital Unit: DU)으로 콘텐트를 요구하는 요구(Request) 메시지를 송신하는 과정과, 상기 제1 DU로부터 상기 콘텐트를 캐쉬(cache)하고 있는 DU인 제2DU에 대한 정보를 포함하는 인터넷 프로토콜(Internet Protocol: IP) 추가(IP_ADD) 메시지를 수신하는 과정과, 상기 IP_ADD 메시지에 포함되어 있는 상기 제2DU에 대한 정보를 기반으로 스트림 제어 송신 프로토콜(Stream Control Transmission Protocol: SCTP) 연결(connection)을 업데이트(update)하는 과정과, 상기 업데이트한 SCTP 연결을 사용하여 상기 제2DU로부터 데이터를 수신하는 과정을 포함함을 특징으로 한다.
본 발명에서 제안하는 다른 방법은; 모바일 콘텐트 네트워크(mobile content network)에서 제1 디지털 유닛(Digital Unit: DU)의 데이터 전송 방법에 있어서, 사용자 단말기로부터 콘텐트를 요구하는 요구(Request) 메시지를 수신하는 과정과, 상기 제1DU 자신이 상기 사용자 단말기가 요구한 콘텐트를 캐쉬(cache)하고 있는지 여부를 검사하는 과정과, 상기 검사 결과 상기 제1DU 자신이 상기 사용자 단말기가 요구한 콘텐트를 캐쉬(cache)하고 있지 않을 경우, 상기 사용자 단말기가 요구한 콘텐트를 캐쉬하고 있을 것으로 예상되는 DU인 제2DU로 상기 Request 메시지를 라우팅(routing)하는 과정과, 상기 사용자 단말기로 상기 제2DU에 대한 정보를 포함하는 인터넷 프로토콜(Internet Protocol: IP) 추가(IP_ADD) 메시지를 송신하는 과정을 포함함을 특징으로 한다.
본 발명에서 제안하는 또 다른 방법은; 모바일 콘텐트 네트워크(mobile content network)에서 제2 디지털 유닛(Digital Unit: DU)의 데이터 전송 방법에 있어서, 사용자 단말기로부터 콘텐트를 요구하는 요구(Request) 메시지를 수신한 제1 DU로부터 상기 Request 메시지를 수신하는 과정과, 상기 제2 DU 자신이 상기 사용자 단말기가 요구한 콘텐트를 캐쉬(cache)하고 있는지 여부를 검사하는 과정과, 상기 검사 결과 상기 제2DU 자신이 상기 사용자 단말기가 요구한 콘텐트를 캐쉬(cache)하고 있을 경우, 상기 사용자 단말기로 상기 사용자 단말기가 요구한 콘텐트를 전송하는 과정을 포함함을 특징으로 한다.
본 발명은 모바일 콘텐트 네트워크에서 사용자 단말기가 새로운 호스트(host) 검색 시마다 (Transmission Control Protocol: TCP, 이하 “TCP”라 칭하기로 한다) 연결(connection)을 새로 설정할 필요가 없이 콘텐트를 전송받을 수 있다는 효과를 가진다.
본 발명은 이렇게 새로운 호스트 검색시마다 TCP 연결을 새로 설정할 필요가 없기 때문에 상기 모바일 콘텐트 네트워크 및 사용자 단말기 모두에 작용될 수 있는 오버헤드(overhead)를 제거할 수 있을 뿐만 아니라, 서비스 지연을 제거할 수 있다는 효과가 있다.
본 발명은 이런 오버헤드 제거 및 서비스 지연 제거를 가능하게 함으로써 결과적으로 콘텐트 다운로드 속도를 향상시키게 된다는 효과가 있다.
도 1은 본 발명의 일 실시예에 따른 모바일 콘텐트 네트워크의 구조를 개략적으로 도시한 도면
도 2는 일반적인 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정을 개략적으로 도시한 도면
도 3은 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 일 예를 개략적으로 도시한 도면
도 4는 도 3의 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 따른 사용자 단말기(310)와, DU #0(320)와 DU #1(330)간의 신호 송/수신 과정을 도시한 신호 흐름도
도 5a는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 다른 예를 사용자 단말기 측면을 고려하여 개략적으로 도시한 도면
도 5b는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 다른 예를 DU#1 측면을 고려하여 개략적으로 도시한 도면
도 6은 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 또 다른 예를 개략적으로 도시한 도면
도 7은 도 6의 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 따른 사용자 단말기(610)와, DU #0(620)와, DU #1(630) 및 DU #2(630)간의 신호 송/수신 과정을 개략적으로 도시한 도면
도 8은 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 사용자 단말기의 내부 구조를 개략적으로 도시한 도면
도 9는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 DU, 혹은 S-GW, 혹은 CDN 노드의 내부 구조를 개략적으로 도시한 도면
이하, 본 발명에 따른 바람직한 실시 예를 첨부한 도면을 참조하여 상세히 설명한다. 하기의 설명에서는 본 발명에 따른 동작을 이해하는데 필요한 부분만이 설명되며 그 이외 부분의 설명은 본 발명의 요지를 흩트리지 않도록 생략될 것이라는 것을 유의하여야 한다.
본 발명은 모바일 콘텐트 네트워크(mobile content network)에서 데이터 전송 및 수신 방법 및 장치를 제안한다.
본 발명은 모바일 콘텐트 네트워크에서 서빙 게이트웨이(Serving-GateWay: S-GW, 이하 “S-GW”라 칭하기로 한다) 선택/변경 장치 및 방법을 제안한다.
또한, 본 발명은 모바일 콘텐트 네트워크에서 콘텐트를 캐쉬(cache)하고 있는 S-GW를 선택/변경하는 장치 및 방법을 제안한다.
또한, 본 발명은 모바일 콘텐트 네트워크에서 사용자 단말기가 새로운 호스트(host) 검색 시마다 (Transmission Control Protocol: TCP, 이하 “TCP”라 칭하기로 한다) 연결(connection)을 새로 설정할 필요가 없이 콘텐트를 전송받을 수 있는 데이터 전송 및 수신 방법 및 장치를 제공한다.
도 1은 본 발명의 일 실시예에 따른 모바일 콘텐트 네트워크의 구조를 개략적으로 도시한 도면이다.
도 1을 설명하기에 앞서, 도 1에 도시되어 있는 모바일 콘텐트 네트워크는 이동 통신 네트워크 내에 콘텐트 캐슁 노드(content caching node)가 설치되어 있는 환경을 가정할 경우의 모바일 콘텐트 네트워크 구조를 나타낸다.
도 1을 참조하면, 먼저 사용자 단말기가 콘텐트를 요구하였을 경우, 중간 절차들을 통해 상기 사용자 단말기의 콘텐트 요구는 해당 콘텐트를 캐쉬하고 있는 노드로 전송될 것이다. 그러면, 상기 사용자 단말기가 요구한 콘텐츠를 캐쉬하고 있는 노드는 해당 콘텐트를 상기 사용자 단말기로 전송하고, 따라서 상기 사용자 단말기는 상기 사용자 단말기가 요구한 콘텐츠를 캐쉬하고 있는 노드로부터 해당 콘텐트를 다운로드(download)할 것이다. 이 경우, 상기 사용자 단말기가 현재의 위치에서 다른 위치로 이동한다 해도, 여전히 해당 노드로부터 콘텐트를 다운로드 한다. 따라서, 적어도 해당 콘텐트에 대해서는 콘텐트를 캐쉬하고 있는 노드가 앵커(anchor) 역할을 하고 있는 것이다. 여기서, anchor 역할을 수행하는 노드는 S-GW 이므로, 결국 다운로드할 콘텐트마다 S-GW가 지정되는 형식을 가지게 된다.
그런데, 사용자 단말기의 콘텐트 요구에 따라 콘텐트를 요구하는 메시지는 상기 사용자 단말기가 현재 인식하고 있는 S-GW로 전송될 것이고, 이 경우 해당 S-GW가 상기 사용자 단말기가 요구하는, 즉 상기 사용자 단말기가 다운로드하기를 원하는 콘텐트를 가지고 있다는 보장은 없다.
따라서, 상기 사용자 단말기가 요구한 콘텐트를 상기 사용자 단말기로 전송할 수 있는 S-GW로 상기 사용자 단말기는 연결되어야만 하며, 이런 현상은 인터넷(internet)에서 사용되고 있는 콘텐트 전송 네트워크(Content Delivery Network: CDN, 이하 “CDN”이라 칭하기로 한다) 방식에서 발생되는 현상과 거의 동일하다.
그러면, 먼저 도 2를 참조하여 일반적인 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 대해서 설명하기로 한다.
도 2는 일반적인 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정을 개략적으로 도시한 도면이다.
도 2를 참조하면, 먼저 상기 모바일 콘텐트 네트워크는 사용자 디바이스(210)와, 서버(220)와, 도메인 네임 시스템(Domain Name System: DNS, 이하 “DNS”라 칭하기로 한다) 서버(230)와, CDN 노드 #1(240)와, CDN 노드 #2(250)를 포함한다.
먼저, 상기 사용자 단말기(210)는 상기 서버(220)와 접속하고 있는 상태에서, 임의의 콘텐트를 전송받기를 원할 경우 상기 서버(220)로 상기 사용자 단말기(210)가 콘텐트를 요구함을 나타내는 http 요구(http request, 이하 “http request”라 칭하기로 한다) 메시지를 송신한다(211단계). 여기서, 상기 http request 메시지는 상기 http request 메시지를 송신한 주체가 콘텐트를 요구하고 있음을 나타낸다.
상기 http request 메시지를 수신한 상기 서버(220)는 상기 서버(220) 자신이 상기 사용자 단말기(210)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(210)로 http 리다이렉션(http redirection, 이하 “http redirection”라 칭하기로 한다) 메시지를 송신하거나 혹은 상기 사용자 단말기(210)가 요구하는 콘텐트를 상기 사용자 단말기(210)로 전송한다. 도 2에서는 상기 서버(220)가 상기 사용자 단말기(210)가 요구한 컨텐트를 캐쉬하고 있지 않다고 가정하기로 한다. 따라서, 상기 서버(220)는 상기 사용자 단말기(210)로 상기 http redirection 메시지를 송신한다(213단계). 여기서, 상기 http redirection 메시지는 상기 http redirection 메시지를 송신하는 노드가 콘텐트를 캐쉬하고 있지 않으므로 다른 노드로 콘텐트를 요구할 것을 나타내는 메시지로서, 상기 사용자 단말기(210)가 요구한 콘텐트를 캐쉬하고 있을 것으로 예상되는 서버에 대한 정보를 포함한다. 여기서, 상기 http redirection 메시지에 포함되어 있는, 상기 사용자 단말기(210)가 요구한 콘텐트를 캐쉬하고 있을 것으로 예상되는 서버에 대한 정보는 해당 서버의 도메인 네임이 될 수 있으며, 여기서는 그 상세한 설명을 생략하기로 한다. 도 2에서는 상기 http redirection 메시지에 상기 사용자 단말기(210)가 요구한 콘텐트를 캐쉬하고 있을 것으로 예상되는 서버에 대한 정보로서 상기 CDN 노드 #1(240)의 도메인 네임이 포함되어 있다고 가정하기로 한다.
상기 서버(220)로부터 http redirection 메시지를 수신한 사용자 단말기(210)는 상기 DNS 서버(230)로 DNS 쿼리(DNS_query, 이하 “DNS_query”라 칭하기로 한다) 메시지를 송신한다(215단계). 여기서, 상기 DNS_query 메시지에는 상기 http redirection 메시지를 통해 수신한 상기 사용자 단말기(210)가 요구한 콘텐트를 캐쉬하고 있을 것으로 예상되는 서버에 대한 정보, 즉 상기 CDN 노드 #1(240)의 도메인 네임이 포함되어 있다.
상기 사용자 단말기(210)로부터 DNS_query 메시지를 수신한 상기 DNS 서버(230)는 상기 DNS_query 메시지에 포함되어 있는 상기 CDN 노드 #1(240)의 도메인 네임을 분석하여, 상기 CDN 노드 #1(240)의 도메인 네임에 해당하는 인터넷 프로토콜(Internet Protocol: IP, 이하 “IP”라 칭하기로 한다) 어드레스(address)를 검출한다. 상기 DNS 서버(230)는 상기 검출한 상기 CDN 노드 #1(240)의 IP 어드레스를 포함하는 DNS 쿼리 응답(DNS_query_ReSPonse: DNS_query_RSP, 이하 “DNS_query_RSP”라 칭하기로 한다) 메시지를 송신한다(217단계). 결국, 상기 215단계 내지 217단계의 DNS 과정을 통해서 상기 사용자 단말기(210)는 상기 콘텐트를 수신할 다른 서버의 IP 어드레스를 획득할 수 있게 되는 것이다.
상기 DNS 서버(230)로부터 DNS_query_RSP 메시지를 수신한 사용자 단말기(210)는 상기 콘텐트를 캐쉬하고 있을 서버인 상기 CDN 노드 #1(240)의 IP 어드레스를 검출할 수 있고, 상기 CDN 노드 #1(240)의 IP 어드레스를 사용하여 새로운 서버, 즉 상기 CDN 노드 #1(240)로 접속을 시도하게 된다. 즉, 상기 사용자 단말기(210)는 상기 CDN 노드 #1(240)으로 동기(SYNchronization: SYN, 이하 “SYN”이라 칭하기로 한다) 메시지를 송신하고(219단계), 상기 사용자 단말기(210)로부터 SYN 메시지를 수신한 상기 CDN 노드 #1(240)는 상기 SYN 메시지에 대한 응답 메시지인 동기 ACK(SYNchronization ACKnowledgement: SYN-ACK, 이하 “SYN-ACK”라 칭하기로 한다) 메시지를 송신하고(221단계), 상기 CDN 노드 #1(240)로부터 SYN-ACK 메시지를 수신한 사용자 단말기(210)는 상기 SYN-ACK 메시지에 대한 응답 메시지인 ACK 메시지를 상기 CDN 노드 #1(240)로 송신한다(223단계). 여기서, 상기 219단계 내지 223단계는 송신 제어 프로토콜(Transmission Control Protocol: TCP, 이하 “TCP”라 칭하기로 한다) 접속 과정, 즉 TCP 연결(connection)을 성립하는 과정이다.
상기 사용자 단말기(210)가 상기 CDN 노드 #1(240)로 ACK 메시지를 송신함에 따라 상기 사용자 단말기(210)는 상기 CDN 노드 #1(240)로 접속되고, 따라서 상기 사용자 단말기(210)는 상기 CDN 노드 #1(240)로 해당 콘텐트를 요구하는 http request 메시지를 송신한다(225단계). 상기 사용자 단말기(210)로부터 http request 메시지를 수신한 CDN 노드 #1(240)는 상기 CDN 노드 #1(240)로 자신이 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(210)로 http redirection 메시지를 송신하거나 혹은 상기 사용자 단말기(210)가 요구하는 콘텐트를 상기 사용자 단말기(210)로 전송한다. 도 2에서는 상기 CDN 노드 #1(240)이 상기 사용자 단말기(210)가 요구한 컨텐트를 캐쉬하고 있다고 가정하기로 한다. 따라서, 상기 CDN 노드 #1(240)는 상기 사용자 단말기(210)로 상기 CDN 노드 #1(240) 자신이 캐쉬하고 있는 데이터를 전송한다(227단계).
여기서, 상기 사용자 단말기(210)는 콘텐트를 캐쉬하고 있는 노드를 검색할 때 까지 상기에서 설명한 바와 같은 동작, 즉 특정 노드로 http request 메시지를 송신하는 동작과, 상기 특정 노드로부터 http redirection 메시지를 수신하는 동작과, 상기 http redirection 메시지에 포함되어 있는 서버에 대한 정보를 검출하여 해당 서버로 접속하는 동작과, 상기 접속한 서버로 다시 http request 메시지를 송신하는 동작을 반복한다. 도 2에서는 CDN 노드 #1(240)이 상기 사용자 단말기(210)가 요구하는 콘텐트를 캐쉬하고 있기 때문에 새로운 호스트와의 TCP 접속 과정, 즉 TCP 연결 설정 과정이 1회만 수행되었다. 하지만, 상기 CDN 노드 #1(240)도 상기 사용자 단말기(210)가 요구하는 콘텐트를 캐쉬하고 있지 않다면 상기 사용자 단말기(210)는 또 다른 호스트와 호스트와의 TCP 접속 과정을 다시 수행해야만 한다.
이와 같은 새로운 호스트와의 TCP 접속 과정은 상기 모바일 콘텐트 네트워크 및 사용자 단말기 모두(210)에 오버헤드(overhead)가 될 뿐만 아니라, 서비스 지연을 초래하는 원인으로 작용하게 된다. 특히, 이미지(image)와 같이 비교적 작은 용량을 가지는 파일(file)들이 송신될 경우에는 상기 TCP 접속으로 인한 오버헤드가 실제 데이터 송신보다 더 크게 된다.
따라서, 본 발명의 실시예에서는 모바일 콘텐트 네트워크에서 사용자 단말기가 새로운 호스트 검색 시마다 TCP 연결을 새로 설정할 필요가 없으면서도, 콘텐트 요구를 위한 http request 메시지를 송신할 필요도 없는 새로운 콘텐트 전송 방법을 제안하며, 이를 도 3을 참조하여 설명하기로 한다.
도 3은 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 일 예를 개략적으로 도시한 도면이다.
도 3을 참조하면, 먼저 상기 모바일 콘텐트 네트워크는 사용자 디바이스(310)와, 디지털 유닛(Digital Unit: DU, 이하 “DU” 라고 칭하기로 한다) #0(320)와, DU #1(330)과, DU #2(340)를 포함한다. 여기서, 상기 DU #0(320)과, DU #1(330)과, DU #2(340) 각각은 서빙 게이트웨이(Serving-GateWay: S-GW, 이하 “S-GW”라 칭하기로 한다) 혹은 CDN 노드가 될 수도 있음은 물론이다.
먼저, 상기 사용자 단말기(310)는 상기 DU #0(320)과 접속하고 있는 상태에서, 임의의 콘텐트를 전송받기를 원할 경우 상기 DU #0(320)로 상기 사용자 단말기(310)가 콘텐트를 요구함을 나타내는 요구(Request, 이하 “Request”라 칭하기로 한다) 메시지를 송신한다(311단계). 상기 사용자 단말기(310)로부터 상기 Request 메시지를 수신한 상기 DU #0(320)는 상기 DU #0(320) 자신이 상기 사용자 단말기(310)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(310)로 IP 추가(IP_ADD, 이하 “IP_ADD”라 칭하기로 한다) 메시지를 송신하거나 혹은 상기 사용자 단말기(310)가 요구하는 콘텐트를 상기 사용자 단말기(310)로 전송한다. 도 3에서는 상기 DU #0(320)가 상기 사용자 단말기(310)가 요구한 컨텐트를 캐쉬하고 있지 않고, 상기 DU #1(330)이 상기 사용자 단말기(310)가 요구한 컨텐트를 캐쉬하고 있다고 가정하기로 한다. 여기서, 상기 DU #0(320)는 상기 사용자 단말기(310)가 요구한 컨텐트를 캐쉬하고 있지 않기 때문에 상기 사용자 단말기(310)의 콘텐트 요구를 처리할 노드를 결정할 때 일반적인 콘텐트 요구 처리 방식, 일 예로 분산 해쉬(distributed hash, 이하 “distributed hash”라 칭하기로 한다) 방식 혹은 테이블(table) 관리 방식 등과 같은 일반적인 콘텐트 요구 처리 방식을 사용하여 결정하며, 이에 대해서는 구체적인 설명을 생략하기로 한다.
따라서, 상기 DU #0(320)는 상기 IP_ADD 메시지에 상기 사용자 단말기(310)가 요구한 컨텐트를 캐쉬하고 있는 DU, 즉 상기 DU #1(330)의 IP 어드레스를 포함시켜 상기 사용자 단말기(310)로 송신한다(313단계). 여기서, 상기 IP_ADD 메시지는 바인딩 정책(binding policy)을 포함할 수 있다. 또한, 상기 모바일 콘텐트 네트워크에서 사용되는 연결은 TCP 연결이 아닌 스트림 송신 제어 프로토콜(Stream Transmission Control Protocol: STCP, 이하 “STCP”라 칭하기로 한다) 연결이기 때문에 각 연결은 다수개의 IP 어드레스를 처리할 수 있다.
상기 DU #0(320)으로부터 IP_ADD 메시지를 수신한 사용자 단말기(310)는 상기 IP ADD 메시지에 포함되어 있는 IP 어드레스, 즉 상기 DU #1(330)의 IP 어드레스를 사용하여 스트림 제어 송신 프로토콜(Stream Control Transmission Protocol: SCTP, 이하 “SCTP”라 칭하기로 한다) 연결을 업데이트(update)한다. 상기 DU #0(320)로부터 IP ADD 메시지를 수신한 사용자 단말기(310)는 필요에 따라 상기 IP_ADD 메시지에 대한 ACK 메시지를 송신할 수도 있으나, 도 3에서는 상기 IP ADD 메시지에 대한 ACK 메시지를 별도로 송신하지 않는다고 가정하기로 한다.
한편, 상기 DU #0(320)은 상기 사용자 단말기(310)로 상기 IP_ADD 메시지를 송신한 후, 상기 DU #1(330)로 IP_ADD 메시지를 송신한다(317단계). 여기서, 상기 DU #0(320)에서 상기 DU #1(330)로 송신되는 IP_ADD 메시지는 상기 DU #1(330)이 상기 사용자 단말기(310)로 콘텐트를 전송할 수 있도록 하기 위해서 송신되는 메시지로서, Request 메시지와 상기 사용자 단말기(310)의 IP 어드레스, 즉 사용자 단말기 IP(User Equipment_IP: UE_IP, 이하 “UE_IP”라 칭하기로 한다) 어드레스와, 신규 스트림 식별자(Identifier: ID, 이하 “ID”라 칭하기로 한다)와, 시퀀스 번호(sequence number)를 포함한다. 상기 DU #0(320)로부터 IP_ADD 메시지를 수신한 DU #1(330)은 상기 DU #0(320)와 상기 DU #1(330)간에 설정되어 있던 SCTP 연결을 그대로 상기 DU #1(330)과 사용자 단말기(310)간의 데이터 통신을 위한 SCTP 연결로 사용한다. 즉, 상기 사용자 단말기(310)는 상기 DU #1(330)과 새로운 연결을 설정하지 않아도 상기 DU #1(330)과 데이터 통신을 수행하는 것이 가능하다.
상기 DU #0(320)로부터 상기 사용자 단말기(310)의 UE_IP 어드레스와, 신규 스트림 ID와, 시퀀스 번호를 포함하는 IP_ADD 메시지를 수신한 DU #1(330)은 상기 사용자 단말기(310)로 상기 사용자 단말기(310)가 요구한 콘텐트를 전송한다(319단계).
이렇게, 상기 사용자 단말기(310)와 DU #1(330)간에 새로운 연결을 설정하지 않고도, 상기 DU #0(320)과 DU #1(330)간에 설정되어 있던 SCTP 연결을 그대로 사용하여 데이터 통신을 수행할 수 있는 이유는 사업자 네트워크에서는 상기 313단계의 IP_ADD 메시지가 상기 DU #1(330)에서 상기 사용자 단말기(310)로 전송하는 데이터보다 항상 먼저 상기 사용자 단말기(310)에게 도달할 수 있다는 것을 보장한다는 가정이 존재하기 때문이다. 참고적으로, 일반적인 인터넷 환경에서는 상기 313단계의 IP_ADD 메시지가 상기 DU #1(330)에서 상기 사용자 단말기(310)로 전송하는 데이터보다 항상 먼저 상기 사용자 단말기(310)에게 도달할 수 있다는 것이 보장되지 않는다. 또한, 상기 DU #0(320)와 상기 DU #1(330) 각각은 늘 상대방의 상태를 확인하고 있기 때문에 상기 DU #0(320)와 상기 DU #1(330)간의 협력 통신을 위해 소요되는 오버헤드(overhead)가 거의 없기 때문에 상기 사용자 단말기(310)와 DU #1(330)간에 새로운 연결을 설정하지 않고도, 상기 DU #0(320)과 DU #1(330)간에 설정되어 있던 SCTP 연결을 그대로 사용하여 데이터 통신을 수행할 수 있는 것이다.
한편, 도 3에서는 상기 사용자 단말기(310)가 상기 DU #0(320)로부터 IP_ADD 메시지를 수신한 후 상기 IP_ADD 메시지에 대한 응답으로 ACK 메시지를 송신하지 않는 경우를 가정하였으나, 상기 모바일 콘텐트 네트워크의 네트워크 상태가 정상적이지 않을 경우에는 상기 사용자 단말기(310)가 상기 DU #0(320)로부터 IP_ADD 메시지를 수신한 후 상기 IP_ADD 메시지에 대한 응답으로 ACK 메시지를 송신해야 안정적인 데이터 통신이 가능함에 유의하여야만 한다.
도 3에서는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 일 예에 대해서 개략적으로 설명하였으며, 다음으로 도 4를 참조하여 도 3의 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 따른 사용자 단말기(310)와, DU #0(320)와 DU #1(330)간의 신호 송/수신 과정에 대해서 설명하기로 한다.
도 4는 도 3의 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 따른 사용자 단말기(310)와, DU #0(320)와 DU #1(330)간의 신호 송/수신 과정을 도시한 신호 흐름도이다.
도 4를 참조하면, 먼저 사용자 단말기(310)에 의한 콘텐트 요구가 발생하기 전부터, 상기 사용자 단말기(310)와 DU #0(320)간에는 이미 SCTP 연결이 설정되어 있으며(411단계), 상기 DU #0(320)와 DU #1(330)간에도 이미 SCTP 연결이 설정되어 있다(413단계). 또한, 상기 DU #0(320)와 DU #1(330)는 평소에도 상호간에 송/수신해야 하는 정보들이 많기 때문에, 상호간의 정보 송/수신을 위한 다수의 스트림들을 가지고 있다. 도 4에서는, 상기 DU #0(320)와 DU #1(330)간의 정보 송/수신을 위해 스트림 #11부터 스트림 #20까지의 총 10개의 스트림이 존재한다고 가정하기로 한다.
상기 사용자 단말기(310)는 상기 DU #0(320)으로 콘텐트를 요구하는 Request 메시지를 송신한다(415단계). 상기 사용자 단말기(310)로부터 Request 메시지를 수신한 DU #0(320)은 상기 DU #0(320) 자신이 상기 사용자 단말기(310)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(310)로 IP_ADD 메시지를 송신하거나 혹은 상기 사용자 단말기(310)가 요구하는 콘텐트를 상기 사용자 단말기(310)로 전송하는데, 도 3에서는 상기 DU #0(320)가 상기 사용자 단말기(310)가 요구한 컨텐트를 캐쉬하고 있지 않고, 상기 DU #1(330)이 상기 사용자 단말기(310)가 요구한 컨텐트를 캐쉬하고 있다고 가정하였었다. 여기서, 상기 DU #0(320)는 상기 사용자 단말기(310)가 요구한 컨텐트를 캐쉬하고 있지 않기 때문에 상기 사용자 단말기(310)의 콘텐트 요구를 처리할 노드를 결정할 때 일반적인 콘텐트 요구 처리 방식, 일 예로 distributed hash 방식 혹은 테이블 관리 방식 등과 같은 일반적인 콘텐트 요구 처리 방식을 사용하여 결정하며, 이에 대해서는 구체적인 설명을 생략하기로 한다.
따라서, 상기 DU #0(320)는 상기 IP_ADD 메시지에 상기 사용자 단말기(310)가 요구한 컨텐트를 캐쉬하고 있는 DU, 즉 상기 DU #1(330)의 IP 어드레스를 포함시켜 상기 사용자 단말기(310)로 송신한다(417단계). 여기서, 상기 IP_ADD 메시지는 바인딩 정책을 포함할 수 있다.
그러면 여기서 상기 사용자 단말기(310)와, DU#0(320) 및 DU#1(330) 각각에 대한 SCTP 연결의 변화에 대해서 설명하기로 한다.
첫 번째로, 상기 사용자 단말기(310)에 대한 SCTP 연결의 변화를 설명하면 다음과 같다.
먼저, 상기 사용자 단말기(310)는 상기 DU#0(320)으로부터 상기 IP_ADD 메시지를 통해 상기DU#1(330)의 IP 어드레스를 수신하였기 때문에, 데스티네이션 IP 어드레스에 상기 DU#1(330)의 IP 어드레스를 추가한다(419단계). 도 4에서는 상기 데스티네이션 IP 어드레스가 도시의 편의를 위해 “dst IP”로 도시하였음에 유의하여야만 한다. 여기서, 상기 사용자 단말기(310)가 데스티네이션 IP 어드레스에 상기 DU#1(330)의 IP 어드레스를 추가하는 동작은 일반적인 SCTP 표준에서 지원되는 동작이므로, 본 발명의 실시예에서는 일반적인 SCTP 표준 이외의 별도의 추가적인 동작을 수행할 필요는 없다. 다만, 상기 DU#1(330)의 IP 어드레스가 상기 데스티네이션 IP 어드레스에 추가되므로, 이전에 데스티네이션 IP 어드레스로 기재되어 있던 DU#0(320)의 IP 어드레스는 일시적으로 디스에이블(disable)되어야만 한다. 이렇게, 상기 DU#0(320)의 IP 어드레스가 일시적으로 디스에이블되어야만 하는 이유는 SCTP ack 메시지가 상기 DU#0(320)로 송신되면 안 되기 때문이다. 즉, 일반적인 SCTP 표준에서는 데스티네이션 IP 어드레스가 2개일 경우라도 동일한 서버가 단지 2개의 인터페이스(interface)들을 가졌기 때문에, 즉 2개의 SCTP 연결들을 설정하고 있기 때문에 2개의 데스티네이션 IP 어드레스들을 사용하여도 전혀 문제가 되지 않는다.
하지만, 본 발명의 실시예에서는 서로 다른 서버의 IP 어드레스들을 데스티네이션 IP 어드레스에 기재하였기 때문에, 미리 설정되어 있는 설정 기간 동안에는 특정한 1개의 IP 어드레스만을 데스티네이션 IP 어드레스로 사용하도록 해야 한다.
두 번째로, 상기 DU#0(320)에 대한 SCTP 연결의 변화를 설명하면 다음과 같다.
먼저, 상기 DU#0(320)는 상기 사용자 단말기(310)로부터 Request 메시지를 수신하면, 상기 DU#0(320) 자신이 상기 사용자 단말기(310)가 요구한 콘텐트를 캐쉬하고 있지 않기 때문에 상기 Request 메시지를 다시 상기 DU#1(330)로 릴레이(relay)한다(421단계). 그런데, 상기 DU#1(330)로 상기 Request 메시지를 릴레이할 경우, 상기 DU#0(320) 자신과 DU#1(330)간에 설정되어 있는 다수개의 스트림들 중에서 특정 스트림을 선택한다. 여기서, 상기 DU#1(330)로 상기 Request 메시지를 릴레이하기 위해 사용되는 스트림은 아이들(idle) 스트림이다. 여기서, 상기 DU#0(320)는 상기 Request 메시지에 상기 사용자 단말기(310)의 IP 어드레스, 즉 UE IP 어드레스를 포함시킨다.
세 번째로, 상기 DU#1(330)에 대한 SCTP 연결의 변화를 설명하면 다음과 같다.
상기 DU#1(330)은 상기 DU#0(320)로부터 Request 메시지를 수신하면, 상기 Request 메시지에 포함되어 있는 사용자 단말기(310)의 IP 어드레스를 검출하여 콘텐트를 요구한 사용자 단말기가 상기 사용자 단말기(310)임을 검출할 수 있다. 따라서, 상기 DU#1(330)은 상기 사용자 단말기(310)로 콘텐트를 전송하기 위해 상기 사용자 단말기(310)와 새롭게 SCTP 연결을 설정하는 것이 아니고, 상기 Request 메시지가 전송된 SCTP 스트림을 상기 DU#1(330)과 사용자 단말기(310)간의 통신을 위해 일시적으로 그 용도를 변경한다. 따라서, 상기 Request 메시지가 전송된 SCTP 스트림을 상기 DU#1(330)과 사용자 단말기(310)간의 통신을 위해 일시적으로 그 용도를 변경하기 위해서는 상기 용도 변경을 위한 정보가 필요하게 되며, 상기 DU#1(330)과 사용자 단말기(310)간의 통신을 위해 사용될 스트림의 스트림 번호를 상기 사용자 단말기(310)가 인식하고 있는 스트림 번호로 일시적으로 변경해야만 한다. 그리고, 상기 DU#1(330)은 SCTP 시퀀스 번호를 상기 사용자 단말기(310)가 인식하고 있는 SCTP 시퀀스 번호로 일시적으로 변경해야만 한다(423단계). 이렇게, 스트림의 스트림 번호가 상기 사용자 단말기(310)가 인식하고 있는 스트림 번호로 일시적으로 변경되고, SCTP 시퀀스 번호가 상기 사용자 단말기(310)가 인식하고 있는 SCTP 시퀀스 번호로 일시적으로 변경됨에 따라 상기 사용자 단말기(310)와 DU#1(330)간에는 가상 SCTP 연결이 생성된다(425단계).
상기 DU#1(330)는 상기 DU#1(330)과 사용자 단말기(310)간에 생성된 가상 SCTP 연결을 통해, 즉 해당 스트림을 통해 상기 사용자 단말기(310)가 요구한 데이터를 전송한다(427단계).
한편, 상기 사용자 단말기(310)가 요구한 데이터에 대한 전송이 종료되면, 상기 DU#1(330)는 상기 DU#0(320)로 상기 사용자 단말기(310)가 요구한 데이터에 대한 전송이 종료되었음을 통보하고(429단계), 또한 상기 사용자 단말기(310)로 상기 사용자 단말기(310)가 요구한 데이터에 대한 전송이 종료되었음을 통보한다(433단계).
한편, 상기 DU#1(330)이 상기 DU#0(320)로 상기 사용자 단말기(310)가 요구한 데이터에 대한 전송이 종료되었음을 통보하면 상기 DU#0(320)는 일시적으로 그 용도가 변경되어 사용하고 있지 못하던 스트림 번호 11에 해당하는 스트림을 다시 사용할 수 있다는 것을 인식하게 된다(431단계).
그리고, 상기 DU#1(330)은 상기 사용자 단말기(310)과 사용하던 SCTP 스트림의 설정을 다시 이전 설정, 즉 상기 사용자 단말기(310)로 상기 사용자 단말기(310)가 요구한 콘텐트를 전송하기 위해서 변경되었던 설정을 다시 이전 설정으로 변경한다.
한편, 상기 사용자 단말기(310) 역시 상기 사용자 단말기(310) 자신이 요구한 콘텐트에 대한 전송이 종료되었으므로, 상기 DU#1(330)의 IP 어드레스를 데스티네이션 IP 어드레스에서 삭제하고 다시 상기 DU#0(320)와 데이터 통신을 수행할 수 있는 SCTP 스트림 상태로 변경한다.
결과적으로, 상기 DU#1(330)에서 상기 사용자 단말기(310)로의 콘텐트 전송이 완료된 후에는 SCTP 스트림이 원래의 연결 상태로 복귀되는 것이다.
한편, 도 4에 도시되어 있는 'UE stream #1 marking' 설정 동작에 대해서 설명하면 다음과 같다.
먼저, 상기 사용자 단말기(310) 측면에서 상기 DU#0(320)로 모든 콘텐트 전송이 완료되면, 해당 스트림의 시퀀스 번호는 미리 설정되어 있는 특정 값으로 증가된 상태가 된다. 도 4에서는 상기 사용자 단말기(310)의 시퀀스 번호가 “77”로 증가되어 있는 상태이다. 따라서, 상기 사용자 단말기(310)가 다음 오브젝트(object)를 다시 상기 DU#0(320)로 요구할 경우, 상기 DU#0(320)는 상기 사용자 단말기(310)의 시퀀스 번호가 이전의 시퀀스 번호보다 증가되어 있는 것을 검출할 수 있는데, 이로 인해서 상기 DU#0(320)가 오동작을 수행하지 않도록 해야만 한다.
따라서, 상기 DU#0(320)는 상기 사용자 단말기(310)로 새로운 오브젝트를 전송하기 위해서 랜덤(random) 시퀀스 번호를 사용할 수 있다는 것을 상기 DU#0(320) 자신이 인식하기 위해서 'UE stream #1 marking'로 설정해 놓은 것이다.
따라서, 상기 DU#0(320)는 해당 스트림에 대해서는 새로운 Request 메시지에 대해서 새로운 시퀀스 번호로 시작된다는 것을 인식할 수 있다.
하지만, 상기에서 설명한 바와는 다른 형태의 방법을 사용하여 상기 DU#0(320)가 상기 사용자 단말기(310)로 새로운 오브젝트를 전송하기 위해서 랜덤 시퀀스 번호를 사용할 수 있다는 것을 인식할 수 있는데, 이는 콘텐트 전송이 완료되었을 때, 상기 DU#1(330)가 상기 DU#0(320)에게 최종 시퀀스 번호를 알려주거나, 혹은 상기 사용자 단말기(310)가 상기 DU#0(320)에게 최종 시퀀스 번호를 알려주도록 함으로써 가능하다.
즉, 상기 DU#0(320)는 상기 DU#1(330)가 상기 DU#0(320)에게 최종 시퀀스 번호를 알려주거나, 혹은 상기 사용자 단말기(310)가 상기 DU#0(320)에게 최종 시퀀스 번호를 알려주도록 함으로써 상기 DU#0(320)가 상기 사용자 단말기(310)로 새로운 오브젝트를 전송하기 위해서 랜덤 시퀀스 번호를 사용할 수 있다는 것을 인식할 수 있다.
도 4에서는 도 3의 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 따른 사용자 단말기(310)와, DU #0(320)와 DU #1(330)간의 신호 송/수신 과정에 대해서 설명하였으며, 다음으로 도 5a 내지 도 5b를 참조하여 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 다른 예에 대해서 설명하기로 한다.
도 5a는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 다른 예를 사용자 단말기 측면을 고려하여 개략적으로 도시한 도면이다.
도 5a를 참조하면, 먼저 상기 모바일 콘텐트 네트워크는 사용자 단말기(510)와, DU#0(520)와, DU#1(530)을 포함한다.
상기 사용자 단말기(510)는 DU#0(520)로 Request 메시지를 전송하고(511단계), SCTP 연결의 재설정 메시지를 수신한 후 바로 콘텐트에 해당하는 데이터를 수신한다(513단계, 515단계, 517단계). 상기 사용자 단말기(510)는 실제 DU#1(530)로부터 데이터를 수신하였지만, 상기 사용자 단말기(510) 측면에서는 상기 DU#0(520)와 DU#1(530)이 마치 1개의 엔터티(entity)처럼 간주된다. 즉, 상기 DU#0(520)와 DU#1(530)는 서로 다른 엔터티가 아니라 마치 2개의 인터페이스들을 가지는 1개의 엔터티처럼 간주되는 것이다.
도 5a에서는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 다른 예를 사용자 단말기 측면을 고려하여 설명하였으며, 다음으로 도 5b를 참조하여 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 다른 예를 DU#1의 측면을 고려하여 설명하기로 한다.
도 5b는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 다른 예를 DU#1 측면을 고려하여 개략적으로 도시한 도면이다.
도 5b를 참조하면, 먼저 상기 모바일 콘텐트 네트워크는 사용자 단말기(510)와, DU#0(520)와, DU#1(530)을 포함한다.
상기 DU#1(530)은 상기 DU#0(520)로부터 Request 메시지를 수신하고(551단계), SCTP 연결 재설정 메시지를 수신한 후(553단계, 555단계), SCTP 연결 재설정을 통해 상기 사용자 단말기(510)로 콘텐트에 해당하는 데이터를 전송한다(557단계). 상기 DU#1(530)은 상기 DU#0(520)와 사용자 단말기(510)가 서로 다른 엔터티가 아니라 마치 2개의 인터페이스들을 가지는 1개의 엔터티처럼 간주되는 것이다.
도 5a 및 도 5b에서 설명한 바와 같이 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서는 실제로는 3개의 엔터티들, 즉 사용자 단말기(510)와, DU#0(520)와, DU#1(530)가 독립적으로 동작을 수행하여 콘텐트 전송을 가능하게 하지만, 실제 동작을 수행함에 있어 서로 다른 2개의 엔터티들을 마치 1개의 엔터티처럼 판단되게 하는 가상화(virtualization) 기능을 구현할 수 있게 되는 것이다.
도 5b에서는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 다른 예를 DU#1 측면을 고려하여 설명하였으며, 다음으로 도 6을 참조하여 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 또 다른 예에 대해서 설명하기로 한다.
도 6은 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 6을 참조하면, 상기 모바일 콘텐트 네트워크는 사용자 디바이스(610)와, DU #0(620)와, DU #1(630)과, DU #2(640)와, DU #3(650)을 포함한다. 여기서, 상기 DU #0(620)와, 상기 DU #1(630)과, 상기 DU #2(640)와, 상기 DU #3(650) 각각은 S-GW 혹은 CDN 노드가 될 수도 있음은 물론이다.
먼저, 상기 사용자 단말기(610)는 상기 DU #0(620)과 접속하고 있는 상태에서, 임의의 콘텐트를 전송받기를 원할 경우 상기 DU #0(620)로 상기 사용자 단말기(610)가 콘텐트를 요구함을 나타내는 Request 메시지를 송신한다(611단계). 상기 사용자 단말기(610)로부터 상기 Request 메시지를 수신한 상기 DU #0(620)는 상기 DU #0(620) 자신이 상기 사용자 단말기(610)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(610)로 IP_ADD 메시지를 송신하거나 혹은 상기 사용자 단말기(610)가 요구하는 콘텐트를 상기 사용자 단말기(610)로 전송한다. 도 6에서는 상기 DU #0(620)가 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않고, 상기 DU #3(650)이 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있다고 가정하기로 한다. 여기서, 상기 DU #0(620)는 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않기 때문에 상기 사용자 단말기(610)의 콘텐트 요구를 처리할 노드를 결정할 때 일반적인 콘텐트 요구 처리 방식, 일 예로 distributed hash 방식 혹은 테이블 관리 방식 등과 같은 일반적인 콘텐트 요구 처리 방식을 사용하여 결정하며, 이에 대해서는 구체적인 설명을 생략하기로 한다.
한편, 상기 DU #0(620)는 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 노드를 DU #1(630)이라고 결정하였다고 가정하기로 한다. 여기서, 상기 DU #0(620)는 원래의 콘텐트 서버, 즉 상기 사용자 단말기(610)가 콘텐트를 요구한 서버, 즉 상기 DU #0(620)와 지형적으로 가장 가까운 곳에 위치한 서버이다. 이렇게, 원래의 콘텐트 서버와 지형적으로 가장 가까운 곳에 위치하는 노드를 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 노드로 판단하는 이유는 원래의 콘텐트 서버에 지형적으로 가까울 수록 해당 콘텐트에 대한 요청이 어그리게이트(aggregate)되기 때문에, 캐쉬 확률이 높아지기 때문이다. 따라서, 원래의 콘텐트 서버에 지형적으로 가까운 순서대로 Request 메시지를 라우팅하다가 최종적으로 캐쉬 미스(cache miss)가 발생할 경우에는 다시 원래의 콘텐트 서버로 Request 메시지를 송신한다. 만일, 콘텐트 서버가 본 발명의 실시예에서 제안하는 방식을 사용하고 있다면, 다시 한번 본 발명의 실시예에서 제안하는 방식을 수행하고, 만일 본 발명의 실시예에서 제안하는 방식을 사용하고 있지 않다면 일반적인 http 리다이렉션(http redirection, 이하 “http redirection”라 칭하기로 한다) 방식을 사용하여 콘텐트 서버를 검색하면 된다.
따라서, 상기 DU #0(620)는 상기 IP_ADD 메시지에 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 DU, 즉 상기 DU #1(630)의 IP 어드레스를 포함시켜 상기 사용자 단말기(610)로 송신한다(613단계). 여기서, 상기 IP_ADD 메시지는 바인딩 정책을 포함할 수 있다. 상기 DU #0(620)으로부터 IP_ADD 메시지를 수신한 사용자 단말기(610)는 상기 IP ADD 메시지에 포함되어 있는 IP 어드레스, 즉 상기 DU #1(630)의 IP 어드레스를 사용하여 SCTP 연결을 업데이트한다. 상기 DU #0(620)로부터 IP ADD 메시지를 수신한 사용자 단말기(610)는 필요에 따라 상기 IP_ADD 메시지에 대한 ACK 메시지를 송신할 수도 있으나, 도 6에서는 상기 IP ADD 메시지에 대한 ACK 메시지를 별도로 송신하지 않는다고 가정하기로 한다.
한편, 상기 DU #0(620)은 상기 사용자 단말기(610)로 상기 IP_ADD 메시지를 송신한 후, 상기 DU #1(630)로 IP_ADD 메시지를 송신한다(615단계). 여기서, 상기 DU #0(620)에서 상기 DU #1(630)로 송신되는 IP_ADD 메시지는 상기 DU #1(630)이 상기 사용자 단말기(610)로 콘텐트를 전송할 수 있도록 하기 위해서 송신되는 메시지로서, Request 메시지와 상기 사용자 단말기(610)의 IP 어드레스, 즉 UE_IP 어드레스와, 신규 스트림 ID와, 시퀀스 번호를 포함한다.
상기 DU #0(620)로부터 IP_ADD 메시지를 수신한 DU #1(630)은 상기 DU #1(630) 자신이 상기 사용자 단말기(610)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(610)로 IP_ADD 메시지를 송신하거나 혹은 상기 사용자 단말기(610)가 요구하는 콘텐트를 상기 사용자 단말기(610)로 전송한다. 도 6에서는 상기 DU #1(630)이 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않기 때문에, 즉 상기 DU #3(650)이 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있기 때문에, 상기 사용자 단말기(610)의 콘텐트 요구를 처리할 노드를 결정할 때 일반적인 콘텐트 요구 처리 방식, 일 예로 distributed hash 방식 혹은 테이블 관리 방식 등과 같은 일반적인 콘텐트 요구 처리 방식을 사용하여 결정하며, 이에 대해서는 구체적인 설명을 생략하기로 한다.
한편, 상기 DU #1(630)는 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 노드를 DU #2(640)라고 결정하였다고 가정하기로 한다. 여기서, 상기 DU #2(640)는 원래의 콘텐트 서버, 즉 상기 사용자 단말기(610)가 콘텐트를 요구한 서버, 즉 상기 DU #0(620)와 지형적으로 가장 가까운 곳에 위치한 서버이다. 물론, DU #0(620)와 지형적으로 가장 가까운 곳에 위치한 서버는 상기 DU #1(630)이지만, 상기 DU #1(630) 자신은 이미 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않다고 판단하였으므로 그 다음으로 DU #0(620)와 지형적으로 가장 가까운 곳에 위치한 서버인 상기 DU #2(640)를 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 노드로 결정하는 것이다.
따라서, 상기 DU #1(630)은 IP 교체(IP REPLACE: IP_REPLACE, 이하 “IP_REPLACE “라 칭하기로 한다) 메시지에 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 DU, 즉 상기 DU #2(640)의 IP 어드레스를 포함시켜 상기 사용자 단말기(610)로 송신한다(617단계). 여기서, 상기 IP_REPLACE 메시지는 SCTP 연결의 IP 어드레스를 상기 DU #1(630)의 IP 어드레스에서 상기 DU #2(640)의 IP 어드레스로 교체할 것을 나타낸다. 상기 DU #1(630)로부터 IP_REPLACE 메시지를 수신한 사용자 단말기(610)는 상기 IP_REPLACE 메시지에 포함되어 있는 IP 어드레스, 즉 상기 DU #2(640)의 IP 어드레스를 사용하여 SCTP 연결을 업데이트한다. 상기 DU #1(630)로부터 상기 IP_REPLACE 메시지를 수신한 사용자 단말기(610)는 필요에 따라 상기 IP_REPLACE 메시지에 대한 ACK 메시지를 송신할 수도 있으나, 도 6에서는 상기 IP_REPLACE 메시지에 대한 ACK 메시지를 별도로 송신하지 않는다고 가정하기로 한다.
한편, 상기 DU #1(630)은 상기 사용자 단말기(610)로 상기 IP_REPLACE 메시지를 송신한 후, 상기 DU #2(640)로 IP_ADD 메시지를 송신한다(619단계). 여기서, 상기 DU #1(630)에서 상기 DU #2(640)로 송신되는 IP_ADD 메시지는 상기 DU #2(640)가 상기 사용자 단말기(610)로 콘텐트를 전송할 수 있도록 하기 위해서 송신되는 메시지로서, Request 메시지와 상기 사용자 단말기(610)의 IP 어드레스, 즉 UE_IP 어드레스와, 신규 스트림 ID와, 시퀀스 번호를 포함한다.
상기 DU #1(630)로부터 IP_ADD 메시지를 수신한 DU #2(640)는 상기 DU #2(640) 자신이 상기 사용자 단말기(610)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(610)로 IP_REPLACE 메시지를 송신하거나 혹은 상기 사용자 단말기(610)가 요구하는 콘텐트를 상기 사용자 단말기(610)로 전송한다. 도 6에서는 상기 DU #2(640)가 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않기 때문에, 즉 상기 DU #3(650)이 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있기 때문에, 상기 사용자 단말기(610)의 콘텐트 요구를 처리할 노드를 결정할 때 일반적인 콘텐트 요구 처리 방식, 일 예로 distributed hash 방식 혹은 테이블 관리 방식 등과 같은 일반적인 콘텐트 요구 처리 방식을 사용하여 결정하며, 이에 대해서는 구체적인 설명을 생략하기로 한다.
한편, 상기 DU #2(640)는 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 노드를 DU #3(650)이라고 결정하였다고 가정하기로 한다. 여기서, 상기 DU #3(650)은 원래의 콘텐트 서버, 즉 상기 사용자 단말기(610)가 콘텐트를 요구한 서버, 즉 상기 DU #0(620)와 지형적으로 가장 가까운 곳에 위치한 서버이다. 물론, DU #0(620)와 지형적으로 가장 가까운 곳에 위치한 서버는 상기 DU #1(630), DU #2(640)이지만, 상기 DU #2(640) 자신은 이미 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않다고 판단하였으므로 그 다음으로 DU #0(620)와 지형적으로 가장 가까운 곳에 위치한 서버인 상기 DU #3(650)을 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 노드로 결정하는 것이다.
따라서, 상기 DU #2(640)는 IP_REPLACE 메시지에 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 DU, 즉 상기 DU #3(650)의 IP 어드레스를 포함시켜 상기 사용자 단말기(610)로 송신한다(621단계). 여기서, 상기 IP_REPLACE 메시지는 SCTP 연결의 IP 어드레스를 상기 DU #2(640)의 IP 어드레스에서 상기 DU #3(650)의 IP 어드레스로 교체할 것을 나타낸다. 상기 DU #2(640)로부터 IP_REPLACE 메시지를 수신한 사용자 단말기(610)는 상기 IP_REPLACE 메시지에 포함되어 있는 IP 어드레스, 즉 상기 DU #3(650)의 IP 어드레스를 사용하여 SCTP 연결을 업데이트한다. 상기 DU #2(640)로부터 상기 IP_REPLACE 메시지를 수신한 사용자 단말기(610)는 필요에 따라 상기 IP_REPLACE 메시지에 대한 ACK 메시지를 송신할 수도 있으나, 도 6에서는 상기 IP_REPLACE 메시지에 대한 ACK 메시지를 별도로 송신하지 않는다고 가정하기로 한다.
한편, 상기 DU #2(640)는 상기 사용자 단말기(610)로 상기 IP_REPLACE 메시지를 송신한 후, 상기 DU #3(650)으로 IP_ADD 메시지를 송신한다(623단계). 여기서, 상기 DU #2(640)에서 상기 DU #3(650)으로 송신되는 IP_ADD 메시지는 상기 DU #3(650)이 상기 사용자 단말기(610)로 콘텐트를 전송할 수 있도록 하기 위해서 송신되는 메시지로서, Request 메시지와 상기 사용자 단말기(610)의 IP 어드레스, 즉 UE_IP 어드레스와, 신규 스트림 ID와, 시퀀스 번호를 포함한다.
상기 DU #2(640)로부터 IP_ADD 메시지를 수신한 DU #3(650)은 상기 DU #3(650) 자신이 상기 사용자 단말기(610)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(610)로 IP_REPLACE 메시지를 송신하거나 혹은 상기 사용자 단말기(610)가 요구하는 콘텐트를 상기 사용자 단말기(610)로 전송한다. 도 6에서는 상기 DU #3(650)이 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있기 때문에 상기 DU #2(640)와의 데이터 통신에 사용하고 있던 SCTP 스트림을 일시적으로 그 용도를 변경하고, 그 용도가 변경된 SCTP 스트림을 사용하여 상기 사용자 단말기(610)로 콘텐트, 즉 데이터를 전송한다(625단계).
도 6에서는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 도 7을 참조하여 도 6의 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 따른 사용자 단말기(610)와, DU #0(620)와, DU #1(630) 및 DU #2(630)간의 신호 송/수신 과정에 대해서 설명하기로 한다.
도 7은 도 6의 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 따른 사용자 단말기(610)와, DU #0(620)와, DU #1(630) 및 DU #2(630)간의 신호 송/수신 과정을 개략적으로 도시한 도면이다.
도 7을 참조하면, 먼저 사용자 단말기(610)에 의한 콘텐트 요구가 발생하기 전부터, 상기 사용자 단말기(610)와 DU #0(620)간에는 이미 SCTP 연결이 설정되어 있으며(711단계), 상기 DU #0(620)와 DU #1(630)간에도 이미 SCTP 연결이 설정되어 있다(713단계). 또한, 상기 DU #0(620)와 DU #1(630)는 평소에도 상호간에 송/수신해야 하는 정보들이 많기 때문에, 상호간의 정보 송/수신을 위한 다수의 스트림들을 가지고 있다. 도 7에서는, 상기 DU #0(620)와 DU #1(630)간의 정보 송/수신을 위해 스트림 #11부터 스트림 #20까지의 총 10개의 스트림이 존재한다고 가정하기로 한다.
상기 사용자 단말기(610)는 상기 DU #0(620)으로 콘텐트를 요구하는 Request 메시지를 송신한다(715단계). 상기 사용자 단말기(610)로부터 Request 메시지를 수신한 DU #0(620)은 상기 DU #0(620) 자신이 상기 사용자 단말기(610)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(610)로 IP_ADD 메시지를 송신하거나 혹은 상기 사용자 단말기(610)가 요구하는 콘텐트를 상기 사용자 단말기(610)로 전송하는데, 도 6에서는 상기 DU #0(620)가 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않고, DU #3(650)(도 7에 별도로 도시하지 않음)이 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있다고 가정하였었다. 여기서, 상기 DU #0(620)는 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않기 때문에 상기 사용자 단말기(610)의 콘텐트 요구를 처리할 노드를 결정할 때 일반적인 콘텐트 요구 처리 방식, 일 예로 distributed hash 방식 혹은 테이블 관리 방식 등과 같은 일반적인 콘텐트 요구 처리 방식을 사용하여 결정하며, 이에 대해서는 구체적인 설명을 생략하기로 한다.
따라서, 상기 DU #0(620)는 상기 IP_ADD 메시지에 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 DU, 즉 상기 DU #1(630)의 IP 어드레스를 포함시켜 상기 사용자 단말기(610)로 송신한다(717단계). 여기서, 상기 IP_ADD 메시지는 바인딩 정책을 포함할 수 있다.
상기 사용자 단말기(610)는 상기 DU#0(620)으로부터 상기 IP_ADD 메시지를 통해 상기DU#1(630)의 IP 어드레스를 수신하였기 때문에, 데스티네이션 IP 어드레스에 상기 DU#1(630)의 IP 어드레스를 추가한다(719단계). 도 7에서는 상기 데스티네이션 IP 어드레스가 도시의 편의를 위해 “dst IP”로 도시하였음에 유의하여야만 한다. 여기서, 상기 사용자 단말기(610)가 데스티네이션 IP 어드레스에 상기 DU#1(630)의 IP 어드레스를 추가하는 동작은 일반적인 SCTP 표준에서 지원되는 동작이므로, 본 발명의 실시예에서는 일반적인 SCTP 표준 이외의 별도의 추가적인 동작을 수행할 필요는 없다. 다만, 상기 DU#1(630)의 IP 어드레스가 상기 데스티네이션 IP 어드레스에 추가되므로, 이전에 데스티네이션 IP 어드레스로 기재되어 있던 DU#0(620)의 IP 어드레스는 일시적으로 디스에이블되어야만 한다. 이렇게, 상기 DU#0(620)의 IP 어드레스가 일시적으로 디스에이블되어야만 하는 이유는 SCTP ack 메시지가 상기 DU#0(620)로 송신되면 안 되기 때문이다. 즉, 일반적인 SCTP 표준에서는 데스티네이션 IP 어드레스가 2개일 경우라도 동일한 서버가 단지 2개의 인터페이스들을 가졌기 때문에, 즉 2개의 SCTP 연결들을 설정하고 있기 때문에 2개의 데스티네이션 IP 어드레스들을 사용하여도 전혀 문제가 되지 않는다.
하지만, 본 발명의 실시예에서는 서로 다른 서버의 IP 어드레스들을 데스티네이션 IP 어드레스에 기재하였기 때문에, 미리 설정되어 있는 설정 기간 동안에는 특정한 1개의 IP 어드레스만을 데스티네이션 IP 어드레스로 사용하도록 해야 한다.
또한, 상기 DU#0(620)는 상기 사용자 단말기(610)로부터 Request 메시지를 수신하면, 상기 DU#0(620) 자신이 상기 사용자 단말기(610)가 요구한 콘텐트를 캐쉬하고 있지 않기 때문에 상기 Request 메시지를 다시 상기 DU#1(630)로 릴레이한다(721단계). 그런데, 상기 DU#1(630)로 상기 Request 메시지를 릴레이할 경우, 상기 DU#0(620) 자신과 DU#1(630)간에 설정되어 있는 다수개의 스트림들 중에서 특정 스트림을 선택한다. 여기서, 상기 DU#1(630)로 상기 Request 메시지를 릴레이하기 위해 사용되는 스트림은 아이들 스트림이다. 여기서, 상기 DU#0(620)는 상기 Request 메시지에 상기 사용자 단말기(610)의 IP 어드레스, 즉 UE IP 어드레스를 포함시킨다.
한편, 도 7에서는, 상기 DU #1(630)과 DU #2(640)간의 정보 송/수신을 위해 스트림 #21부터 스트림 #30까지의 총 10개의 스트림이 존재한다고 가정하기로 한다. 상기 DU#1(630)은 상기 DU#1(630)이 상기 사용자 단말기(610)가 요구한 데이터를 캐쉬하고 있지 못하기 때문에 상기 DU#0(620)로 스트림이 유용함을 나타내는 스트림 유용(Stream Available, 이하 “Stream Available”라고 칭하기로 한다) 메시지를 송신한다(723단계). 상기 DU#0(620)은 상기 DU#1(630)로부터 Stream Available 메시지를 수신함에 따라 일시적으로 그 용도가 변경되어 사용하고 있지 못하던 스트림 번호 11에 해당하는 스트림을 다시 사용할 수 있다는 것을 인식하게 된다(725단계).
한편, 상기 DU#0(620)로부터 Request 메시지를 수신한 DU #1(630)은 상기 DU #1(630) 자신이 상기 사용자 단말기(610)가 요구하는 콘텐트를 캐쉬하고 있는지 검사하고, 상기 검사 결과에 상응하게 상기 사용자 단말기(610)로 IP_REPLACE 메시지를 송신하거나 혹은 상기 사용자 단말기(610)가 요구하는 콘텐트를 상기 사용자 단말기(610)로 전송하는데, 도 6에서는 상기 DU #1(630)이 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않고, DU #3(650)(도 7에 별도로 도시하지 않음)이 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있다고 가정하였었다. 여기서, 상기 DU #0(620)는 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있지 않기 때문에 상기 사용자 단말기(610)의 콘텐트 요구를 처리할 노드를 결정할 때 일반적인 콘텐트 요구 처리 방식, 일 예로 distributed hash 방식 혹은 테이블 관리 방식 등과 같은 일반적인 콘텐트 요구 처리 방식을 사용하여 결정하며, 이에 대해서는 구체적인 설명을 생략하기로 한다.
따라서, 상기 DU #1(630)는 상기 IP_REPLACE 메시지에 상기 사용자 단말기(610)가 요구한 컨텐트를 캐쉬하고 있을 것으로 예상되는 DU, 즉 상기 DU #2(640)의 IP 어드레스를 포함시켜 상기 사용자 단말기(610)로 송신한다(727단계).
상기 사용자 단말기(610)는 상기 DU#1(630)로부터 상기 IP_REPLACE 메시지를 통해 상기 DU#2(640)의 IP 어드레스를 수신하였기 때문에, 데스티네이션 IP 어드레스에 추가되어 있던 상기 DU#1(630)의 IP 어드레스를 DU#2(640)의 IP 어드레스로 교체한다(729단계). 상기 DU#2(640)의 IP 어드레스가 상기 데스티네이션 IP 어드레스에 추가되므로, 이전에 데스티네이션 IP 어드레스로 기재되어 있던 DU#0(620)의 IP 어드레스는 일시적으로 디스에이블되어야만 한다. 이렇게, 상기 DU#0(620)의 IP 어드레스가 일시적으로 디스에이블되어야만 하는 이유는 SCTP ack 메시지가 상기 DU#2(640)로 송신되면 안 되기 때문이다. 즉, 일반적인 SCTP 표준에서는 데스티네이션 IP 어드레스가 2개일 경우라도 동일한 서버가 단지 2개의 인터페이스들을 가졌기 때문에, 즉 2개의 SCTP 연결들을 설정하고 있기 때문에 2개의 데스티네이션 IP 어드레스들을 사용하여도 전혀 문제가 되지 않는다.
하지만, 본 발명의 실시예에서는 서로 다른 서버의 IP 어드레스들을 데스티네이션 IP 어드레스에 기재하였기 때문에, 미리 설정되어 있는 설정 기간 동안에는 특정한 1개의 IP 어드레스만을 데스티네이션 IP 어드레스로 사용하도록 해야 한다.
또한, 상기 DU#2(640)는 상기 사용자 단말기(610)로부터 Request 메시지를 수신하면, 상기 DU#2(640) 자신이 상기 사용자 단말기(610)가 요구한 콘텐트를 캐쉬하고 있지 않기 때문에 상기 Request 메시지를 다시 상기 DU#3(650)(도 7에 별도로 도시하지 않음)로 릴레이한다(731단계).
이후의 동작은 상기에서 설명한 바와 유사하므로 여기서는 그 상세한 설명을 생략하기로 한다.
한편, 도 7에 도시되어 있는 'UE stream #1 marking' 설정 동작에 대해서 설명하면 다음과 같다.
먼저, 상기 DU#0(620)가 'UE stream #1 marking' 설정 동작을 수행하는 이유는, 도 4에서 설명한 바와 같이 해당 스트림에 대해서는 새로운 Request 메시지가 수신될 경우 새로운 시퀀스 번호로 시작해야한 다는 것을 상기 DU#0(620) 자신이 인식하기 위해서이다. 만약, 해당 스트림에서 마지막 시퀀스 번호가 정확히 무엇으로 끝났는지 알 수 있도록 하려면, 도 4에서 설명한 바와 같이 상기 사용자 단말기(610)가 상기 DU#0(620)로 보고하거나 혹은 상기 DU#1(630)이 상기 DU#0(620)로 마지막 시퀀스 번호를 보고해야 한다.
여기서, 상기 DU#1(630)이 상기 DU#0(620)로 마지막 시퀀스 번호를 보고할 경우를 고려하면 다음과 같다.
상기 DU#1(630)에서 상기 DU#2(640)로 Request 메시지가 다시 라우팅될 경우, 상기 상기 DU#1(630)은 다시 최종 시퀀스 번호가 무엇인지 상기 DU#2(640)로부터 보고받아야만 정확한 마지막 시퀀스 번호를 알 수 있다. 이 경우, 최종 시퀀스 번호를 상기 DU#1(630)이 상기 DU#2(640)로부터 보고받아서 상기 DU#0(620)로 전송할 수도 있고, 상기 DU#2(640)가 직접 상기 DU#0(620)에 보고하게 할 수도 있다. 만일, 상기 DU#2(640)가 상기 직접 DU#0(620)에 보고하게 하려면, 상기 DU#2(640)는 상기 사용자 단말기(610)의 콘텐트 요구를 처리하는 기본 DU가 상기 DU#0(610)임을 미리 알고 있어야만 하며, 따라서 이 정보가 Request 메시지가 라우팅될 때 함께 전송되어야만 한다.
도 7에서는 도 6의 모바일 콘텐트 네트워크에서 콘텐트를 전송하는 과정에 따른 사용자 단말기(610)와, DU #0(620)와, DU #1(630) 및 DU #2(630)간의 신호 송/수신 과정에 대해서 설명하였으며, 다음으로 도 8을 참조하여 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 사용자 단말기의 내부 구조에 대해서 설명하기로 한다.
도 8은 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 사용자 단말기의 내부 구조를 개략적으로 도시한 도면이다.
도 8을 참조하면, 사용자 단말기(800)는 송신 유닛(unit)(811)과, 제어 유닛(813)과, 수신 유닛(815)과, 저장 유닛(817)을 포함한다.
먼저, 상기 제어 유닛(813)은 상기 사용자 단말기(800)의 전반적인 동작을 제어하며, 도 3 내지 도 7에서 설명한 바와 같은 콘텐트 전송 동작 수행을 위한 전반적인 동작을 제어한다. 상기 콘텐트 전송 동작 수행에 대해서는 도 3 내지 도 7에서 설명하였으므로 여기서는 그 상세한 설명을 생략하기로 한다.
상기 송신 유닛(811)은 상기 제어 유닛(813)의 제어에 따라 DU, 혹은 S-GW, 혹은 CDN 노드로 각종 메시지를 송신한다. 또한, 상기 수신 유닛(815)은 상기 제어 유닛(813)의 제어에 따라 DU, 혹은 S-GW, 혹은 CDN 노드로부터 각종 메시지를 수신한다.
상기 저장 유닛(817)은 상기 사용자 단말기(800)의 콘텐트 전송 동작에 관련된 프로그램(program)과 각종 데이터 등을 저장한다. 또한, 상기 저장 유닛(817)은 상기 수신 유닛(815)이 상기 DU, 혹은 S-GW, 혹은 CDN 노드로부터 수신한 각종 메시지를 저장한다.
한편, 도 8에는 상기 사용자 단말기(800)가 송신 유닛(811)과, 제어 유닛(813)과, 수신 유닛(815)과, 저장 유닛(817)과 같이 별도의 유닛들로 구현된 경우가 도시되어 있으나, 상기 송신 유닛(811)과, 제어 유닛(813)과, 수신 유닛(815)과, 저장 유닛(817)은 서로 병합되어 1개의 유닛으로 구현 가능함은 물론이다.
도 8에서는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 사용자 단말기의 내부 구조에 대해서 설명하였으며, 다음으로 도 9를 참조하여 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 DU, 혹은 S-GW, 혹은 CDN 노드의 내부 구조에 대해서 설명하기로 한다.
도 9는 본 발명의 실시예에 따른 모바일 콘텐트 네트워크에서 DU, 혹은 S-GW, 혹은 CDN 노드의 내부 구조를 개략적으로 도시한 도면이다.
도 9를 참조하면, DU, 혹은 S-GW, 혹은 CDN 노드(900)는 송신 유닛(911)과, 제어 유닛(913)과, 수신 유닛(915)과, 저장 유닛(917)을 포함한다.
먼저, 상기 제어 유닛(913)은 상기 DU, 혹은 S-GW, 혹은 CDN 노드 (900)의 전반적인 동작을 제어하며, 도 3 내지 도 7에서 설명한 바와 같은 콘텐트 전송 동작 수행을 위한 전반적인 동작을 제어한다. 상기 콘텐트 전송 동작 수행에 대해서는 도 3 내지 도 7에서 설명하였으므로 여기서는 그 상세한 설명을 생략하기로 한다.
상기 송신 유닛(911)은 상기 제어 유닛(913)의 제어에 따라 사용자 단말기와, 다른 DU, 혹은 S-GW, 혹은 CDN 노드로 메시지를 송신한다. 또한, 상기 수신 유닛(915)은 상기 제어 유닛(913)의 제어에 따라 사용자 단말기와, 다른 DU, 혹은 S-GW, 혹은 CDN 노드로부터 각종 메시지를 수신한다.
상기 저장 유닛(917)은 상기 DU, 혹은 S-GW, 혹은 CDN 노드(900)의 콘텐트 전송 동작에 관련된 프로그램과 각종 데이터 등을 저장한다. 또한, 상기 저장 유닛(917)은 상기 수신 유닛(915)이 상기 사용자 단말기와, 다른 DU, 혹은 S-GW, 혹은 CDN 노드로부터 수신한 각종 메시지를 저장한다.
한편, 도 9에는 상기 DU, 혹은 S-GW, 혹은 CDN 노드(900)가 송신 유닛(911)과, 제어 유닛(913)과, 수신 유닛(915)과, 저장 유닛(917)과 같이 별도의 유닛들로 구현된 경우가 도시되어 있으나, 상기 송신 유닛(911)과, 제어 유닛(913)과, 수신 유닛(915)과, 저장 유닛(917)은 서로 병합되어 1개의 유닛으로 구현 가능함은 물론이다.
본 발명이 속하는 기술분야의 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시 예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.
한편, 본 명세서와 도면에는 본 발명의 바람직한 실시 예에 대하여 개시하였으며, 비록 특정 용어들이 사용되었으나, 이는 단지 본 발명의 기술 내용을 쉽게 설명하고 발명의 이해를 돕기 위한 일반적인 의미에서 사용된 것이지, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예 외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.

Claims (34)

  1. 모바일 콘텐트 네트워크(mobile content network)에서 사용자 단말기의 데이터 수신 방법에 있어서,
    제1 디지털 유닛(digital unit: DU)으로 콘텐트를 요구하는 요구 메시지를 송신하는 과정과,
    상기 제1 DU로부터 상기 요구된 콘텐트를 캐쉬(cache)하고 있는 제2 DU에 대한 정보를 포함하는 인터넷 프로토콜(internet protocol: IP) 추가(IP_ADD) 메시지를 수신하는 과정과,
    상기 IP_ADD 메시지에 포함되어 있는 상기 제2 DU에 대한 정보를 기반으로 스트림 제어 송신 프로토콜(stream control transmission protocol: SCTP) 연결을 업데이트하는 과정과,
    상기 업데이트된 SCTP 연결을 사용하여 상기 제2DU로부터 데이터를 수신하는 과정을 포함하는 방법.

  2. 제1항에 있어서,
    상기 IP_ADD 메시지에 대한 응답 메시지인 ACK (acknowledgement) 메시지를 상기 제1DU로 송신하는 과정을 더 포함함을 특징으로 하는 방법.
  3. 제1항에 있어서,
    상기 IP_ADD 메시지에 포함되어 있는 상기 제2DU에 대한 정보는 상기 제2DU의 IP 어드레스를 포함함을 특징으로 하는 방법.
  4. 제1항에 있어서,
    상기 IP_ADD 메시지는 바인딩 정책(binding policy)를 더 포함함을 특징으로 하는 방법.
  5. 모바일 콘텐트 네트워크(mobile content network)에서 제1 디지털 유닛(digital unit: DU)의 데이터 송신 방법에 있어서,
    사용자 단말기로부터 콘텐트를 요구하는 요구 메시지를 수신하는 과정과,
    상기 제1 DU 가 상기 요구된 콘텐트를 캐쉬(cache)하고 있는지 여부를 판단하는 과정과,
    상기 제1 DU가 상기 요구된 콘텐트를 캐쉬하고 있지 않을 경우, 상기 요구된 콘텐트를 캐쉬하고 있을 것으로 예상되는 제2 DU로 상기 요구 메시지를 라우팅(routing)하는 과정과,
    상기 사용자 단말기로 상기 제2 DU에 대한 정보를 포함하는 인터넷 프로토콜(internet protocol: IP) 추가(IP_ADD) 메시지를 송신하는 과정을 포함하는 방법.

  6. 제5항에 있어서,
    상기 제2DU로 상기 사용자 단말기에 대한 정보를 포함하는 IP_ADD 메시지를 송신하는 과정을 더 포함함을 특징으로 하는 방법.
  7. 제5항에 있어서,
    상기 사용자 단말기로부터 상기 IP_ADD 메시지에 대한 응답 메시지인 ACK (acknowledgement) 메시지를 수신하는 과정을 더 포함함을 특징으로 하는 방법.
  8. 제5항에 있어서,
    상기 IP_ADD 메시지에 포함되어 있는 상기 제2 DU에 대한 정보는 상기 제2 DU의 IP 어드레스를 포함함을 특징으로 하는 방법.
  9. 제5항에 있어서,
    상기 IP_ADD 메시지는 바인딩 정책(binding policy)를 더 포함함을 특징으로 하는 방법.
  10. 제6항에 있어서,
    상기 제2DU로 송신되는, 상기 사용자 단말기에 대한 정보를 포함하는 IP_ADD 메시지는 신규 스트림 식별자(stream identifier: ID)와, 시퀀스 번호(sequence number)를 포함함을 특징으로 하는 방법.
  11. 모바일 콘텐트 네트워크(mobile content network)에서 제2 디지털 유닛(digital unit: DU)의 데이터 송신 방법에 있어서,
    사용자 단말기로부터 콘텐트를 요구하는 요구 메시지를 수신한 제1 DU로부터 상기 요구 메시지를 수신하는 과정과,
    상기 제2 DU 가 상기 요구된 콘텐트를 캐쉬(cache)하고 있는지 여부를 판단하는 과정과,
    상기 제1 DU로부터 상기 사용자 단말기에 대한 정보를 포함하는 인터넷 프로토콜(internet protocol: IP) 추가(IP_ADD) 메시지를 수신하는 과정과,
    상기 제2 DU가 상기 사용자 단말기와의 업데이트된(updated) 스트림 제어 송신 프로토콜 (stream control transmission protocol: SCTP) 연결을 사용하여 상기 요구된 콘텐트를 캐쉬하고 있을 경우, 상기 사용자 단말기로 콘텐트를 송신하는 과정을 포함하는 방법.
  12. 삭제
  13. 제11항에 있어서,
    상기 IP_ADD 메시지는 신규 스트림 식별자(stream identifier: ID)와, 시퀀스 번호(sequence number)를 포함함을 특징으로 하는 방법.
  14. 모바일 콘텐트 네트워크(mobile content network)에서 사용자 단말기에 있어서,
    제1 디지털 유닛(digital unit: DU)으로 콘텐트를 요구하는 요구 메시지를 송신하는 송신 유닛과,
    상기 제1 DU로부터 상기 요구된 콘텐트를 캐쉬(cache)하고 있는 제2 DU에 대한 정보를 포함하는 인터넷 프로토콜(internet protocol: IP) 추가(IP_ADD) 메시지를 수신하는 수신 유닛과,
    상기 IP_ADD 메시지에 포함되어 있는 상기 제2 DU에 대한 정보를 기반으로 스트림 제어 송신 프로토콜(stream control transmission protocol: SCTP) 연결을 업데이트(update)하는 제어 유닛을 포함하고,
    상기 수신 유닛은 상기 업데이트된 SCTP 연결을 사용하여 상기 제2 DU로부터 데이터를 수신함을 특징으로 하는 사용자 단말기.
  15. 제14항에 있어서,
    상기 송신 유닛은 상기 IP_ADD 메시지에 대한 응답 메시지인 ACK (acknowledgement) 메시지를 상기 제1 DU로 송신함을 특징으로 하는 사용자 단말기.
  16. 제14항에 있어서,
    상기 IP_ADD 메시지에 포함되어 있는 상기 제2DU에 대한 정보는 상기 제2 DU의 IP 어드레스를 포함함을 특징으로 하는 사용자 단말기.
  17. 제14항에 있어서,
    상기 IP_ADD 메시지는 바인딩 정책(binding policy)를 더 포함함을 특징으로 하는 사용자 단말기.
  18. 모바일 콘텐트 네트워크(mobile content network)에서 제1 디지털 유닛(digital unit: DU)에 있어서,
    사용자 단말기로부터 콘텐트를 요구하는 요구 메시지를 수신하는 수신 유닛과,
    상기 제1 DU가 상기 요구된 콘텐트를 캐쉬(cache)하고 있는지 여부를 판단하는 제어 유닛과,
    상기 제1 DU가 상기 요구된 콘텐트를 캐쉬하고 있지 않을 경우, 상기 요구된 콘텐트를 캐쉬하고 있을 것으로 예상되는 제2 DU로 상기 요구 메시지를 라우팅(routing)하고, 상기 사용자 단말기로 상기 제2 DU에 대한 정보를 포함하는 인터넷 프로토콜(internet protocol: IP) 추가(IP_ADD) 메시지를 송신하는 송신 유닛을 포함함을 특징으로 하는 제1DU.
  19. 제18항에 있어서,
    상기 송신 유닛은 상기 제2 DU로 상기 사용자 단말기에 대한 정보를 포함하는 IP_ADD 메시지를 송신함을 특징으로 하는 제1DU.
  20. 제18항에 있어서,
    상기 수신 유닛은 상기 사용자 단말기로부터 상기 IP_ADD 메시지에 대한 응답 메시지인 ACK (acknowledgement) 메시지를 수신함을 특징으로 하는 제1DU.
  21. 제18항에 있어서,
    상기 IP_ADD 메시지에 포함되어 있는 상기 제2 DU에 대한 정보는 상기 제2 DU의 IP 어드레스를 포함함을 특징으로 하는 제1DU.
  22. 제18항에 있어서,
    상기 IP_ADD 메시지는 바인딩 정책(binding policy)를 더 포함함을 특징으로 하는 제1DU.
  23. 제19항에 있어서,
    상기 제2DU로 송신되는, 상기 사용자 단말기에 대한 정보를 포함하는 IP_ADD 메시지는 신규 스트림 식별자(stream identifier: ID)와, 시퀀스 번호(sequence number)를 포함함을 특징으로 하는 제1DU.
  24. 모바일 콘텐트 네트워크(mobile content network)에서 제2 디지털 유닛(digital unit: DU)에 있어서,
    사용자 단말기로부터 콘텐트를 요구하는 요구 메시지를 수신한 제1 DU로부터 상기 요구 메시지를 수신하는 수신 유닛과,
    상기 제2 DU가 상기 요구된 콘텐트를 캐쉬(cache)하고 있는지 여부를 판단하는 제어 유닛과,
    상기 제2 DU가 상기 사용자 단말기와의 업데이트된 (updated) 스트림 제어 송신 프로토콜 (stream control transmission protocol: SCTP) 연결을 사용하여 상기 요구된 콘텐트를 캐쉬하고 있을 경우, 상기 사용자 단말기로 콘텐트를 송신하는 송신 유닛을 포함하며,
    상기 수신 유닛은 상기 제1 DU로부터 상기 사용자 단말기에 대한 정보를 포함하는 인터넷 프로토콜(internet protocol: IP) 추가 (IP_ADD) 메시지를 수신함을 특징으로 하는 제2DU.
  25. 삭제
  26. 제24항에 있어서,
    상기 IP_ADD 메시지는 신규 스트림 식별자(stream identifier: ID)와, 시퀀스 번호(sequence number)를 포함함을 특징으로 하는 제2DU.
  27. 제1항에 있어서,
    제1 DU가 상기 요구된 콘텐트를 캐쉬하고 있지 않은 경우, 상기 사용자 단말기는 상기 제1 DU로부터 상기 IP_ADD메시지를 수신하고, 상기 제2 DU로부터 상기 데이터를 수신하는 과정을 포함함을 특징으로 하는 방법.
  28. 제1항에 있어서,
    상기 데이터는 상기 요구된 콘텐트를 포함함을 특징으로 하는 방법.
  29. 제11항에 있어서,
    상기 제1 DU가 상기 요구된 콘텐트를 캐쉬하고 있지 않은 경우, 상기 제2 DU는 상기 요구 메시지를 수신하고 상기 콘텐트를 송신하는 과정을 포함함을 특징으로 하는 방법.
  30. 제11항에 있어서,
    상기 데이터는 상기 요구된 콘텐트를 포함함을 특징으로 하는 방법.
  31. 제14항에 있어서,
    상기 수신 유닛은, 제1 DU가 상기 요구된 콘텐트를 캐쉬하고 있지 않은 경우, 상기 사용자 단말기는 상기 IP_ADD메시지를 제1 DU로부터 수신하고, 제2 DU로부터 상기 데이터를 수신함을 특징으로 하는 사용자 단말기.
  32. 제14항에 있어서,
    상기 데이터는 상기 요구된 콘텐트를 포함함을 특징으로 하는 사용자 단말기.
  33. 제24항에 있어서,
    상기 제1 DU가 상기 요구된 컨텐트를 캐쉬하고 있지 않은 경우, 상기 수신 유닛은 상기 요구 메시지를 수신하고, 상기 송신 유닛은 상기 콘텐트를 송신함을 특징으로 하는 제2DU.
  34. 삭제
KR1020130068180A 2013-06-14 2013-06-14 모바일 콘텐트 네트워크에서 데이터 전송 및 수신 장치 및 방법 KR102141444B1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020130068180A KR102141444B1 (ko) 2013-06-14 2013-06-14 모바일 콘텐트 네트워크에서 데이터 전송 및 수신 장치 및 방법
EP14172400.5A EP2814220B1 (en) 2013-06-14 2014-06-13 Apparatus and method for transmitting/receiving data in a mobile content network
US14/304,476 US9609684B2 (en) 2013-06-14 2014-06-13 Apparatus and method for transmitting/receiving data in mobile content network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020130068180A KR102141444B1 (ko) 2013-06-14 2013-06-14 모바일 콘텐트 네트워크에서 데이터 전송 및 수신 장치 및 방법

Publications (2)

Publication Number Publication Date
KR20140145716A KR20140145716A (ko) 2014-12-24
KR102141444B1 true KR102141444B1 (ko) 2020-08-05

Family

ID=50942139

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020130068180A KR102141444B1 (ko) 2013-06-14 2013-06-14 모바일 콘텐트 네트워크에서 데이터 전송 및 수신 장치 및 방법

Country Status (3)

Country Link
US (1) US9609684B2 (ko)
EP (1) EP2814220B1 (ko)
KR (1) KR102141444B1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110505646B (zh) * 2018-05-17 2021-06-11 大唐移动通信设备有限公司 一种数据传输方法及发送端
CN110022261A (zh) * 2019-05-20 2019-07-16 北京邮电大学 基于sctp-cmt传输协议的多路径传输方法及设备
WO2021002667A1 (en) * 2019-07-01 2021-01-07 Lg Electronics Inc. Method and apparatus for saving energy for a distributed unit in a wireless communication system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7080158B1 (en) 1999-02-09 2006-07-18 Nortel Networks Limited Network caching using resource redirection
US20100218034A1 (en) 2009-02-24 2010-08-26 Sirigiri Anil Kumar Reddy Method And System For Providing High Availability SCTP Applications

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6138162A (en) * 1997-02-11 2000-10-24 Pointcast, Inc. Method and apparatus for configuring a client to redirect requests to a caching proxy server based on a category ID with the request
US6799214B1 (en) * 2000-03-03 2004-09-28 Nec Corporation System and method for efficient content delivery using redirection pages received from the content provider original site and the mirror sites
CA2408766A1 (en) * 2001-10-17 2003-04-17 Telecommunications Research Laboratory Content delivery network bypass system
US20080126535A1 (en) * 2006-11-28 2008-05-29 Yinjun Zhu User plane location services over session initiation protocol (SIP)
GB0400080D0 (en) * 2004-01-05 2004-02-04 Nokia Corp Controlling data sessions in a communications system
US7929422B2 (en) * 2005-01-06 2011-04-19 Cisco Technology, Inc. Method of moving a transport connection among network hosts
EP2105003B1 (en) * 2006-12-28 2018-02-21 Telecom Italia S.p.A. Method and apparatus to control application messages between a client and a server having a private network address
US8892745B2 (en) * 2009-03-30 2014-11-18 Cisco Technology, Inc. Redirection of a request for information
JP2013505612A (ja) 2009-09-21 2013-02-14 テレフオンアクチーボラゲット エル エム エリクソン（パブル） モバイルネットワークにおけるキャッシング
US8856281B2 (en) * 2010-03-22 2014-10-07 At&T Intellectual Property I, L.P. Internet protocol version 6 content routing
WO2012167184A2 (en) * 2011-06-02 2012-12-06 Interdigital Patent Holdings, Inc. Methods, apparatus, and systems for managing converged gateway communications
US9130869B2 (en) * 2012-02-09 2015-09-08 Telefonaktiebolaget L M Ericsson (Publ) Methods of redirecting network forwarding elements and related forwarding elements and controllers
US9049613B2 (en) * 2013-06-06 2015-06-02 Seven Networks, Inc. Radio or network evaluation for selection based on measurements using application layer protocols at a mobile device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7080158B1 (en) 1999-02-09 2006-07-18 Nortel Networks Limited Network caching using resource redirection
US20100218034A1 (en) 2009-02-24 2010-08-26 Sirigiri Anil Kumar Reddy Method And System For Providing High Availability SCTP Applications

Also Published As

Publication number Publication date
KR20140145716A (ko) 2014-12-24
EP2814220A1 (en) 2014-12-17
EP2814220B1 (en) 2017-12-27
US20140369259A1 (en) 2014-12-18
US9609684B2 (en) 2017-03-28

Similar Documents

Publication Publication Date Title
US11343306B2 (en) Method, device and system for downloading data block of resource file
KR101379864B1 (ko) 네트워크 연산 요소들을 이용한 요청 라우팅
US10904205B2 (en) Content delivery network optimization system
US10162753B2 (en) Managing resources using resource expiration data
EP3729784B1 (en) Methods and apparatus for delivering content
US9571407B2 (en) Strategically scheduling TCP stream transmissions
WO2012089062A1 (zh) Cdn网络中的数据传输方法及设备
EP2897340A1 (en) Routing proxy for adaptive streaming
US20090031415A1 (en) Dynamic Network Tunnel Endpoint Selection
CA2430416A1 (en) A method and apparatus for discovering client proximity using multiple http redirects
US10848586B2 (en) Content delivery network (CDN) for uploading, caching and delivering user content
US20150006622A1 (en) Web contents transmission method and apparatus
KR102141444B1 (ko) 모바일 콘텐트 네트워크에서 데이터 전송 및 수신 장치 및 방법
KR101356961B1 (ko) 컨텐츠 전송 시스템, 이를 위한 방법 및 장치
US8706865B1 (en) Enhanced network communications using diagnostic information
KR101469310B1 (ko) 서비스 오버레이 네트워크에서 종단간 ＱｏＳ 보장형 콘텐츠 전달 방법 및 그 시스템
CN109788075B (zh) 专网网络系统、数据的获取方法及边缘服务器
WO2018090335A1 (zh) 一种缓存数据请求方法及相关设备
KR101407934B1 (ko) 컨텐츠 전송 시스템, 이를 위한 방법 및 장치
CN110795656A (zh) 一种基于分光技术的http缓存方法

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