KR20130039741A - 파일 시스템 추상화, 브로드캐스트 스케쥴 메시지들 및 선택적 수신을 이용하는 브로드캐스트 네트워크를 통한 파일 전달 - Google Patents
파일 시스템 추상화, 브로드캐스트 스케쥴 메시지들 및 선택적 수신을 이용하는 브로드캐스트 네트워크를 통한 파일 전달 Download PDFInfo
- Publication number
- KR20130039741A KR20130039741A KR1020127033547A KR20127033547A KR20130039741A KR 20130039741 A KR20130039741 A KR 20130039741A KR 1020127033547 A KR1020127033547 A KR 1020127033547A KR 20127033547 A KR20127033547 A KR 20127033547A KR 20130039741 A KR20130039741 A KR 20130039741A
- Authority
- KR
- South Korea
- Prior art keywords
- file
- broadcast
- files
- broadcast schedule
- delivery
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000012384 transportation and delivery Methods 0.000 title claims abstract description 765
- 238000000034 method Methods 0.000 claims abstract description 234
- 230000005540 biological transmission Effects 0.000 claims description 197
- 238000012544 monitoring process Methods 0.000 claims description 58
- 230000015654 memory Effects 0.000 claims description 56
- 238000012546 transfer Methods 0.000 claims description 48
- 238000004891 communication Methods 0.000 claims description 25
- 230000006870 function Effects 0.000 claims description 24
- 238000012937 correction Methods 0.000 claims description 22
- 230000002457 bidirectional effect Effects 0.000 claims description 4
- 238000013507 mapping Methods 0.000 claims description 4
- 238000012856 packing Methods 0.000 claims description 3
- 230000037406 food intake Effects 0.000 claims description 2
- 230000003213 activating effect Effects 0.000 claims 2
- 238000002716 delivery method Methods 0.000 claims 1
- 230000007246 mechanism Effects 0.000 abstract description 35
- 239000010410 layer Substances 0.000 description 213
- 238000007726 management method Methods 0.000 description 160
- 230000008569 process Effects 0.000 description 85
- 238000010586 diagram Methods 0.000 description 84
- 238000001914 filtration Methods 0.000 description 33
- 238000012545 processing Methods 0.000 description 27
- 230000003993 interaction Effects 0.000 description 16
- 238000012217 deletion Methods 0.000 description 14
- 230000037430 deletion Effects 0.000 description 14
- 238000005516 engineering process Methods 0.000 description 14
- 230000000737 periodic effect Effects 0.000 description 12
- 230000001413 cellular effect Effects 0.000 description 9
- 230000005055 memory storage Effects 0.000 description 8
- 230000011664 signaling Effects 0.000 description 8
- 230000004044 response Effects 0.000 description 7
- 101001076408 Homo sapiens Interleukin-6 Proteins 0.000 description 6
- 102100026019 Interleukin-6 Human genes 0.000 description 6
- 238000004422 calculation algorithm Methods 0.000 description 6
- 230000008859 change Effects 0.000 description 6
- 230000001419 dependent effect Effects 0.000 description 5
- 230000002452 interceptive effect Effects 0.000 description 5
- 239000000243 solution Substances 0.000 description 5
- 101001002709 Homo sapiens Interleukin-4 Proteins 0.000 description 4
- 102100020941 Interleukin-4 Human genes 0.000 description 4
- 230000007774 longterm Effects 0.000 description 4
- 230000008520 organization Effects 0.000 description 4
- 238000000926 separation method Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000013468 resource allocation Methods 0.000 description 2
- 238000000638 solvent extraction Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000001427 coherent effect Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000012792 core layer Substances 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000005670 electromagnetic radiation Effects 0.000 description 1
- 239000002360 explosive Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000002401 inhibitory effect Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000002829 reductive effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000000411 transmission spectrum Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/42—Arrangements for resource management
- H04H20/426—Receiver side
-
- 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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26266—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for determining content or additional data repetition rate, e.g. of a file in a DVB carousel according to its importance
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
- H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/64315—DVB-H
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/835—Generation of protective data, e.g. certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
- H04H60/06—Arrangements for scheduling broadcast services or broadcast-related services
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Databases & Information Systems (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
방법들, 시스템들 및 디바이스들은 파일들을 브로드캐스트 시스템을 통해서 모바일 디바이스들로 효율적으로 전달하는 메커니즘들 및 시스템들을 제공한다. 브로드캐스트를 위한 파일들은 파일 시스템에서의 디렉토리에 속하는 것으로 논리적으로 식별될 수도 있다. 브로드캐스트 스케쥴 메시지는 수신기 디바이스들에게 특정된 시간에서 브로드캐스트될 파일들을 통지할 뿐만 아니라, 그 파일들을 기술할 수도 있다. 파일은 파일 전달 파이프들로 송신될 수도 있으며, 파일 전달 파이프들은 상이한 대역폭 및 데이터 레이트들일 수도 있다. 실시형태들에 따라 구성되는 수신기 디바이스들은 브로드캐스트 스케쥴 메시지를 이용하여, 그 파일이 연관되는 서비스 또는 애플리케이션, 및 그 파일이 새로운 것인지 또는 이전에 수신된 파일에 대한 업데이트인지 여부에 기초하여, 수신될 파일들을 선택할 수도 있다. 수신기 디바이스들은 수신기 회로를 활성화함으로써, 그들의 광고된 브로드캐스트 윈도우 내에서 그 파일들을 캡쳐하고 그 수신된 파일들을 그 파일들을 요청하는 애플리케이션들 또는 서비스들로 전달한다.
Description
본 출원은 "File Delivery Over A Broadcast Network Using File System Abstraction, Broadcast Schedule Messages And Selective Reception" 란 발명의 명칭으로, 2010년 5월 28일자로 출원된, 미국 가특허출원 번호 제 61/349,598호에 대해 우선권의 이익을 주장하며, 이의 전체 내용들이 본원에서 참조로 포함된다.
무선 통신 기술들은 과거 수년 사이에 폭발적인 성장을 보여 왔다. 이러한 성장은 움직이는 대중에게 이동의 자유를 제공하고 하드와이어드 통신 시스템들에 대한 구속을 제거하는 무선 서비스들에 의해 자극을 받았다. 서비스 향상들의 결과로, 무선 서비스들의 인구가 빠르게 계속 증가할 것으로 예상되고 있다. 최근에는 무선 통신 서비스들에 텔레비전 및 다른 콘텐츠를 수신기 디바이스들에 브로드캐스트하는 능력이 추가되었다. 모바일 순방향-링크-전용 브로드캐스트 서비스들은 사용자들로 하여금, 모바일 브로드캐스트 송신들을 수신하도록 구성되는 모바일 수신기 디바이스들을 이용하여, 텔레비전 쇼들과 같은 멀티미디어 프로그래밍을 시청할 뿐만 아니라, 뉴스, 엔터테인먼트, 스포츠, 비즈니스, 및 다른 브로드캐스트 프로그래밍의 모바일 판들을 수신할 수 있도록 한다. 멀티미디어 브로드캐스트 서비스들의 성장은 매우 다양한 콘텐츠를 전달하고 사용자들과 상호작용하는 매력적인 통신 플랫폼을 나타낸다.
여러 실시형태들은 파일들을 수신기 디바이스들 상에서 실행하는 애플리케이션들에 전달하기 위해 브로드캐스트 및/또는 멀티캐스트 기반의 파일 전달 프레임워크 (FDF) 를 이용하는 시스템들, 디바이스들, 및 방법들을 제공한다. 구체적으로 설명하면, 여러 실시형태들은 브로드캐스트 및/또는 멀티캐스트 네트워크의 FDF 서비스를 이용하여 브로드캐스트 시스템을 통해서 수신기 디바이스들로 파일들을 효율적으로 전달하는 메커니즘들 및 시스템들을 제공한다. 브로드캐스트 및/또는 수신을 위한 파일들 및 데이터그램 패킷들은 브로드캐스트 네트워크에 의해 브로드캐스트 스케쥴 메시지 (BSM) 를 브로드캐스트함으로써 미리 광고될 수도 있다. BSM 들이 미래의 특정된 시간에 브로드캐스트될 파일들 및 데이터그램 패킷들을 수신기 디바이스들에게 통지하기 위해서 미리 송신될 수도 있다. 여러 실시형태들은 파일들을 좀더 시기 적절하고 코히런트하고 효과적인 방식으로 전달하기 위해서, FDF 서비스에 의해 제공되는, 내장 (built in) 리던던시, 에러 정정 및 신뢰성 메커니즘들을 이용한다.
본원에 포함되고 본 명세서의 일부를 구성하는 첨부 도면들은, 본 발명의 예시적인 실시형태들을 예시하며, 상기 주어진 일반적인 설명 및 이하에 주어진 상세한 설명과 함께, 본 발명의 특징들을 설명하는 기능을 한다.
도 1 은 일 실시형태에 사용하기에 적합한, 모바일 멀티미디어 브로드캐스트 통신 시스템 및 셀룰러 "유니캐스트" 통신 시스템을 도시하는 통신 시스템 블록도이다.
도 2 는 순방향 링크 전용 브로드캐스트 시스템의 브로드캐스트 통신 시스템 블록도의 대안적인 표현이다.
도 3 은 일 실시형태에 따른, 브로드캐스트 네트워크를 통해서 파일들을 전달하는 것에 관계되는 기능적 블록들을 도시하는 브로드캐스트 통신 시스템의 엘리먼트들의 시스템 블록도이다.
도 4 는 여러 실시형태들의 주요 기능적 구성요소들을 도시하는 개요 (overview) 시스템 블록도이다.
도 5 는 일 실시형태에 따른, 특정의 애플리케이션 (날씨 애플리케이션) 에 대한 파일들의 수취 및 수신을 도시하는 시스템 블록도이다.
도 6 은 일 실시형태에 따른, 특정의 애플리케이션 (iTV 애플리케이션) 에 대한 파일들의 수취 및 수신을 도시하는 시스템 블록도이다.
도 7 및 도 8 은 수신기 디바이스들에게 브로드캐스트 파이프로 송신되는 특정의 파일들의 타이밍 및 수신 파라미터들을 통지하기 위해서 어떻게 브로드캐스트 스케쥴 메시지들이 송신될 수 있는지를 도시하는 타이밍도들이다.
도 9 는 브로드캐스트 스케쥴 메시지에 사용하기에 적합한 예시적인 데이터 구조이다.
도 10 은 브로드캐스트 스케쥴 메시지에 사용하기에 적합한 또 다른 예시적인 데이터 구조이다.
도 11 은 다음 브로드캐스트 스케쥴 기간 (BSP) 의 브로드캐스트 스케쥴 흐름 (BSF) 에서 브로드캐스트 스케쥴 메시지 (BSM) 를 업데이트하는데, 어떻게 브로드캐스트 스케쥴 메시지의 다음 모니터 시간 데이터 필드가 이용될 수 있는지를 도시하는 타이밍도이다.
도 12 는 브로드캐스트 스케쥴 메시지들을 프로세싱하는 일 실시형태 방법의 프로세스 흐름도이다.
도 13 은 브로드캐스트 스케쥴 흐름 상에서 업데이트 검출을 구현하는 일 실시형태 방법의 프로세스 흐름도이다.
도 14 는 수신기 디바이스가 여러 시간들에서 브로드캐스트 네트워크의, 및/또는 브로드캐스트 흐름의 커버리지 영역의 외부에 있을 수도 있다는 것을 도시하는 타이밍도이다.
도 15 는 초기 획득 흐름 (IAF) 을 지원하는 시스템들 상에서 브로드캐스트 스케쥴 흐름 (BSF) 에 대한 업데이트들을 검출하는 일 실시형태 방법을 도시하는 타이밍도이다.
도 16 은 동일한 슈퍼프레임 내에서, 브로드캐스트 스케쥴 메시지의 2 개의 상이한 버전들을 수신하는 일 실시형태 방법을 도시하는 타이밍도이다.
도 17 은 초기 획득 흐름 (IAF) 시스템으로부터의 지원으로 브로드캐스트 스케쥴 메시지들 (BSMs) 을 프로세싱하는 일 실시형태 방법의 프로세스 흐름도이다.
도 18 은 수신기 디바이스와 브로드캐스트 서버 사이에 업데이트된 브로드캐스트 스케쥴 메시지들 (BSMs) 의 브로드캐스팅을 타이밍하는 일 실시형태 방법을 도시하는 타이밍도이다.
도 19 는 수신기 디바이스 상에서의 파일 전달 프레임워크 (FDF) 의 계층적 도면 (layered view) 을 도시하는 시스템 블록도이다.
도 20 은 상이한 애플리케이션들에 걸쳐서 파일 공유를 지원하는 파일 전달 프레임워크 (FDF) 를 구현하는 일 실시형태 방법의 프로세스 흐름도이다.
도 21 은 상이한 애플리케이션들에 걸쳐서 파일들을 공유하는데 이용될 수도 있는, 구조, 데이터흐름 및 하이-레벨 단계들을 도시하는 시스템 블록도이다.
도 22 는 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름, 및 파일 전달 프레임워크가 파일을 수신하거나 또는 거절하도록 선택하는 결정 프로세스를 도시하는 시스템 블록도이다.
도 23 은 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름, 및 수신기 디바이스 상의 파일 전달 프레임워크가 파일들을 수신하여 저장하는 프로세스를 도시하는 시스템 블록도이다.
도 24 는 애플리케이션들이 관심을 갖는 엘리먼트들만을 선택적으로 수신하는 일 실시형태 방법의 프로세스 흐름도이다.
도 25 는 브로드캐스트 스케쥴링 레코드들을 프로세싱하는 일 실시형태 방법의 프로세스 흐름도이다.
도 26 은 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름, 및 브로드캐스트 스케쥴 레코드들이 프로세싱되는 프로세스를 도시하는 시스템 블록도이다.
도 27 은 파일 전달 프레임워크 상에서의 파일들의 수신을 위한 일 실시형태 방법을 도시하는 시스템 블록도이다.
도 28 은 스크래치 공간 관리의 구조, 데이터흐름, 및 파일 전달 코어 (FDC) 에서 구현될 수도 있는 프로세스를 도시하는 시스템 블록도이다.
도 29 는 엘리먼트들을 프로세싱하여 저장하는 일 실시형태 방법의 프로세스 흐름도이다.
도 30 은 스크래치 공간으로부터 삭제할 아이템들을 선택하는 일 실시형태 방법의 프로세스 흐름도이다.
도 31 은 데이터를 정렬하고 편성하는 일 실시형태 방법의 구조 및 데이터흐름을 도시하는 시스템 블록도이다.
도 32 는 어떻게 긴급한 파일들이 긴급한 데이터 흐름 상에서 동시에 전달될 수 있는지를 도시하는 타임라인도이다.
도 33 은 어떻게 파일들이 별개의 브로드캐스트 서비스 흐름들을 통한 흐름 동안 프로세싱될 수 있는지를 도시하는 메시지 흐름도이다.
도 34 는 어떻게 멀티 주파수 네트워크 (MFN) 에서, 수신기 디바이스가 브로드캐스트 서비스 흐름에 대한 업데이트가 존재하는지를 검출하고, 그러나 동시에, 그 업데이트를 수신할 수 없다는 것을 식별할 수 있는지를 도시하는 타임라인도이다.
도 35 는 어떻게 새로운 멀티플렉스 (multiplex) 로 이동하는 수신기 디바이스들이 그 새로운 멀티플렉스에 대한 BSM 을 수신하도록 강제될 수 있는지를 도시하는 타임라인도이다.
도 36 은 하나 보다 많은 멀티플렉스가 동일한 무선 주파수 상에 있는 파일 전달 프레임워크 구성을 도시하는 타임라인/블록도이다.
도 37 은 파일 전달 코어 (FDC) 가 상이한 무선 주파수들 상에서 파일 다운로드들을 독립적으로 스케쥴링하도록 구성되는 파일 전달 프레임워크 구성을 도시하는 타임라인/블록도이다.
도 38 은 파일 전달 파이프 (FDP) 페이로드의 구조를 도시하는 시스템 블록도이다.
도 39 는 스토리지 이름들에의 파일 이름들의 파일 전달 프레임워크 맵핑을 도시하는 메시지 흐름도이다.
도 40 은 관리된 엘리먼트 테이블 (MET) 을 도시하는 블록도이다.
도 41 은 애플리케이션을 위한 스토리지 공간을 관리하는 일 실시형태 방법의 프로세스 흐름도이다.
도 42 는 애플리케이션용으로 수신될 엘리먼트를 위한 스토리지 공간을 체크하는 일 실시형태 방법의 프로세스 흐름도이다.
도 43 은 애플리케이션용으로 수신될 엘리먼트를 위한 스토리지 공간을 체크하는, 애플리케이션 계층과 파일 전달 프레임워크 사이의 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 44 는 애플리케이션 스토리지 공간으로의 수신된 파일의 이동을 위한 일 실시형태 방법의 프로세스 흐름도이다.
도 45 는 수신된 파일을 애플리케이션 스토리지 공간으로 이동하는 동안에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 46 은 파일 전달 파일 관리 (FDM) 계층의 관리된 엘리먼트 테이블에서 다수의 파일 이름들을 동일한 스토리지 이름에 맵핑하는 일 실시형태 방법의 프로세스 흐름도이다.
도 47 은 수신된 파일에 대해 애플리케이션 스토리지 공간이 충분하지 않은 상황들을 처리하는 일 실시형태 방법의 프로세스 흐름도이다.
도 48 은 수신된 파일에 대해 애플리케이션 스토리지 공간이 충분하지 않은 상황들을 처리할 때에, 애플리케이션 계층 (App 계층) 과 파일 전달 프레임워크 (FDF) 사이의 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 49 는 삭제 기능들을 처리하는 일 실시형태 방법의 프로세스 흐름도이다.
도 50 은 파일 전달 프레임워크 상에서의 파일 번들링 피쳐 (feature) 를 구현하는 일 실시형태 방법의 프로세스 흐름도이다.
도 51 은 파일 전달 프레임워크 상에서의 파일 번들링 피쳐에서 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 52 는 저장될 파일 번들에서 파일들을 선택하기 위해, 파일 전달 파일 관리 계층에 의해 사용될 선택 스트링 (selection string) 을 발생하는 일 실시형태 방법의 프로세스 흐름도이다.
도 53 은 파일 전달 프레임워크 상에서의 파일 번들링 피쳐에 의해 사용될 선택 스트링을 결정할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 54 는 파일 번들이 수신되어야 하는지 여부를 결정하는 일 실시형태 방법의 프로세스 흐름도이다.
도 55 는 파일 번들이 수신되어야 하는지 여부를 결정할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 56 은 파일 번들들에 파일들을 저장할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 57 은 관리된 엘리먼트 테이블 (MET) 에서 예시적인 파일 번들 엔트리를 도시하는 메시지 흐름도이다.
도 58 은 파일 번들을 수신하여 애플리케이션 스토리지 공간에 저장하는 일 실시형태 방법의 프로세스 흐름도이다.
도 59 는 파일 번들을 수신하여 애플리케이션 스토리지 공간에 저장할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 60 은 파일 번들로부터 수신되는 파일들을 삭제하는 일 실시형태 방법의 프로세스 흐름도이다.
도 61 은 파일 번들로부터 수신되는 파일들을 삭제하는 것에 관계되는 논리적 및 예시적인 데이터 흐름들을 도시하는 흐름도이다.
도 62 는 이전에 수신된 파일 번들을 수신할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 상호작용들을 디스플레이하는 예시적인 데이터흐름을 도시하는 흐름도이다.
도 63 은 파일 전달 코어 (FDC) 와 파일 전달 파일 관리 (FDM) 계층 사이에 데이터를 교환하는데 사용되는 여러 파일 전달 코어 페이로드 포맷들을 도시하는 데이터 구조도이다.
도 64 는 또 다른 예시적인 파일 전달 코어 페이로드 포맷을 도시하는 데이터 구조도이다.
도 65 는 2 개의 이름들을 갖는 단일 파일인 엘리먼트에 대한 예시적인 파일 전달 코어 페이로드 포맷을 도시하는 데이터 구조도이다.
도 66 은 2 개의 이름들을 갖는 파일을 갖는 파일 번들인 엘리먼트에 대한 예시적인 파일 전달 코어 페이로드 포맷을 도시하는 데이터 구조도이다.
도 67 은 브로드캐스트 스케쥴 메시지를 발생하여 송신하는 일 실시형태 방법의 프로세스 흐름도이다.
도 68 은 일 실시형태에 따른, 다수의 애플리케이션들에 대한 파일들의 수취 및 수신을 도시하는 시스템 블록도이다.
도 69 및 도 70 은 일 실시형태에 따른, 파일들을 파일 수취 시스템에 실행의뢰하는데 적합한 예시적인 데이터 스키마이다.
도 71 은 일 실시형태에 따른, 파일 송신 스케쥴링을 파일 수취 시스템의 부분으로서 도시하는 타임라인도이다.
도 72a 내지 도 72d 는 어떻게 파일들의 송신의 스케쥴링 및 파일 전달 서비스가 브로드캐스트 스케쥴 내에 파일 수취 시스템에 의해 수신되는 새로운 긴급한 파일들을 수용하는데 동적일 수 있는지를 도시하는 타임라인도들이다.
도 73 및 도 74 는 어떻게 파일 수취 시스템에 의한 파일들의 수취가 브로드캐스트 스케쥴 메시지의 발생을 유발하고 수취된 파일들의 송신을 브로드캐스트 스케쥴 메시지에 리스트된 바와 같은 스케쥴링된 시간에서 유발하는 지의 예시들이다.
도 75 는 브로드캐스트 파일 전달 서비스를 통해서 전달하는 파일을 수취하여 프로세싱하는 일 실시형태 방법의 프로세스 흐름도이다.
도 76 은 어떻게 와이드 (wide) 멀티플렉스 및 로컬 멀티플렉스로 이루어지는 상이한 신호 멀티플렉스들이 상이한 로컬 동작 기반구조들에서 브로드캐스트될 수 있는 지를 도시한다.
도 77 은 일 실시형태에 따른, 어떻게 상이한 용량 파일 전달 파이프들이 상이한 와이드 멀티플렉스 신호들에 할당될 수 있는지의 예시이다.
도 78a 및 도 78b 는 어떻게 파일 전달 송신들이 상이한 용량 파일 전달 파이프들을 통해서 송신될 수 있는 지를 도시한다.
도 79a 는 일 실시형태에 따른, 데이터 송신 편성 양태들을 도시하는 타임라인도이다.
도 79b 내지 도 79d 는 어떻게 파일 전달 송신들이 상이한 파일 전달 파이프들을 통해서 파티셔닝되어 송신될 수 있는 지를 도시한다.
도 79e 및 도 79f 는 여러 실시형태들에 따른, 데이터 송신 편성 (organization) 세부사항들을 도시하는 추가적인 타임라인도들이다.
도 80 은 어떻게 상이한 파일들이 병렬 파일 전달 파이프들을 통한 브로드캐스트에 대해 스케쥴링될 수 있는 지를 도시한다.
도 81a 내지 도 81c 는 파일들이 파일 전달 파이프 내에서 송신될 수도 있는 상이한 방법들을 도시한다.
도 82a 및 도 82b 는 어떻게 파일 전달 파이프 내에서 큰 파일의 송신이 긴급한 파일의 송신에 의해 차단될 수 있는 지를 도시한다.
도 83a 및 도 83b 는 파일들을 파일 전달 파이프들을 통해서 스케쥴링하여 송신하는 실시형태 방법들의 프로세스 흐름도들이다.
도 84 는 여러 실시형태들과 함께 사용하기에 적합한 모바일 수신기 디바이스의 소프트웨어 아키텍처도이다.
도 85 는 어떻게 수신기 디바이스 내에서 동작하는 애플리케이션들이 파일 전달 서비스 모듈에 의한 수신을 위한 파일들을 특정할 수 있는지의 예시이다.
도 86 은 일 실시형태에 따른, 파일 전달 카탈로그에 사용될 수도 있는 예시적인 데이터 스키마이다.
도 87a 및 도 87b 는 브로드캐스트 파일 전달 서비스를 통해서 전달되는 파일들을 수신하기 위해서 수신기 디바이스 내에서 구현될 수도 있는 실시형태 방법들의 프로세스 흐름도들이다.
도 88 은 일 실시형태에 사용하기에 적합한 수신기 디바이스의 구성요소 블록도이다.
도 89 는 일 실시형태에 사용하기에 적합한 서버 디바이스의 구성요소 블록도이다.
도 1 은 일 실시형태에 사용하기에 적합한, 모바일 멀티미디어 브로드캐스트 통신 시스템 및 셀룰러 "유니캐스트" 통신 시스템을 도시하는 통신 시스템 블록도이다.
도 2 는 순방향 링크 전용 브로드캐스트 시스템의 브로드캐스트 통신 시스템 블록도의 대안적인 표현이다.
도 3 은 일 실시형태에 따른, 브로드캐스트 네트워크를 통해서 파일들을 전달하는 것에 관계되는 기능적 블록들을 도시하는 브로드캐스트 통신 시스템의 엘리먼트들의 시스템 블록도이다.
도 4 는 여러 실시형태들의 주요 기능적 구성요소들을 도시하는 개요 (overview) 시스템 블록도이다.
도 5 는 일 실시형태에 따른, 특정의 애플리케이션 (날씨 애플리케이션) 에 대한 파일들의 수취 및 수신을 도시하는 시스템 블록도이다.
도 6 은 일 실시형태에 따른, 특정의 애플리케이션 (iTV 애플리케이션) 에 대한 파일들의 수취 및 수신을 도시하는 시스템 블록도이다.
도 7 및 도 8 은 수신기 디바이스들에게 브로드캐스트 파이프로 송신되는 특정의 파일들의 타이밍 및 수신 파라미터들을 통지하기 위해서 어떻게 브로드캐스트 스케쥴 메시지들이 송신될 수 있는지를 도시하는 타이밍도들이다.
도 9 는 브로드캐스트 스케쥴 메시지에 사용하기에 적합한 예시적인 데이터 구조이다.
도 10 은 브로드캐스트 스케쥴 메시지에 사용하기에 적합한 또 다른 예시적인 데이터 구조이다.
도 11 은 다음 브로드캐스트 스케쥴 기간 (BSP) 의 브로드캐스트 스케쥴 흐름 (BSF) 에서 브로드캐스트 스케쥴 메시지 (BSM) 를 업데이트하는데, 어떻게 브로드캐스트 스케쥴 메시지의 다음 모니터 시간 데이터 필드가 이용될 수 있는지를 도시하는 타이밍도이다.
도 12 는 브로드캐스트 스케쥴 메시지들을 프로세싱하는 일 실시형태 방법의 프로세스 흐름도이다.
도 13 은 브로드캐스트 스케쥴 흐름 상에서 업데이트 검출을 구현하는 일 실시형태 방법의 프로세스 흐름도이다.
도 14 는 수신기 디바이스가 여러 시간들에서 브로드캐스트 네트워크의, 및/또는 브로드캐스트 흐름의 커버리지 영역의 외부에 있을 수도 있다는 것을 도시하는 타이밍도이다.
도 15 는 초기 획득 흐름 (IAF) 을 지원하는 시스템들 상에서 브로드캐스트 스케쥴 흐름 (BSF) 에 대한 업데이트들을 검출하는 일 실시형태 방법을 도시하는 타이밍도이다.
도 16 은 동일한 슈퍼프레임 내에서, 브로드캐스트 스케쥴 메시지의 2 개의 상이한 버전들을 수신하는 일 실시형태 방법을 도시하는 타이밍도이다.
도 17 은 초기 획득 흐름 (IAF) 시스템으로부터의 지원으로 브로드캐스트 스케쥴 메시지들 (BSMs) 을 프로세싱하는 일 실시형태 방법의 프로세스 흐름도이다.
도 18 은 수신기 디바이스와 브로드캐스트 서버 사이에 업데이트된 브로드캐스트 스케쥴 메시지들 (BSMs) 의 브로드캐스팅을 타이밍하는 일 실시형태 방법을 도시하는 타이밍도이다.
도 19 는 수신기 디바이스 상에서의 파일 전달 프레임워크 (FDF) 의 계층적 도면 (layered view) 을 도시하는 시스템 블록도이다.
도 20 은 상이한 애플리케이션들에 걸쳐서 파일 공유를 지원하는 파일 전달 프레임워크 (FDF) 를 구현하는 일 실시형태 방법의 프로세스 흐름도이다.
도 21 은 상이한 애플리케이션들에 걸쳐서 파일들을 공유하는데 이용될 수도 있는, 구조, 데이터흐름 및 하이-레벨 단계들을 도시하는 시스템 블록도이다.
도 22 는 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름, 및 파일 전달 프레임워크가 파일을 수신하거나 또는 거절하도록 선택하는 결정 프로세스를 도시하는 시스템 블록도이다.
도 23 은 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름, 및 수신기 디바이스 상의 파일 전달 프레임워크가 파일들을 수신하여 저장하는 프로세스를 도시하는 시스템 블록도이다.
도 24 는 애플리케이션들이 관심을 갖는 엘리먼트들만을 선택적으로 수신하는 일 실시형태 방법의 프로세스 흐름도이다.
도 25 는 브로드캐스트 스케쥴링 레코드들을 프로세싱하는 일 실시형태 방법의 프로세스 흐름도이다.
도 26 은 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름, 및 브로드캐스트 스케쥴 레코드들이 프로세싱되는 프로세스를 도시하는 시스템 블록도이다.
도 27 은 파일 전달 프레임워크 상에서의 파일들의 수신을 위한 일 실시형태 방법을 도시하는 시스템 블록도이다.
도 28 은 스크래치 공간 관리의 구조, 데이터흐름, 및 파일 전달 코어 (FDC) 에서 구현될 수도 있는 프로세스를 도시하는 시스템 블록도이다.
도 29 는 엘리먼트들을 프로세싱하여 저장하는 일 실시형태 방법의 프로세스 흐름도이다.
도 30 은 스크래치 공간으로부터 삭제할 아이템들을 선택하는 일 실시형태 방법의 프로세스 흐름도이다.
도 31 은 데이터를 정렬하고 편성하는 일 실시형태 방법의 구조 및 데이터흐름을 도시하는 시스템 블록도이다.
도 32 는 어떻게 긴급한 파일들이 긴급한 데이터 흐름 상에서 동시에 전달될 수 있는지를 도시하는 타임라인도이다.
도 33 은 어떻게 파일들이 별개의 브로드캐스트 서비스 흐름들을 통한 흐름 동안 프로세싱될 수 있는지를 도시하는 메시지 흐름도이다.
도 34 는 어떻게 멀티 주파수 네트워크 (MFN) 에서, 수신기 디바이스가 브로드캐스트 서비스 흐름에 대한 업데이트가 존재하는지를 검출하고, 그러나 동시에, 그 업데이트를 수신할 수 없다는 것을 식별할 수 있는지를 도시하는 타임라인도이다.
도 35 는 어떻게 새로운 멀티플렉스 (multiplex) 로 이동하는 수신기 디바이스들이 그 새로운 멀티플렉스에 대한 BSM 을 수신하도록 강제될 수 있는지를 도시하는 타임라인도이다.
도 36 은 하나 보다 많은 멀티플렉스가 동일한 무선 주파수 상에 있는 파일 전달 프레임워크 구성을 도시하는 타임라인/블록도이다.
도 37 은 파일 전달 코어 (FDC) 가 상이한 무선 주파수들 상에서 파일 다운로드들을 독립적으로 스케쥴링하도록 구성되는 파일 전달 프레임워크 구성을 도시하는 타임라인/블록도이다.
도 38 은 파일 전달 파이프 (FDP) 페이로드의 구조를 도시하는 시스템 블록도이다.
도 39 는 스토리지 이름들에의 파일 이름들의 파일 전달 프레임워크 맵핑을 도시하는 메시지 흐름도이다.
도 40 은 관리된 엘리먼트 테이블 (MET) 을 도시하는 블록도이다.
도 41 은 애플리케이션을 위한 스토리지 공간을 관리하는 일 실시형태 방법의 프로세스 흐름도이다.
도 42 는 애플리케이션용으로 수신될 엘리먼트를 위한 스토리지 공간을 체크하는 일 실시형태 방법의 프로세스 흐름도이다.
도 43 은 애플리케이션용으로 수신될 엘리먼트를 위한 스토리지 공간을 체크하는, 애플리케이션 계층과 파일 전달 프레임워크 사이의 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 44 는 애플리케이션 스토리지 공간으로의 수신된 파일의 이동을 위한 일 실시형태 방법의 프로세스 흐름도이다.
도 45 는 수신된 파일을 애플리케이션 스토리지 공간으로 이동하는 동안에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 46 은 파일 전달 파일 관리 (FDM) 계층의 관리된 엘리먼트 테이블에서 다수의 파일 이름들을 동일한 스토리지 이름에 맵핑하는 일 실시형태 방법의 프로세스 흐름도이다.
도 47 은 수신된 파일에 대해 애플리케이션 스토리지 공간이 충분하지 않은 상황들을 처리하는 일 실시형태 방법의 프로세스 흐름도이다.
도 48 은 수신된 파일에 대해 애플리케이션 스토리지 공간이 충분하지 않은 상황들을 처리할 때에, 애플리케이션 계층 (App 계층) 과 파일 전달 프레임워크 (FDF) 사이의 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 49 는 삭제 기능들을 처리하는 일 실시형태 방법의 프로세스 흐름도이다.
도 50 은 파일 전달 프레임워크 상에서의 파일 번들링 피쳐 (feature) 를 구현하는 일 실시형태 방법의 프로세스 흐름도이다.
도 51 은 파일 전달 프레임워크 상에서의 파일 번들링 피쳐에서 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 52 는 저장될 파일 번들에서 파일들을 선택하기 위해, 파일 전달 파일 관리 계층에 의해 사용될 선택 스트링 (selection string) 을 발생하는 일 실시형태 방법의 프로세스 흐름도이다.
도 53 은 파일 전달 프레임워크 상에서의 파일 번들링 피쳐에 의해 사용될 선택 스트링을 결정할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 54 는 파일 번들이 수신되어야 하는지 여부를 결정하는 일 실시형태 방법의 프로세스 흐름도이다.
도 55 는 파일 번들이 수신되어야 하는지 여부를 결정할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 56 은 파일 번들들에 파일들을 저장할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 57 은 관리된 엘리먼트 테이블 (MET) 에서 예시적인 파일 번들 엔트리를 도시하는 메시지 흐름도이다.
도 58 은 파일 번들을 수신하여 애플리케이션 스토리지 공간에 저장하는 일 실시형태 방법의 프로세스 흐름도이다.
도 59 는 파일 번들을 수신하여 애플리케이션 스토리지 공간에 저장할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터흐름 및 상호작용들을 도시하는 흐름도이다.
도 60 은 파일 번들로부터 수신되는 파일들을 삭제하는 일 실시형태 방법의 프로세스 흐름도이다.
도 61 은 파일 번들로부터 수신되는 파일들을 삭제하는 것에 관계되는 논리적 및 예시적인 데이터 흐름들을 도시하는 흐름도이다.
도 62 는 이전에 수신된 파일 번들을 수신할 때에, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 상호작용들을 디스플레이하는 예시적인 데이터흐름을 도시하는 흐름도이다.
도 63 은 파일 전달 코어 (FDC) 와 파일 전달 파일 관리 (FDM) 계층 사이에 데이터를 교환하는데 사용되는 여러 파일 전달 코어 페이로드 포맷들을 도시하는 데이터 구조도이다.
도 64 는 또 다른 예시적인 파일 전달 코어 페이로드 포맷을 도시하는 데이터 구조도이다.
도 65 는 2 개의 이름들을 갖는 단일 파일인 엘리먼트에 대한 예시적인 파일 전달 코어 페이로드 포맷을 도시하는 데이터 구조도이다.
도 66 은 2 개의 이름들을 갖는 파일을 갖는 파일 번들인 엘리먼트에 대한 예시적인 파일 전달 코어 페이로드 포맷을 도시하는 데이터 구조도이다.
도 67 은 브로드캐스트 스케쥴 메시지를 발생하여 송신하는 일 실시형태 방법의 프로세스 흐름도이다.
도 68 은 일 실시형태에 따른, 다수의 애플리케이션들에 대한 파일들의 수취 및 수신을 도시하는 시스템 블록도이다.
도 69 및 도 70 은 일 실시형태에 따른, 파일들을 파일 수취 시스템에 실행의뢰하는데 적합한 예시적인 데이터 스키마이다.
도 71 은 일 실시형태에 따른, 파일 송신 스케쥴링을 파일 수취 시스템의 부분으로서 도시하는 타임라인도이다.
도 72a 내지 도 72d 는 어떻게 파일들의 송신의 스케쥴링 및 파일 전달 서비스가 브로드캐스트 스케쥴 내에 파일 수취 시스템에 의해 수신되는 새로운 긴급한 파일들을 수용하는데 동적일 수 있는지를 도시하는 타임라인도들이다.
도 73 및 도 74 는 어떻게 파일 수취 시스템에 의한 파일들의 수취가 브로드캐스트 스케쥴 메시지의 발생을 유발하고 수취된 파일들의 송신을 브로드캐스트 스케쥴 메시지에 리스트된 바와 같은 스케쥴링된 시간에서 유발하는 지의 예시들이다.
도 75 는 브로드캐스트 파일 전달 서비스를 통해서 전달하는 파일을 수취하여 프로세싱하는 일 실시형태 방법의 프로세스 흐름도이다.
도 76 은 어떻게 와이드 (wide) 멀티플렉스 및 로컬 멀티플렉스로 이루어지는 상이한 신호 멀티플렉스들이 상이한 로컬 동작 기반구조들에서 브로드캐스트될 수 있는 지를 도시한다.
도 77 은 일 실시형태에 따른, 어떻게 상이한 용량 파일 전달 파이프들이 상이한 와이드 멀티플렉스 신호들에 할당될 수 있는지의 예시이다.
도 78a 및 도 78b 는 어떻게 파일 전달 송신들이 상이한 용량 파일 전달 파이프들을 통해서 송신될 수 있는 지를 도시한다.
도 79a 는 일 실시형태에 따른, 데이터 송신 편성 양태들을 도시하는 타임라인도이다.
도 79b 내지 도 79d 는 어떻게 파일 전달 송신들이 상이한 파일 전달 파이프들을 통해서 파티셔닝되어 송신될 수 있는 지를 도시한다.
도 79e 및 도 79f 는 여러 실시형태들에 따른, 데이터 송신 편성 (organization) 세부사항들을 도시하는 추가적인 타임라인도들이다.
도 80 은 어떻게 상이한 파일들이 병렬 파일 전달 파이프들을 통한 브로드캐스트에 대해 스케쥴링될 수 있는 지를 도시한다.
도 81a 내지 도 81c 는 파일들이 파일 전달 파이프 내에서 송신될 수도 있는 상이한 방법들을 도시한다.
도 82a 및 도 82b 는 어떻게 파일 전달 파이프 내에서 큰 파일의 송신이 긴급한 파일의 송신에 의해 차단될 수 있는 지를 도시한다.
도 83a 및 도 83b 는 파일들을 파일 전달 파이프들을 통해서 스케쥴링하여 송신하는 실시형태 방법들의 프로세스 흐름도들이다.
도 84 는 여러 실시형태들과 함께 사용하기에 적합한 모바일 수신기 디바이스의 소프트웨어 아키텍처도이다.
도 85 는 어떻게 수신기 디바이스 내에서 동작하는 애플리케이션들이 파일 전달 서비스 모듈에 의한 수신을 위한 파일들을 특정할 수 있는지의 예시이다.
도 86 은 일 실시형태에 따른, 파일 전달 카탈로그에 사용될 수도 있는 예시적인 데이터 스키마이다.
도 87a 및 도 87b 는 브로드캐스트 파일 전달 서비스를 통해서 전달되는 파일들을 수신하기 위해서 수신기 디바이스 내에서 구현될 수도 있는 실시형태 방법들의 프로세스 흐름도들이다.
도 88 은 일 실시형태에 사용하기에 적합한 수신기 디바이스의 구성요소 블록도이다.
도 89 는 일 실시형태에 사용하기에 적합한 서버 디바이스의 구성요소 블록도이다.
여러 실시형태들을 첨부 도면들을 참조하여 자세히 설명한다. 가능한 경우에는 언제나, 동일한 또는 유사한 부재들을 지칭하기 위해서 동일한 참조 번호들이 도면들에 걸쳐서 사용된다. 특정의 예들 및 구현예들에 대한 참조들은 예시적인 목적들을 위한 것으로, 본 발명 또는 청구항들의 범위를 한정하는 것으로 의도되지 않는다.
단어 "예시적인" 은 "일 예, 사례, 또는 예시로서 기능하는 것" 을 의미하도록 본원에서 사용된다. 본원에서 "예시적인" 으로서 설명하는 임의의 구현예는 다른 구현예들보다 반드시 바람직하거나 또는 유리한 것으로 해석될 필요는 없다.
용어들 "모바일 디바이스" 및 "수신기 디바이스" 는 모바일 미디어 브로드캐스트 수신기들, 셀룰러 전화기들, 개인 텔레비전 디바이스들, 개인 휴대정보 단말기들 (PDA's), 팜탑 컴퓨터들, 무선 전자 메일 수신기들 (예컨대, Blackberry? 및 Treo? 디바이스들), 멀티미디어 인터넷 이용가능한 셀룰러 전화기들 (예컨대, Blackberry Storm?), 글로벌 측위 시스템 (GPS) 수신기들, 무선 게이밍 제어기들, 운송체들 (예컨대, 자동차들) 내의 수신기들 및 프로그래밍가능 프로세서 및 메모리를 포함하는 유사한 개인 전자 디바이스들 및/또는 MediaFLO? FLO TV? 브로드캐스트들과 같은 모바일 TV 브로드캐스트 송신들을 수신하여 프로세싱하는 순방향-링크-전용 모바일 TV 브로드캐스트 수신기 회로 중 임의의 하나 또는 모두를 지칭하도록 교환가능하게 사용된다. 그러나, 용어들 "모바일 디바이스" 및 "수신기 디바이스" 는 열거된 수신기들의 리스트에 한정되지 않아야 하며, 모바일 브로드캐스트 텔레비전 서비스들 중 임의의 서비스를 수신하거나 및/또는 아래에서 설명하는 브로드캐스트 표준들 중 임의의 표준을 구현할 수 있는 임의의 디바이스를 포함할 수도 있다.
단어들 "브로드캐스트" 및 "멀티캐스트" 는 다수의 수신 디바이스들에 의해 동시에 수신될 수 있는 데이터 (정보 패킷들) 의 송신을 의미하도록 본원에서 교환가능하게 사용된다. 브로드캐스트 메시지의 예들은 콘텐츠 브로드캐스트들 (콘텐츠 흐름) 및 메타데이터 메시지들과 같은 오버헤드 정보 브로드캐스트들 (오버헤드 흐름) 을 포함한, 모바일 텔레비전 서비스 브로드캐스트 신호들이다.
본원에서 사용될 때, 용어 "파일" 은 컴퓨팅 디바이스 상에 저장될 수도 있는 매우 다양한 데이터 구조들, 데이터의 집합체들 및 데이터베이스 파일들 중 임의의 것을 지칭한다.
본원 및 도면들에서는, 다음의 용어들 및 약어들이 사용된다 : 브로드캐스트 스케쥴 메시지 (BSM); 브로드캐스트 스케쥴 레코드들 (BSR); 브로드캐스트 스케쥴 기간 (BSP); 브로드캐스트 스케쥴 흐름 (BSF); 브로드캐스트 스케쥴 모니터링 레코드 (BSMR); 조건부 액세스 솔루션들 (CAS); 일정 또는 가변 비트 레이트 (CBR/VBR); 디렉토리 정보 메시지 (DIM); DIST (구성된 레이트에서 파일들 및 오버헤드 메시지들을 송신하는 배포 구성요소); 파일 전달 프레임워크 (FDF); 파일 전달 파이프 (FDP); 파일 수취 시스템 (File Ingestion System; FIS); 흐름 브로드캐스트 스케쥴 레코드 (Flow Broadcast Schedule Record; FBSR); 순방향 에러 정정 (FEC) 코드들; FLO 서빙 노드들 또는 FSN (FLO 에 대한 전송 네트워크 특정의 FSN, 또는 특정의 전송 기술들에 대한 적응들을 제공하는, 일반적으로 다른 브로드캐스트 기술들에 대한 BSN 일 수도 있는, 실제 OTA 송신과 관계되는 구성요소들); 초기 획득 흐름 (Initial Acquisition Flow; IAF); IP 데이터 서비스들 (IPDS); 로컬 멀티플렉스 (LM); 로컬 동작 기반구조 (Local Operating Infrastructure; LOI); 서비스 품질 (QoS); 오버헤드 스케쥴링 서버 또는 OSS (오버헤드 메시지들, 메타데이터 및/또는 버전 변경들을 관리하고 광고하는 구성요소); 무선 주파수 (RF); 실시간 (RT); 유형-값-길이 (Type-Value-Length; TLV); 주문형 비디오 (Video-On-Demand; VOD) 애플리케이션 (vodApp); 및 와이드 멀티플렉스 (Wide Multiplex; WM).
다수의 상이한 모바일 브로드캐스트 텔레비전 서비스들 및 브로드캐스트 표준들이 이용가능하거나 또는 미래에 예상되며, 이의 모두가 여러 실시형태들을 구현하고 이로부터 이득을 취할 수도 있다. 이런 서비스들 및 표준들은 예컨대, OMA BCAST (Open Mobile Alliance Mobile Broadcast Services Enabler Suite), MediaFLO?, DVB-IPDC (Digital Video Broadcast IP Datacasting), DVB-H (Digital Video Broadcasting-Handheld), DVB-SH (Digital Video Broadcasting-Satellite services to Handhelds), DVB-H2 (Digital Video Broadcasting-Handheld 2), ATSC-M/H (Advanced Television Systems Committee-Mobile/Handheld), 및 CMMB (China Multimedia Mobile Broadcasting) 을 포함한다. 이들 브로드캐스트 포맷들의 각각은 브로드캐스트 통신 채널을 포함한다. 참조의 용이를 위해, 여러 실시형태들이 MediaFLO? 시스템을 참조하여 설명되며, 이 시스템은 FLO TV? 브로드캐스트 시스템들에서 구현된다. 그러나, MediaFLO? 전문용어 및 기술적인 세부사항들에 대한 참조들은 단지 예시적인 목적들을 위한 것이며, 청구항 용어에서 특히 언급하지 않는 한, 청구항들의 범위를 특정의 FLO 통신 시스템 또는 기술에 한정하는 것으로 의도되지 않는다.
여러 실시형태들은 파일들을 브로드캐스트 시스템을 통해서 모바일 디바이스들로 효율적으로 전달하는 메커니즘들 및 시스템들을 제공한다. 브로드캐스트 및 수신을 위한 파일들은 파일 시스템 내 디렉토리에 속하는 것으로 논리적으로 식별될 수도 있다. 수신기 디바이스들로의 파일들의 브로드캐스트를 위해, 이 파일 시스템 추상화의 배터리-효율적인 사용을 하기 위해서, 브로드캐스트 시스템은 다운로드에 이용가능한 파일들에 관한 정보를 운반하는 메커니즘, 및 이들 파일들이 브로드캐스트될 시간들을 이용할 수도 있다. 여러 실시형태들에서, 이것은 파일들의 브로드캐스팅 이전에 또는 파일들의 브로드캐스팅과 함께, 브로드캐스트 스케쥴 메시지들 (BSMs) 을 브로드캐스트함으로써 달성될 수도 있다.
일반적으로, BSM 들은 수신기 디바이스들에게 미래에 브로드캐스트될 파일들 뿐만 아니라, 파일들이 브로드캐스트될 것으로 수신기 디바이스들이 예상할 수 있는 특정의 시간 프레임을 통지한다. 각각의 BSM 은 여러 서비스들 또는 애플리케이션들에 의해 브로드캐스트되는 파일들의 연관 (예컨대, 애플리케이션 특정의 디렉토리 상의 서비스 ID 또는 파일 이름); 브로드캐스트되는 파일이 새로운, 업데이트된 또는 반복된 파일인지의 식별 (예컨대, 파일 ID/엘리먼트 ID 또는 버전 번호); 파일이 수신될 수 있는 브로드캐스트 전송 스트림 (예컨대, IP 어드레스 및 UDP 포트 번호에 의해 식별되는 흐름 ID, IP 흐름); 파일이 브로드캐스트될 시간 (예컨대, 전달 윈도우); 및 전달 스케쥴 정보 (예컨대, BSM) 가 새로운 정보로 업데이트될 수도 있는 시기와 같은 파일 콘텐츠 및 브로드캐스트 스케쥴 정보를 포함할 수도 있다.
BSM 은 주어진 주파수 (예컨대, 채널 (55)) 상에서 브로드캐스트되는 파일들에 대한 전달 스케쥴 정보를, 그 주파수 (예컨대, MediaFLO? 로컬 대 와이드 멀티플렉스) 에서, 및/또는 전송 기술 (예컨대, MediaFLO? 또는 ATSC) 에 대해서, 송신 스펙트럼의 부분 상에, 제공하는 (예컨대, 흐름 ID, IP 어드레스 및 UDP 포트 번호 등에 의해 정의되는 바와 같은) 오버헤드 전송 스트림의 부분으로서 운반될 수도 있다. 이들 오버헤드 흐름들, 이런 송신들에 이용되는 채널, 흐름 또는 주파수, BSM 들이 브로드캐스트되는 신호 또는 슈퍼-프레임들의 부분, 및 BSM 들을 송신하는데 사용되는 전송 기술의 이용가능성은 부트스트랩 오버헤드 흐름 (예컨대, MediaFLO? 송신들에서의 IAF) 을 통해서 발견될 수도 있다.
본 실시형태들에 따라 구성되는 수신기 디바이스는 광고될 상이한 파일 브로드캐스트들로부터 파일을 선택하는데 BSM 메시지를 이용할 수도 있다. 수신기 디바이스는 이 BSM 을 이용하여, 그 파일이 연관되는 서비스 또는 애플리케이션, 그 파일이 새로운 것인지 또는 이전에 수신된 파일에 대한 재송신 또는 업데이트인지 여부, 또는 다양한 다른 인자들에 기초하여, 특정의 파일을 수신할 수도 있다. 여러 실시형태들에서, BSM 들은 애플리케이션/서비스 ID 들의 별칭 (aliasing) 및/또는 전송하는 파일들의 번들들의 기술 (description) 을 지원할 수도 있다. 여러 실시형태들에서, 각각의 BSM 은 브로드캐스트 스케쥴 정보의 부분을 따로 광고할 수도 있다. 이것은 콘텐츠 신선도와 수신기 디바이스들이 현재까지 BSM의 최신 버전으로 유지하기 위해 소비해야 하는 배터리 전력의 양 사이에 트레이드-오프를 제공한다.
여러 실시형태들은 콘텐츠 제공자들이 브로드캐스트 시스템에게 브로드캐스트할 새로운 파일들을 통지하기 위해 사용할 수 있는 인터페이스를 제공할 수도 있는 브로드캐스트 네트워크 내에 파일 수취 시스템 (FIS) 을 포함하거나 또는 그 브로드캐스트 네트워크와 통신하는 파일 수취 시스템 (FIS) 을 포함할 수도 있다. 콘텐츠 제공자들은 각각의 파일의 시의성 요구사항들 (예컨대, 레이턴시 허용오차) 및 송신 강건성 요구사항들 (예컨대, 순방향 에러 정정의 레벨 또는 재송신들의 수) 과 같은, 파일들에 대한 브로드캐스트 전송 요구사항들을 특정하기 위해서, 파일 수취 시스템을 이용할 수도 있다. 파일 수취 시스템은 새로운 파일 수취 시에 콘텐츠 제공자들에 의해 특정되는 전송 요구사항들을 이용하고, 송신용으로 이미 수락되어 스케쥴링된 파일들과 함께, 새로운 파일을 브로드캐스트 송신 스트림으로 팩킹하려고 시도할 수도 있다. 여러 실시형태들에서, 파일 수취는 브로드캐스트 송신 스트림으로의 새로운 파일들의 팩킹이 성공적이지 않을 (즉, 새로운 파일이 송신 스트림 내에, 송신용으로 이미 스케쥴링된 파일들과 함께, 꼭 들어 맞지 않을 수도 있을) 때에 실패한 것으로 간주될 수도 있다. 여러 실시형태들에서, 파일 수취 시스템은 팩킹이 초기에 성공적이지 않을 때, 이전에 수취된 파일들의 송신을 억제하는 것을 대가로, 새로운 파일 수취가 계속되도록, 파일들에 걸쳐서 우선순위를 고려할 수도 있다.
일단 새로운 파일이 파일 수취 시스템에 의해 프로세싱되었으면, 파일 수취 시스템은 단지 성공적으로 스케쥴링된 파일들의 일부 만을 브로드캐스트 스케쥴 기간 (BSP) 에 걸쳐서 광고하는 BSM 을 발생할 수도 있다. 수신기 디바이스들은 BSM 내의 정보를 이용하여 그들의 파일 브로드캐스트들의 수신을 설계할 수도 있다. 따라서, 수신기 디바이스들이 디바이스 상의 애플리케이션에 대한 관련 파일이 브로드캐스트된다고 결정할 때, 수신기 디바이스는 수신기 회로의 활성화를 그 광고된 브로드캐스트 스케쥴 기간 동안 스케쥴링할 수 있다. 성공적으로 스케쥴링된 파일들의 일부만을 광고함으로써, 새로운 파일들을 최종 브로드캐스트 BSM 에 의해 다루어지는 시간 기간에 뒤따르는 브로드캐스트 스케쥴에 삽입하고, 그 수정된 스케쥴에 따라서 새로운 BSM 을 브로드캐스트함으로써, 새로운 파일 수취들이 도모될 수도 있다. 여러 실시형태들에서, 브로드캐스트 시스템은 BSM 에 대한 업데이트들 및 파일들의 송신을 기존 스케쥴 정보에 기초하여 제어할 수도 있다.
위에서 설명한 바와 같이, 임의의 주어진 시간에, BSM 들은 브로드캐스트 스케쥴 정보의 일 부분 만을 광고할 수도 있다. 이것은 콘텐츠 신선도와, 한편으로는, 스케쥴링 유연성, 다른 한편으로는, 수신기 디바이스들에 의한 전력 소비 사이에 트레이드-오프를 제공한다. 콘텐츠 신선도는 각각의 BSM 에서 브로드캐스트 스케쥴 정보의 양을 제한함으로써 최대화될 수도 있다. 이것은, 브로드캐스트 스케쥴의 더 큰 부분 (즉, BSM 에서 선언되지 않은 부분) 이 새로 수취된 파일들을 삽입하도록 조정될 수도 있기 때문에, 더 큰 파일 송신 스케쥴링 유연성을 가능하게 한다. BSM 들이 빈번히 변하게 함으로써, 브로드캐스터들은 더 짧은 통지 (notice) 에 의해 파일들을 브로드캐스트하여, 파일 전달 우선순위들 및 스케쥴들에서의 변경들을 도모할 수도 있다. 그러나, BSM 을 빈번하게 변경하는 것은 수신기 디바이스들이 새로운 BSM 들을 수신하는데 좀더 자주 전력을 상승시키는 것을 필요로 한다. 각각의 전력 상승은 수신기 디바이스의 배터리 전력의 추가적인 양을 소모한다. 따라서, BSM 들에 대한 빈번한 업데이트들로 인해, 수신기 디바이스들이 더 많은 배터리 전력을 소모하게 될 수도 있다. 따라서, 수신기 디바이스들에 의한 전력 소비는 각각의 BSM 에 어드레스되는 브로드캐스트 스케쥴의 양을 최대화함으로써 최소화될 수도 있다. 따라서, 브로드캐스터들은 사용자 경험을 향상시키기 위해서, 스케쥴링 유연성과 디바이스 전력 소비 사이의, BSM 들에 대한 업데이트들의 빈도 (frequency) 에서의 균형을 유지할 수도 있다.
파일 수취 시스템은 또한 파일들과 연관되는 속성들의 수취를 지원할 수도 있다. 파일 수취 시스템은 오버헤드 메시지 (예컨대, BSM) 를 통해서 운반될 수도 있도록 파일 속성들을 포맷할 수도 있다. 여러 실시형태들에서, 수신기 디바이스들은 이들 파일 속성들을 이용하여 수신 및 다운로드를 위한 파일들을 선택할 수도 있다. 여러 실시형태들에서, 수신기 디바이스들은 그들의 파일 속성들에 기초하여 파일들을 선택하기 위해서 필터링 기준들을 이용할 수도 있다.
여러 실시형태들에서, 파일 수취 시스템은 하나 보다 많은 파일을 따로 수취하는 것을 지원할 수도 있다. 이들 실시형태들에서, 파일 수취 시스템은 2개 이상 파일들을, 단일 파일로서의 송신을 위해, 또는 더 적은 세트의 더 큰 파일들로서의 송신을 위해 함께 번들할 수도 있다. 파일들이 함께 번들될 수 없으면, 파일 수취 시스템은 송신을 위한 각각의 파일을 독립적으로 스케쥴링할 수도 있다. 파일들을 함께 번들하는 것은 순방향 에러 정정 (FEC) 보호의 좀더 효율적인 적용을 가능하게 하여, 그 송신된 파일들 내에 포함되는 데이터의 무결성을 향상시킨다.
여러 실시형태들에서, 브로드캐스트 리소스들 (예컨대, 브로드캐스트 신호의 대역폭 또는 세그먼트들) 은 시스템의 전체 효율 및 리소스 예약 목표들 (예컨대, 작은 파일들에 대해 하나의 파이프, 그리고 큰 파일들에 대해 하나의 파이프) 을 향상시키기 위해, 파일 전달 "파이프들" 에 트래픽 엔지니어링 툴로서 편성될 수도 있다. 파일 전달 파이프들은 파일 전송을 위해 리소스 할당을 캡쳐하고, 다수의 상이한 파일들을 하나 이상의 송신 스트림들 상으로 멀티플렉싱하는 것을 지원한다. 브로드캐스트 리소스들을 파일 전달 파이프들에 편성하는 것은 그 집합한 할당된 리소스들에 걸쳐서 파일들을 시분할 멀티플렉싱하는 파일들의 중앙 집중된 스케쥴링을 가능하게 함으로서, 효율을 향상시킬 수도 있다. 따라서, 리소스들이 편성되는 방법은 효율적이어야 하며, 상이한 파일 전달 애플리케이션들과 연관되는 상이한 요구사항들을 해결해야 한다. 여러 실시형태들에서, 리소스들은 다수의 파일 전달 파이프들로 편성될 수도 있으며, 파일 수취 시스템은 브로드캐스트 시스템에 정의되는 여러 파일 전달 파이프들로부터 통지를 받을 수도 있다. 그렇게 통지를 받으면, 파일 수취 시스템은 각각의 파일에 대해 특정되는 애플리케이션-특정의 전달 요구사항들을 해결하는 방법으로, 그리고 상이한 파이프들 (예컨대, 큰 파일 전송들 동안 작은 파일들의 HOL (head-of-line) 블록킹을 피하기 위해 작은 파일들에 대해 하나의 파이프 및 큰 파일들에 대해 하나의 파이프) 의 셋업에 이르게 했을 지도 모르는 트래픽 엔지니어링 목표에 따라서, 송신 리소스들에 걸쳐서 브로드캐스트를 위한 파일들을 스케쥴링할 수도 있다.
여러 실시형태들은 파일 전달 파이프들을 정의하고 상이한 파이프들에 걸친 송신을 위해 파일들을 스케쥴링하는 다양한 전략들을 구현하는 것을 지원한다. 예를 들어, 여러 실시형태들에서, 애플리케이션들의 종류들은 특정의 파이프들로 맵핑될 수도 있으며, 예컨대, 낮은 레이턴시 요구사항들을 갖는 작은 파일들은 전용 파이프들 상에서 브로드캐스트될 수도 있다. 여러 실시형태들에서, 파일 수취 시스템은 짧은 파일 송신들을 가능하게 하기 위해서, 큰 파일들의 송신을 따로 떨어진 브로드캐스트 윈도우들로 분할할 수도 있다. 여러 실시형태들에서, 파일 수취 시스템은 동일한 파이프 상에서 상이한 흐름들을 통해서 다수의 동시발생 파일 송신들을 스케쥴링할 수도 있다.
여러 실시형태들에서, 브로드캐스트-측 애플리케이션 또는 서비스는 전송에 적합한 하나 이상의 파일들로의 조합을 위해서, 다수의 파일들을 파일 수취 시스템에 실행의뢰할 수도 있다. 대응하는 수신기-측 애플리케이션 또는 서비스는 단지 브로드캐스트될 파일들의 작은 서브-세트와 호환되거나 또는 관계될 수도 있다. 이 경우, 브로드캐스트-측 애플리케이션 또는 서비스는, 그 시스템이 수신기-측 애플리케이션 또는 서비스에 의해 사용될 수도 있는 메타데이터를 식별하는 것을 포함하는 BSM 또는 유사한 오버헤드 파일 (예컨대, 카탈로그 파일) 을 구성할 수 있도록, 적용가능성 메타데이터 (applicability metadata) 를 파일 전달 서비스에 공급할 수도 있다. 예를 들어, BSM 오버헤드 파일은 브로드캐스트 기간 내에 브로드캐스트될 파일들의 모두를, 브로드캐스트될 파일들에 대한 식별 또는 적용가능성 정보와 함께, 리스트할 수도 있다. 이런 식별하는 메타데이터는 파일들을 수신할 수 있거나 수신해야 하는 애플리케이션들 또는 서비스들의 이름 또는 식별자와 같은, 애플리케이션-특정의 속성들을 포함할 수도 있다. 수신기 디바이스 상에서, BSM 오버헤드 파일은 수신기 디바이스에 의해 수신되어, 대응하는 수신기-측 애플리케이션에 의해 수신용 파일들을 선택하기 위해 사용될 수도 있다. 여러 실시형태들에서, 수신기-측 애플리케이션들은 다양한 애플리케이션-특정의 로직 및 이용가능한 속성들에 기초하여, 그리고 BSM 오버헤드 파일에 포함되는 식별 또는 적용가능성 정보를 이용함으로써, 이 선택을 행할 수도 있다.
여러 실시형태들에서, 수신기-측 애플리케이션은, 수신기 디바이스 상의 파일 전달 서비스 모듈에 원하는 애플리케이션 또는 서비스 파일 이름들, 또는 원하는 파일들에 대한 식별자들에 관해 표시함으로써, 파일 전달 서비스로부터의 그 BSM 에 기술되어 있는 선택된 파일들의 수신을 요청할 수도 있다. 수신기 디바이스 상의 파일 전달 서비스 모듈은 그 BSM 로부터, 언제, 그리고 어느 채널/흐름/브로드캐스트 리소스 상에서, 원하는 파일들을 포함하는 그 표시된 (indicated) 파일들이 브로드캐스트될지를 결정할 수도 있다. 수신기 디바이스 내의 프로세서는 이 정보를 이용하여, 단지, 브로드캐스트가 수신기-측 애플리케이션들에 의해 요청받은 파일들 또는 호환되는 파일들을 포함할 가능성이 많을 경우에만, 수신기 회로를 "웨이크-업" 할 수도 있다. BSM 내의 정보는 또한 수신기 디바이스 상의 프로세서로 하여금, 수신기가 데이터에 대해 진행하고 청취하는 것을 필요로 하는 정확한 시간 프레임을 정확하게 위치 지정가능하게 할 수도 있다. 수신기가 진행하는 것을 필요로 하는 정확한 시간 프레임을 정확하게 위치 지정함으로써, 수신기 디바이스는 프로세싱 리소스들을 다른 작업들에 이용가능하게 하면서도, 상당한 배터리 전력을 절약할 수도 있다.
여러 실시형태들에서, 파일 전달 서비스 (예컨대, FDF 서비스) 를 이용하는 브로드캐스트-측 애플리케이션은 그 파일들과 연관되는 애플리케이션-특정의 속성들을, 파일들이 전송을 위해 파일 수취 시스템에 실행의뢰되는 시간에, 제공할 수도 있다. 이런 애플리케이션-특정의 속성들은 BSM 을 통해서 수신기 디바이스들에 전송될 수도 있다. 수신기-측 애플리케이션들은 관심 파일을 특징화한 애플리케이션들-특정의 파라미터들 내에 규칙적인 또는 논리적 표현을 표시함으로써, 수신기 디바이스의 파일 전달 서비스 모듈로부터의 파일 캡쳐를 요청할 수도 있다. 관심 파일들을 특징화하는데 규칙적인 또는 논리적 표현들을 이용함으로써, 수신기 디바이스는 그 애플리케이션-특정의 파라미터들을, 수신을 위한 파일들을 선택하는 필터링 기준들으로서 이용할 수도 있다. 수신기 디바이스의 파일 전달 서비스 모듈은 이런 필터링 기준들을 이용하여, 그 BSM 으로부터, 원하는 파일들의 특성들 (일자/시간, 흐름 ID 등) 을 식별함으로써, 오직 브로드캐스트될 파일들의 서브세트만을 수신할 수도 있다.
여러 실시형태들은 다양한 모바일 멀티-미디어 브로드캐스트 시스템들 내에서 구현될 수도 있으며, 이의 일 예가 도 1 에 도시되어 있다. MediaFLO? 브로드캐스트 네트워크와 같은, 모바일 멀티미디어 브로드캐스트 네트워크 (1) 는, 본원에서 브로드캐스트 동작 센터 (4) (또는, 도면들에서 "BOC") 로서 지칭되는 모바일 브로드캐스트 네트워크 제어 센터에 의해 제어되는 복수의 브로드캐스트 송신기들 (2) 을 일반적으로 포함한다. 모바일 멀티미디어 브로드캐스트 네트워크 (1) 는 브로드캐스트 송신기들 (2) 로부터의 콘텐츠를, 모바일 텔레비전 수신기들, 스마트폰들, 셀룰러폰들, 개인 휴대정보 단말기들 (PDA), 상호작용 게임 디바이스들, 노트북들, 스마트북들, 넷북들, 데이터 프로세싱 장치, 또는 다른 이런 전자 디바이스들과 같은, 수신기 디바이스들 (10) 에 의한 수신을 위한 모바일 브로드캐스트 송신들 (3) 로서, 브로드캐스트한다. 모바일 브로드캐스트 네트워크 제어 센터 (4) (또한, 브로드캐스트 동작 센터 또는 "BOC" 로도 지칭됨) 내에는, 모바일 멀티미디어 브로드캐스트 네트워크 (1) 의 오버헤드 흐름을 통한 브로드캐스트를 위해 실시간 콘텐츠 브로드캐스트들, 전자 서비스 안내들, 카탈로그 메시지들 및 콘텐츠 브로드캐스트들에 관한 BSM 들의 발생, 및 메타데이터 메시지들의 발생을 관리하는 하나 이상의 서버들 및 시스템들이 일반적으로 있을 것이다.
통상의 콘텐츠 전달 시스템에 더해, 모바일 멀티미디어 브로드캐스트 네트워크 (1) 는 또한 모바일 멀티미디어 브로드캐스트 네트워크 (1) 를 통한 브로드캐스트를 위한 파일들을 수신하고, 저장하고, 스케쥴링하고 포맷하는 파일 수취 시스템 서버 (FIS) (31) 를 포함할 수도 있다. 파일 수취 시스템 서버 (31) 는 직접 네트워크 접속 또는 간접 네트워크 접속, 예컨대 인터넷 (7) 을 통해서, 파일 콘텐츠 제공자 (9) 로부터의 브로드캐스트를 위한 파일들을 수신할 수도 있다.
모바일 멀티미디어 브로드캐스트 네트워크 (1) 에 더해, 수신기 디바이스들 (10) 은 또한 유니캐스트 네트워크 (11), 예컨대, 셀룰러 전화기 네트워크를 통해서 통신하도록 일반적으로 구성될 것이다. 일반적인 셀룰러 전화기 네트워크는 네트워크 동작 센터 (14) 에 커플링되는 복수의 셀룰러 기지국들 (12) 을 포함하며, 그 네트워크 동작 센터는 모바일 디바이스들 (10) 과 다른 네트워크 목적지들 사이에, 예컨대, 전화기 지상통신 라인들 (예컨대, POTS 네트워크, 미도시됨) 및 인터넷 (7) 을 통해서, 보이스 및 데이터 콜들을 접속하도록 동작한다. 수신기 디바이스들 (10) 과 유니캐스트 네트워크 (11) 사이의 통신들은 양방향 무선 통신 링크들 (13), 예컨대, 4G, 3G, CDMA, TDMA, 및 다른 셀룰러 전화기 통신 기술들을 통해서 달성된다. 인터넷 데이터 통신들을 용이하게 하기 위해서, 유니캐스트 네트워크 (11) 는 일반적으로 인터넷 (7) 에의 접속을 제공하는 네트워크 동작 센터 (14) 에 커플링된, 또는 그 내부의 하나 이상의 서버들 (16) 을 포함할 것이다. 추가 실시형태들에서, 유니캐스트 네트워크 (11) 는 WiFi, WiMAX 등과 같은 무선 광역 네트워크일 수도 있다. 수신기 디바이스들 (10) 은 브로드캐스트 서비스들에 가입하고 사용자 상호작용 메시지들을 브로드캐스터로 송신하려는 목적을 위해서, 유니캐스트 네트워크 (11) 를 통해서, 예컨대, 인터넷 (7) 을 경유한 브로드캐스트 네트워크 서버 (6) 로의 IP 데이터 콜을 통해서, 브로드캐스트 네트워크 (1) 와 통신할 수도 있다.
도 2 는 일 실시형태에 따른, 브로드캐스트 네트워크 (1) (예컨대, MediaFLO? 브로드캐스트 네트워크) 의 부분 내에서의 정보 흐름들을 도시한다. 파일 콘텐츠 제공자들 (9) 은 브로드캐스트 파일 전달 서비스를 통한 송신을 위한 파일들을 파일 수취 서버 (31) 에 제공할 수도 있다. 파일 수취 서버 (31) 는 아래에서 좀더 충분히 설명하는 바와 같이 브로드캐스트를 위한 파일들을 스케쥴링하고 저장할 수도 있다. 스케쥴 브로드캐스트 시간에, 파일 수취 서버 (31) 는 스케쥴링된 파일들을 브로드캐스트 동작 센터 (4) (BOC) 에 제공할 수도 있으며, 여기서, 브로드캐스트 신호가 콘텐츠 흐름들 (26) 및 오버헤드 흐름들 (28) 을 포함하는 정보의 멀티플렉스로서 발생된다. 따라서, BSM 이 하나 이상의 오버헤드 흐름들 (28) 의 부분으로서 송신되는 동안, 파일 전달 서비스를 통한 송신을 위한 파일들이 콘텐츠 흐름들 (26) 의 부분으로서 송신될 수도 있다. 수신기 디바이스들 (10) 은 멀티플렉스 신호를 수신하며, BSM 을 포함하는 오버헤드 흐름 (28) 및 다른 오버헤드 정보 스트림들 (예컨대, 제어 채널) 을 개별적으로 수신할 수 있으며, 그 BSM 내의 정보를 이용하여 콘텐츠 흐름 (26) 으로부터 특정의 파일들을 수신할 수 있다.
일반적인 멀티미디어 모바일 브로드캐스트 시스템에서, 정보는 복수의 슈퍼프레임들로 편성되는 무선 신호들로 송신된다. 각각의 슈퍼프레임은 주파수 대역 내의 주파수들, 및 브로드캐스트 콘텐츠 및 오버헤드 정보를 통신하는 복수의 데이터 패킷들을 인코딩하는 설정 시간 경계들 (예컨대, 슈퍼프레임 경계들) 내의 시간의 관점에서 편성되는 복수의 신호들을 포함한다. 예를 들어, MediaFLO? 브로드캐스트 시스템에서, 브로드캐스트 송신들은 6 MHz 주파수 대역 (예를 들어 716 MHz 내지 722 MHz) 에 걸쳐있는 1 초 (one-second) 슈퍼프레임들로 편성된다. MediaFLO? 브로드캐스트 신호들은 다른 주파수 대역들 상에서 전송될 수도 있으며, 다수의 신호들이 다수의 다른 주파수 대역들을 이용하여 동시에 전송될 수도 있다. 각각의 슈퍼프레임은 오버헤드 흐름에 전용된 부분 및 콘텐츠 흐름들과 연관되는 다수의 채널들을 운반하는 부분을 포함할 수도 있다. 위에서 언급한 바와 같이, 오버헤드 흐름 및 다른 오버헤드 스트림들 (예컨대, 제어 채널) 내의 정보는, 수신기 디바이스들에게, 슈퍼프레임 내 어디에서 그 특정의 콘텐츠 흐름이 획득될 수 있는지, 뿐만 아니라, 얼마나 많은 패킷들이 그 콘텐츠 흐름의 스트림들과 연관되는지를 통지한다.
도 3 은 파일 전달 서비스를 통해서 파일들을 전달하는 여러 실시형태들을 구현하는데 적합한 브로드캐스트 통신 시스템의 브로드캐스터 측 상의 시스템 기능적 구성요소들을 도시한다. 실시간 콘텐츠 제공자 서버들 (8) 은 실시간 콘텐츠 (예컨대, 오디오, 비디오, 텍스트 등) 를 브로드캐스트 동작 센터 (4) 내의 실시간 인코더 (39) 로 전송할 수도 있다. 파일 콘텐츠 제공자들 (9) 은 파일 전달 서비스를 통한 전달을 위한 파일들을 파일 수취 서버 (31) 에 제공할 수도 있다. 파일 수취 서버 (31) 는 그 수신된 파일들을 로컬 데이터베이스 (32) 에 저장하고, 그 수신된 파일들을 브로드캐스트를 위해 스케쥴링할 수도 있다. 스케쥴링된 브로드캐스트 시간에 관련한 정보 뿐만 아니라, 파일 속성 데이터가, 오버헤드 시그널링 서버 (OSS) (34) 에 제공될 수도 있으며, 오버헤드 시그널링 서버는 그 BSM 에서의 오버헤드 버전 변경들을 관리하고 광고하는 구성요소이다. 아래에서 좀더 충분히 설명하는 바와 같이, 파일 수취 서버 (31) 에 의한 파일들의 송신의 수취 및 스케쥴링은, 그 스케쥴링된 브로드캐스트 시간들에 대한 빈번한 변경들이 오버헤드 시그널링 서버 (34) 로 통신될 수 있도록, 동적일 수도 있다.
오버헤드 시그널링 서버 (34) 는 업데이트된 BSM 을 배포 서버 (33) 에 제공할 수도 있으며, 이 배포 서버는 구성되는 레이트에서 파일들 및 오버헤드 메시지들을 송신하는 구성요소이다. 배포 서버 (33) 는 송신을 위해 BSM 을 순방향 링크 전용 (FLO) 서비스 노드 (FSN) (35) 에 제공할 수도 있으며, 이 서비스 노드는 브로드캐스트 네트워크 (1) 를 통한 송신을 위해 BSM 을 오버헤드 데이터 전달 시스템 (36) 으로 안내한다. 파일들을 송신하는 스케쥴링된 시간 근처에서, 파일 수취 서버 (31) 는, 로컬 데이터베이스 (32) 와 함께, 송신을 위한 파일들을 배포 서버 (33) 에 제공할 수도 있다. 배포 서버 (33) 는 그들 파일들을 FLO 서비스 노드 (35) 에, 각각의 파일이 브로드캐스트될 시기를 특정하는 제어 데이터와 함께 제공할 수도 있다. FLO 서비스 노드 (35) 는 송신을 위한 파일들을 파일 전달 시스템 (38) 에 전달할 수도 있으며, 이 파일 전달 시스템은 브로드캐스트 네트워크 (1) 를 통해서 파일들을 송신한다. 그 후, 모바일 디바이스들 (10) 은 브로드캐스트 네트워크 (1) 로부터 무선 데이터 송신들을 통해서 파일들을 수신할 수도 있다.
도 3 이 파일 전달 시스템의 구성요소들을 별개의 유닛들 또는 서버들로서 도시하지만, 당업자는 상이한 기능적 프로세스들의 일부 또는 모두가 도 3 에 도시된 것 이외의 단일 서버 또는 더 적은 서버들 내에서 구현될 수도 있음을 명백히 알 수 있을 것이다. 예를 들어, 오버헤드 서비스 서버 (34), 배포 서버 (33) 및 흐름 서비스 노드 (35) 는 단일 서버 디바이스 내에 파일 수취 시스템 (31) 과 함께 구현될 수도 있으며, 동시에, 이들 기능들의 각각은 상이한 소프트웨어 모듈들 또는 통합된 소프트웨어 시스템에 의해 달성될 수도 있다.
여러 실시형태들의 예시로서, 도 4 는 MediaFLO 파일 전달 프레임워크 (FDF) (40) 에 관계되는 상부-레벨 구성요소들을 나타낸다. 파일 전달 프레임워크 (40) 는 상이한 파일 전달 애플리케이션들에 대한 지원을 동시에 제공할 수도 있다. 논리적 컨셉들의 형태의 파일들의 전달은, 파일들이 콘텐츠 제공자들로부터 수신되고 브로드캐스트 시스템을 통해서 송신되며 수신기 디바이스들에 의해 수신될 때에, 파일들의 조작 및 관리에 이용되는 실시형태 방법들을 포함한다. 하이-레벨에서, 브로드캐스트 파일 전달 시스템 (40) 은 통신 시스템의 브로드캐스트 측인 헤드엔드 (headend), 및 송신된 파일들을 선택적으로 수신하여 저장하는 수신기 디바이스를 포함한다.
헤드엔드에서, 본원에서 "헤드엔드 애플리케이션들" (42, 43) 로서 지칭되는, 송신을 위한 파일들을 제공하는 애플리케이션들은 전달을 위한 파일들을 정의한다. 헤드엔드의 서버 내에서, 파일 수취 시스템 (31) 은 전송을 위한 파일들을 파일 콘텐츠 제공자들 또는 헤드엔드 애플리케이션들 (42, 43) 로부터 수신하여, 전달을 위한 파일들을 브로드캐스트 스케쥴로 스케쥴링할 수도 있다. 파일 수취 시스템 (31) 은 또한 파일 전송 네트워크 (41) 를 통한 추후 전송을 위해 성공적으로 스케쥴링된 파일들을 메모리에 저장할 수도 있다. 헤드엔드 애플리케이션들 (42, 43) 에 의해 제공되는 파일들은 파일 수취 시스템 (31) 을 통해서 수취되는 하나 이상의 전송 파일들에 패키지되어, 파일 전송 네트워크 (41) 를 통해서 수신기 디바이스들로 전달될 수도 있다.
MediaFLO? 수신기 디바이스와 같은 수신기 디바이스 상에서, 디바이스 애플리케이션들 (45, 46) 은 수신되는 파일들을 특징화하거나 또는 식별하고, 그들 파일들을 파일 전달 서비스 모듈 (44) 로부터 요청할 수도 있다. 파일 전달 서비스 모듈 (44) 은 수신기 디바이스에, 디바이스 애플리케이션들 (45, 46) 에 파일 캡쳐 서비스들을 제공하도록 구성되는 소프트웨어로서 구현될 수도 있다. 파일 전달 서비스 모듈 (44) 은 파일들에 대한 요청에 응답하여, 전달 및 스케쥴링 정보를 이용하여, 요청된 흐름들을 캡쳐하고 그들을 메모리에 저장할 수도 있다. 파일 전달 서비스 모듈 (44) 은 파일들의 수신, 스토리지 및 유지관리를 관리할 수도 있다.
송신될 파일들을 조립할 때에, 파일 수취 시스템 (31) 은 전송 파일들을 파일 시스템 유사성을 이용하여 생성할 수도 있으며, 여기서, 애플리케이션-특정의 디렉토리 구조에서의 파일 경로 이름이 애플리케이션들의 세트에 대한 파일을 고유하게 식별한다. 위에서 설명한 바와 같이, 브로드캐스트 시스템의 헤드엔드의 서버 내에, 파일 수취 시스템 (31) 이, 전송을 위한 파일들을 수신하고, 전달 적정 시기들 (opportunities) 에 대해 파일들을 브로드캐스트 스케쥴로 스케쥴링하고, 브로드캐스트 네트워크의 파일 전송 네트워크 (41) 를 통한 추후 전송을 위해 성공적으로 스케쥴링된 파일들을 메모리에 저장하기 위해서, 제공될 수도 있다. 파일 수취 시스템 (31) 은 파일 이름과 같은 그 파일들에 관련한 추가적인 속성들, 그 파일을 기술하는 파라미터들 (예컨대, 장르, 파일 유형, 등), 파일 콘텐츠들을 기술하는 파라미터들 (예컨대, 개개의 데이터그램 패킷들의 소스 및 로케이션, 그 파일에 포함되는 데이터그램 패킷들의 아이덴티티, 애플리케이션 또는 파일 유형들 등), 및 전송을 위한 파일들의 콘텐츠와 연관되는 다른 정보를 특정할 수도 있다. 파일 수취 시스템 (31) 은 또한 각각의 파일의 브로드캐스트 전달 요구사항들을 기술하는 파라미터들을 특정할 수도 있다. 여러 실시형태들에서, 파일 수취 시스템 (31) 은 버전화 목적들을 위해서, 그리고 실행의뢰된 파일들을 순방향 에러 정정 (FEC) 코드들의 효율적인 적용을 위해 조합된 패키지들로 번들하기 위해서 사용될 수 있는 파일들에, 고유 식별자 (예컨대, fileID) 를 할당할 수도 있다. 파일 수취 시스템 (31) 은 또한 그들의 브로드캐스트 전송 신뢰성을 향상시키기 위해 순방향 에러 정정 코드들을 수취된 파일들에 적용할 수도 있다.
일 실시형태에서, 파일 수취 시스템 (31) 은 새로 수신된 전송을 위한 파일들에 대해 브로드캐스트 전달 적정 시기들을 스케쥴링할 수도 있다. 이 프로세스의 부분으로서, 파일 수취 시스템 (31) 은 여러 파라미터들에 기초하여 송신 스케쥴을 결정할 수도 있다. 예를 들어, 일 실시형태에서, 파일 수취 시스템 (31) 은 송신 스케쥴을 파일 사이즈들 및 이용가능한 리소스들의 함수로서 생성할 수도 있다. 또다른 실시형태에서, 송신 스케쥴들은 또한 콘텐츠 제공자들에 의해 파일들에 할당되는 우선순위를 고려할 수도 있다. 여러 실시형태들에서, 파일 브로드캐스트 시간들의 스케쥴링은, 새로 수신된 파일들 및 이전에 수취된 파일들에 대한 브로드캐스트 전달 요구사항들이 만족되도록, 송신을 위한 시작 시간들을 알고리즘적으로 결정하기 위해 수행될 수도 있다. 파일 수취 시스템 (31) 은 성공적으로 스케쥴링된 파일들을, 파일 전송 네트워크 (41) 를 통한 추후 전송을 위해 저장할 수도 있다. 파일 수취 시스템 (31) 은 적당한 시간에, 파일 수취 시스템 (31) 에 의해 이전에 결정된 파일 스케쥴 정보에 따라서, 스케쥴링된 파일들을 브로드캐스트 네트워크에 발송할 수도 있다.
송신을 위한 파일들을 스케쥴링할 때에, 파일 수취 시스템 (31) 은 송신 리소스들, 예컨대, 파일 전송 네트워크 (41) 에서 정의되는 파일 전달 파이프들을 인지할 수도 있다. 파일 전달 파이프들의 이용가능성에 관한 정보를 이용하여, 파일 수취 시스템 (31) 은 파일 콘텐츠 제공자들에 의해 정의되는 애플리케이션-특정의 전달 요구사항들을 해결할 수 있도록 하기 위해서, 여러 송신 리소스들에 걸쳐서 파일들을 스케쥴링할 수도 있다. 일부 실시형태들에서, 파일 수취 시스템 (31) 은 어떤 종류들의 애플리케이션들에 대해 특정의 파이프들을 이용하도록 구성될 수도 있다. 예를 들어, 낮은 레이턴시 요구사항들을 갖는 작은 파일들은 전용 송신 파이프들 상에서 브로드캐스트될 수도 있다. 이의 대안으로, 파일 수취 시스템 (31) 은 감소된 지연으로 짧은 파일 송신들이 가능하도록, 큰 파일들의 송신들을 따로 떨어진 브로드캐스트 윈도우들로 분할할 수도 있다. 파일 수취 시스템 (31) 은 또한 상이한 송신 파이프들을 통해 동일한 유형의 다수의 동시발생 송신들을 스케쥴링할 수도 있다.
여러 실시형태들에서, 파일 전송 네트워크 (41) 는 MediaFLO? 네트워크 또는 다른 브로드캐스트 네트워크일 수도 있다. 여러 실시형태들에서, 파일 전송 네트워크 (41) 는 브로드캐스트와 유니캐스트 네트워크들의 조합일 수도 있다. 전송 네트워크가 브로드캐스트 네트워크일 때, 파일 송신들은 브로드캐스트 채널이 송신될 상이한 파일들의 모두에 걸쳐서 효율적으로 공유될 수 있도록, 스케쥴링될 수도 있다. 게다가, 브로드캐스트 채널이 다수의 매체들 스트림들을 동시에 지원할 수 있으면, 데이터 파일들의 송신이 다수의 매체들 스트림들의 하나와 연관될 수도 있다.
파일 전달 프레임워크 (40) 의 부분으로서, 일련의 BSM 들이 브로드캐스트 전송 네트워크에서 이용가능한 오버헤드 메시지 흐름으로 브로드캐스트될 수도 있다. 위에서 설명한 바와 같이, BSM 들은 수신기 디바이스들로 하여금 브로드캐스트될 파일들을 특정의 서비스 또는 애플리케이션과 연관시킬 수 있도록 하는 정보를 제공할 수도 있다. BSM 들은 또한 브로드캐스트될 파일들에 관한 파일 ID/엘리먼트 ID 또는 버전 정보, 파일들이 수신될 수 있는 전송 스트림에 관한 정보, 파일이 브로드캐스트될 시기에 관한 정보 (예컨대, 전달 윈도우), 및 전달 스케쥴 또는 BSM 이 새로운 정보로 업데이트되는 시기에 관한 정보를 포함할 수도 있다.
위에서 설명한 바와 같이, 브로드캐스트 및 수신을 위한 파일들은 파일 시스템의 디렉토리에 속하는 것으로 논리적으로 식별될 수도 있다. 여러 실시형태들에서, 이 파일 시스템 추상화는 파일들이 애플리케이션-특정의 디렉토리 구조에 속하는 것으로 정의될 수 있도록 하며, 여가서 루트 (최상위) 디렉토리는 애플리케이션을 식별한다. 예를 들어, 애플리케이션 testApp 에 속하는 파일 testFile 은 "/testApp/testFile" 로서 정의될 수도 있다. 여러 실시형태들에서, 파일들은 파일들의 의미론적 속성들을 기술하는 메커니즘으로서 서브디렉토리들에 추가로 편성될 수도 있다. 예를 들어, 파일들은 파일의 콘텐츠들과 브로드캐스트 채널 (예컨대, CNN, ABC 등) 사이의 연관에 기초하여, 편성될 수도 있다. 따라서, 주문형 비디오 애플리케이션 (vodApp) 에 대한 파일들은 애플리케이션-특정의 디렉토리, 예컨대, /vodApp/CNN/ 또는 /vodApp/ABC/ 등에 속하는 것으로서 편성될 수도 있다.
파일 시스템 추상화의 추가적인 예로서, 날씨 애플리케이션 (weaApp) 은 날씨 업데이트들에 관한 파일들을 도시 단위 기준으로 편성할 수도 있으며, 여기서 서브폴더들은 특정의 도시들과 연관되는 파일들을 식별한다. 예를 들어, 어구 "/weaApp/LA/" 를 포함하는 파일 이름은 로스 앤젤레스 (Los Angeles) 에 대한 날씨 업데이트들에 관한 파일들을 포함할 수도 있지만, 어구 "/weaApp/NY/" 를 포함하는 전송 파일 이름은 뉴욕 (New York) 에 대한 날씨 업데이트들에 관한 파일들을 포함할 수도 있다. 예를 들어, weaApp 파일들은 특정의 파일들이 도시에 따라 식별되어 그룹화될 수 있도록 "weaApp/LA/f1.jpg" 및 "/weaApp/NY/f4.jpg" 으로 명명될 수도 있다.
이 파일 시스템 추상화는 브로드캐스트 파일 전달 서비스를 통해서 전송되는 파일들의 정의 및 관리를 간소화한다. 파일 시스템 추상화는 또한 애플리케이션 개발자들이 브로드캐스트 전송 시스템의 세부사항들을 상대하는 것을 염려할 필요가 없기 때문에, 애플리케이션 개발 프로세스를 간소화한다.
도 5 는 파일 시스템 추상화의 구현예를 도시한다. 구체적으로 설명하면, 도 5 는 파일 전송 네트워크 (41) 를 통한, 날씨 애플리케이션 (44) 에 의한 사용을 위한 파일들의 전송에 사용될 수도 있는 파일 이름들을 도시한다. 도시된 예에서, 전송자-측 날씨 애플리케이션 (43) 은 적절히 명명된 파일을 가진 전송 지령을 발함으로써 파일들이 전송되도록 요청할 수도 있다. 예를 들어, 날씨 애플리케이션 (43) 은 LA 날씨 파일들이 전송되도록 요청하기 위해서 지령 sendFile(/weaApp/LA/012510Update.jpg) 을 이용할 수도 있다. 파일 수취 시스템 (31) 은 이들 파일들을 수신하고, BSM 메시지들 내에 파일 이름들을 포함시킨다.
수신기 디바이스 측 상에서, 수신기 디바이스의 프로세서 내에서 기능하는 디바이스 애플리케이션들은 헤드엔드 측 상에서 이용되는 동일한 파일 이름 구조를 이용하여 파일들을 요청할 수도 있다. 이것은 도 5 에 도시되어 있으며, 클라이언트 날씨 애플리케이션 (46) 이 파일 전달 서비스 (44) 에 등록하여, 모든 관련된 파일들이 단일 지령으로 캡쳐되도록 요청할 수도 있는 것으로 도시되어 있다. 예를 들어, 수신기 디바이스가 (예컨대, 사용자 선호사항들 또는 GPS와 같은 위치 결정 능력에 기초하여 결정될 수도 있는) 뉴욕시 인근에 로케이트되는 경우, 디바이스 애플리케이션 (46) 은 캡쳐 지령을 발하고 적절히 명명된 디렉토리를 제공함으로써 모든 뉴욕시 관련된 날씨 파일들이 수신되도록 요청할 수도 있다. 도시된 예에서, 클라이언트 날씨 애플리케이션 (46) 은 그 요청된 디렉토리 이름으로서 "/weaApp/NYC/" 을 제공하는, "captureAll" 지령을 발할 수도 있다 ("/" 은 디렉토리 이름들을 파일 이름들과 구별하는 규약 (convetion) 으로 사용될 수도 있다). 따라서, 도시된 예에서, 클라이언트 날씨 애플리케이션 (46) 은 헤드엔드 애플리케이션 (42) 로부터 모든 관련된 뉴욕시 날씨 파일들을 수신하기 위해서, 단지 "captureAll(/weaApp/NYC/)" 지령만을 발하는 것을 필요로 한다. 파일 시스템 추상화를 이용하여 파일들을 요청하고 전송하는 이 방법은 파일 송신 및 애플리케이션 개발 프로세스들을 크게 간소화한다.
도 6 은 파일 시스템 추상화의 또 다른 구현예를 도시한다. 구체적으로 설명하면, 도 6 은 헤드엔드 상호작용성 애플리케이션 (iTVApp) (60) 이 이미지 파일들 및 카탈로그를 오버헤드 파일로서 실행의뢰하는 시나리오를 도시한다. 카탈로그 파일 (/itv/sig/cat.xml) 은 상호작용성 애플리케이션으로부터 입수가능한 파일들에 관한 정보를 제공한다. 헤드엔드 상호작용성 애플리케이션 (60) 이 전송을 위한 새로운 파일들을 실행의뢰할 때, 업데이트된 상호작용성 카탈로그가 또한 그 파일들과 함께 실행의뢰될 수도 있다. 업데이트된 상호작용성 카탈로그는 새로 추가된 상호작용성 파일들을 기술할 수도 있다. 따라서, 도시된 예에서, 상호작용성 애플리케이션 서버 (60) 는 카탈로그 파일 및 3개의 상호작용성 파일들을 파일 수취 시스템 (31) 에, 전송 지령과 함께 제공한다. 도시된 예에서, 전송 지령은 "sendFile(/itv/sig/cat.xml; /itv/res/svc_5/f1.jpg; /itv/res/svc_5/f2.jpg; /itv/res/svc_5/f3.jpg)" 일 수도 있다. 수신기 측상에서, 클라이언트 애플리케이션 (62) 은 카탈로그 파일에 대한 업데이트들의 연속 캡쳐를 위해 요청 지령을 파일 전달 서비스 모듈 (44) 로 발할 수도 있다. 도시된 예에서, 이 요청 지령은 "captureAll (/itv/sig/cat.xml)" 일 수도 있으며; 여기서는, 디렉토리 이름이 아닌 파일 이름 ("/" 로 종결되지 않은 인수) 이, 서비스 요청에 대한 인수 (argument) 로서 사용되었다. 요청 지령을 발한 후, 클라이언트 애플리케이션 (62) 은 카탈로그 정보에 대한 업데이트들에 기초하여, 그 카탈로그 파일에서의 애플리케이션-특정의 정보의 애플리케이션-특정의 프로세싱에 따라서, 특정의 파일들을 캡쳐하기 위해서 요청 지령들을 발할 수도 있다. 예를 들어, 클라이언트 애플리케이션 (62) 은 단일 관심 파일 "f2.jpg" 을 캡쳐하기 위해서 "singleCapture(/itv/res/svc_5/f2.jpg)" 지령을 발할 수도 있으며; singleCapture () 은 이들 파일들에 대한 콘텐츠가 변할 것으로 예상되지 않기 때문에, 그 요청된 파일에 대한 업데이트들을 계속 모니터링하지 않는다.
여러 실시형태들에서, 위에서 설명한 파일 시스템 추상화 시스템을 구현하는 애플리케이션들은 파일 전송 네트워크 (41) 를 통한 수신에 이용가능한 파일들을 발견하고 요청하는 다른 방법들을 구현하는 애플리케이션들과 결합될 수도 있다. 따라서, 여러 실시형태들에서, 상이한 파일 추상화 및/또는 파일 요청/송신 기법들을 구현하는 클라이언트 및 헤드엔드 애플리케이션들 양자를 이용하는 하이브리드 시스템이 채용될 수도 있다. 이 하이브리드 시스템은 단일 프레임워크 상에서 상이한 유형의 파일 전달 애플리케이션들을 동시에 지원하는 파일 전달 프레임워크 (FDF) 의 능력에 기여할 수도 있다.
도 7 은 송신 리소스들을 공유하기 위해서 파일 전달 파이프의 파일들을 시간 멀티플렉싱하는 것에 의한 수취된 파일들의 스케쥴링을 도시한다. 위에서 설명한 바와 같이, 여러 실시형태들에서, 리소스들은 시스템의 전체 효율을 향상시키기 위해서 파일 전달 파이프들에 편성될 수도 있다. 리소스들을 파일 전달 파이프들에 편성하는 것은 파일 전송 서비스들 (예컨대, FDF 서비스) 을 제공하는 대부분의 브로드캐스트 네트워크들이 일반적으로 리소스 바인딩되기 때문에, 효율을 향상시킨다. 여러 실시형태들에서, 파일 전달 파이프들은 송신 프로세스에 전용되는 리소스들의 특정의 그룹일 수도 있다. 여러 실시형태들에서, 파일 전달 파이프들은 전용 브로드캐스트 리소스들일 수도 있다. 여러 실시형태들에서, 전용 리소스들은 특정의 파일 전송 프로세스에 전용되는 네트워크 리소스들을 포함할 수도 있다. 여러 실시형태들에서, 하나 이상의 파일 전달 파이프들이 파일 전달 네트워크에 걸쳐서 하나 이상의 파일들을 전송하는데 사용될 수도 있다.
도 7 은 또한 파일들의 시퀀스를 운반하도록 스케쥴링되는 파일 전달 파이프 (72) 를 도시한다. 각각의 파일은 상이한 전송 파일 ID 및/또는 엘리먼트 ID (예컨대, fID_1 내지 fID_4) 에 의해 식별된다. 전송 파일 ID 들 및/또는 엘리먼트 ID 들은 파일들을 고유하게 식별하며, 암시적인 버전화 지원 (implicit versioning support) 의 형태를 제공할 수도 있다 (즉, 파일의 각각의 실행의뢰된 버전에 새로운 파일 ID/엘리먼트 ID 가 할당될 수도 있다). 도 7 은 각각의 파일이 특정의 브로드캐스트 윈도우 (BW) 내에서 브로드캐스트되도록 스케쥴링될 수도 있음을 도시하며, 여기서, 각각의 브로드캐스트 윈도우 (예컨대, BWfID _2) 는 파일 (예컨대, fID_2) 이 송신될 수 있는 시간 기간에 대응한다. 여러 실시형태들에서, 전용 파이프에 걸쳐서 각각의 파일을 송신하는데 요구되는 브로드캐스트 윈도우는 전송 파이프 데이터 레이트 및 송신될 파일의 사이즈의 함수로서 정의될 수도 있다. 여러 실시형태들에서, 브로드캐스트 윈도우는 파일 사이즈를 파일 파이프 데이터 레이트로 나눈 값에 비례할 수도 있다.
도 7 은 또한 브로드캐스트 스케쥴 흐름 (BSF) (70) 이 전송을 위한 파일들, 그들의 브로드캐스트 윈도우들 뿐만 아니라 송신 메타데이터를 기술하는 브로드캐스트 스케쥴 메시지들 (BSMs) 을 운반하는데 사용될 수도 있다는 것을 도시한다. 여러 실시형태들에서, 브로드캐스트 스케쥴 흐름 (70) 은 콘텐츠 흐름들과는 분리된 오버헤드 흐름일 수도 있다. 여러 실시형태들에서, 브로드캐스트 스케쥴 메시지들은, 수신기 디바이스들이 그들의 원하는 파일들을 수신하도록 시기 적절하게 수신기 회로를 활성화할 수 있게, 그 파일들보다 앞에 송신될 수도 있다. 여러 실시형태들에서, 동일한 브로드캐스트 스케쥴 메시지는 수신기 디바이스들에 의한 브로드캐스트 스케쥴 메시지들의 신뢰성 있는 수신을 보장하기 위해서, 예컨대, 모든 슈퍼프레임에서, 빈번하게 재브로드캐스트될 수도 있다.
위에서 설명한 바와 같이, 여러 실시형태들에서, 각각의 브로드캐스트 스케쥴 메시지 (BSM) 는 스케쥴링된 파일들의 일부를 단지 기술할 수도 있다. 이것은 다수의 파일들이 이용가능하고 공중 (over-the-air) 송신을 위해 스케쥴링되는 상황들을 지원하는 것이며, 단일 브로드캐스트 스케쥴 메시지 내의 모든 스케쥴링된 파일들을 정의하는 것은 실용적이지 않다. 브로드캐스트 스케쥴 메시지들 내의 스케쥴링된 파일들의 단지 일부만을 광고하는 것은 또한 새로운 파일들이 송신을 위해 연속적으로 실행의뢰됨에 따라서 스케쥴이 자주 변할 수도 있는 상황들을 지원한다. 따라서, 여러 실시형태들에서, 브로드캐스트 스케쥴 메시지들은 그들이 스케쥴링된 파일들의 단지 일부만을 기술하도록, 발생될 수도 있다. 이들 실시형태들에서, 브로드캐스트 스케쥴 메시지는 주어진 브로드캐스트 스케쥴 기간 (BSP) 내에서 브로드캐스트될 일련의 파일들을 기술할 수도 있다.
도 7 은 또한 각각의 BSM 이 각각의 브로드캐스트 스케쥴 기간 (BSP) 내에서 일련의 파일들을 기술할 수도 있음을 도시한다. 구체적으로 설명하면, 도 7 은 단지 3개의 고유 파일들 (fID_1 내지 fID_3) 이 제 1 브로드캐스트 스케쥴 기간 (BSP1) 에 브로드캐스트되는 예를 도시한다. 여러 실시형태들에서, 각각의 브로드캐스트 스케쥴 기간은 대응하는 브로드캐스트 스케쥴 메시지에 포함되는 광고된 파일 브로드캐스트 스케쥴들의 수를 나타내는 양을 정의할 수도 있다. 이들 브로드캐스트 스케쥴 메시지들은 동일한 브로드캐스트 스케쥴 흐름 (70) 내에서 반복적으로 송신될 수도 있다. 예를 들어, 도 7 은 그 BSP1 기간 내에 브로드캐스트를 위해서 스케쥴링되는 파일들의 모두를 기술하는 동일한 BSM1 메시지가 BSM (70a) 내지 BSM (70d) 에 의해 나타낸 바와 같이, 브로드캐스트 스케쥴 흐름 (70) 에서 여러 번 브로드캐스트되는 것을 도시한다.
여러 실시형태들에서, 파일 전달 시스템은 브로드캐스트 스케쥴 기간들 (BSPs) 이 상대적으로 짧고 브로드캐스트 스케쥴 메시지들 (BSMs) 이 브로드캐스트 스케쥴 흐름 (BSF) (70) 내에서 규칙적으로 업데이트되도록, 구성될 수 있다. 짧은 브로드캐스트 스케쥴 기간들을 이용하도록 시스템을 구성하고 브로드캐스트 스케쥴 메시지들을 규칙적으로 업데이트함으로써, 파일 전달 시스템의 효율 및 유연성 뿐만 아니라, 업데이트된 파일들을 연속적으로 관리하는 그의 능력이 크게 향상될 수 있다.
도 7 은 브로드캐스트 스케쥴 흐름 (BSF) (70) 내에 포함되는 브로드캐스트 스케쥴 메시지들 (BSMs) 이 규칙적으로 업데이트되는 예를 도시한다. 구체적으로 설명하면, 도 7 은 BSM1 (70d) 이 BSP2 내에 브로드캐스트될 파일들에 대응하는 BSM2 (70e) 로 업데이트될 수도 있다는 것을 도시한다. 도 7 은 또한 브로드캐스트 스케쥴 메시지들 (예컨대, BSM1 및 BSM2) 이 2개의 BSP 들 (예컨대, BSP1 및 BSP2) 의 경계 상에서 업데이트될 수도 있다는 것을 도시한다.
도 7 이 다수의 브로드캐스트 윈도우들이 fID_1 로 나타낸 바와 같은 단일 파일에 대한 브로드캐스트 스케쥴 기간 (BSP) 동안 존재하는 시나리오를 도시한다는 점에 유의해야 한다. 단일 파일에 대한 다수의 브로드캐스트 윈도우들은, 높은 우선순위 파일들에 적합할 수도 있는 정도로, 파일 송신에 대한 성공률을 향상시키기 위해서 파일이 반복적으로 송신될 때에, 사용될 수도 있다. 단일 파일들에 대한 다수의 브로드캐스트 윈도우들은 또한 분리된 파일들이 동시에 송신가능하도록 파일이 따로 떨어진 조각들로 분할되어야 할 만큼 큰 경우에 필요할 수도 있다. 단일 파일에 대한 다수의 브로드캐스트 윈도우들이 있을 경우, 그들 다수의 브로드캐스트 윈도우들은 동일한 브로드캐스트 스케쥴 기간 내에 또는 상이한 브로드캐스트 스케쥴 기간들에서 나타날 수도 있다.
도 8 은 각각의 브로드캐스트 스케쥴 메시지 (예컨대, BSM1 및 BSM2) 가 브로드캐스트 스케쥴 기간 내에 브로드캐스트되는 복수의 파일들에 대한 브로드캐스트 윈도우 및 수신 정보를 제공하기 위해서, 예컨대, 슈퍼프레임 마다, 규칙적으로 반복될 수도 있다는 것을 도시한다. 도 8 은 또한 파일들이 상이한 사이즈들을 갖기 때문에, 파일 전달 파이프 데이터흐름에서 송신되는 파일들이 상이한 브로드캐스트 지속기간들을 가질 수도 있다는 것을 도시한다.
위에서 설명한 바와 같이, BSM 들은 송신 스케쥴을 광고하는 메커니즘을 제공한다. BSM 들은 또한 일련의 추가 정보를 수신기 디바이스들에 제공할 수도 있다. 예시적인 BSM 의 하이-레벨 포맷이 도 9 에 도시되어 있다. 도 9 가 도시하는 바와 같이, 브로드캐스트 스케쥴 메시지는 브로드캐스트 스케쥴 모니터링 레코드 (BSMR) 를 포함할 수도 있다. 브로드캐스트 스케쥴 모니터링 레코드는 수신기 디바이스가 그 브로드캐스트 스케쥴 흐름을 업데이트된 BSM 에 대해 모니터링해야 하는 다음 시간을 특정하는 다음 모니터 시간 데이터 필드 (Next_Monitor_Time) 를 포함할 수도 있다. 이 데이터 필드는 또한 다음 브로드캐스트 스케쥴 기간이 시작할 수도 있는 시간을 정의할 수도 있다. 아래에서 좀더 충분히 설명하는 바와 같이, BSM 이 업데이트될 시간을 특정하는 것은, 수신기 디바이스들로 하여금, 여분의 BSM 들이 브로드캐스트 스케쥴 흐름 (BSF) (70) 상에서 운반되어질 때에 그들의 수신기 회로를 비활성화함으로써, 배터리 전력을 절약할 수 있도록 한다.
도 9 는 BSM 들이 또한 흐름 브로드캐스트 스케쥴 레코드 (FBSR) 를 포함할 수도 있다는 것을 도시한다. 흐름 브로드캐스트 스케쥴 레코드는 현재 브로드캐스트 스케쥴 기간 (BSP) 동안 콘텐츠 흐름 상에서 (예컨대, 파일 브로드캐스트 파이프 내에서) 브로드캐스트되고 있는 파일들에 대한 브로드캐스트 스케쥴들을 기술할 수도 있다. BSM 은 다수의 흐름 브로드캐스트 스케쥴 레코드들을 포함할 수도 있다. 각각의 흐름 브로드캐스트 스케쥴 레코드는 2개의 주요 부분들: 흐름 브로드캐스트 스케쥴 레코드 헤더 (FBSR 헤더); 및 흐름 브로드캐스트 스케쥴 레코드 바디 (FBSR 바디) 를 포함하는 값 부분 (즉, 레코드 데이터) 을 갖는 유형-값-길이 (TLV) 구조의 형태일 수도 있다.
흐름 브로드캐스트 스케쥴 레코드 헤더 (FBSR 헤더) 는 전송 스트림, 주파수, 및/또는 브로드캐스트 시스템에 관한 정보를 운반할 수도 있다. 흐름 브로드캐스트 스케쥴 레코드 헤더는 흐름 ID 및 흐름 데이터 레이트를 포함할 수도 있다. 흐름 ID 는 파일의 송신에 이용되는 브로드캐스트 흐름에 대한 식별자일 수도 있다. 흐름 데이터 레이트는 흐름 ID 하의 브로드캐스트 스케쥴 메시지에 기술되는 파일들이 송신되는 데이터 레이트일 수도 있다.
흐름 브로드캐스트 스케쥴 레코드 바디 (FBSR 바디) 는 BSR1 및 BSR2 로 나타낸 바와 같이, 하나 이상의 브로드캐스트 스케쥴 레코드들 (broadcast schedule records) 을 운반할 수도 있다. 각각의 브로드캐스트 스케쥴 레코드 (BSR) 는 주어진 브로드캐스트 스케쥴 기간 (BSP) (70) 내에서 콘텐츠 흐름 상에서 브로드캐스트되어질 단일 파일에 관한 브로드캐스트 정보를 제공할 수도 있다. 브로드캐스트 스케쥴 레코드 바디 (BSR 바디) 는 브로드캐스트 디지털 레코드 유형 (BSR_Type), 파일 ID 및/또는 엘리먼트 ID (예컨대, File_ID), 스케쥴 정보, 및 유형-값-길이 (TLV) 인코딩으로 인코딩된 파라미터들의 시퀀스를 포함할 수도 있다. 브로드캐스트 디지털 레코드 유형 (예컨대, BSR_Type) 은 단일 파일, 파일들의 번들 등과 같은, 브로드캐스트될 파일의 유형에 관한 정보를 제공할 수도 있다. 파일 ID 및/또는 엘리먼트 ID (예컨대, File_ID) 는 브로드캐스트될 파일 콘텐츠를 식별할 수도 있다. 스케쥴 정보는 주어진 파일에 대한 브로드캐스트 윈도우를 기술하며, 브로드캐스트 스케쥴 기간에 걸친 많은 브로드캐스트 송신들을 기술할 수도 있다. 브로드캐스트 윈도우는 브로드캐스트 윈도우 시작 시간 (BW_Start_Time) 및 브로드캐스트 지속기간 (BW_Duration) 에 의해 정의될 수도 있다. 브로드캐스트 윈도우 시작 시간은 파일의 브로드캐스트가 시작하는 시간으로서 정의될 수도 있다. 브로드캐스트 지속기간은 파일이 브로드캐스트될 브로드캐스트 윈도우 시작 시간을 초과하는 시간의 길이로서 정의될 수도 있다.
흐름 브로드캐스트 스케쥴 레코드 바디는 특정의 파일 ID 및/또는 엘리먼트 ID 의 파일을 수신기 디바이스들에 의한 필터링 및 선택을 용이하게 할 수도 있는 방법으로 추가로 식별할 수도 있는 추가 정보를 운반하기 위해서 BSM 의 확장성을 제공하는 유형-값-길이 (TLV) 인코딩에서의 파라미터들의 시퀀스를 추가로 포함할 수도 있다. 흐름 브로드캐스트 스케쥴 레코드 바디에 포함될 수도 있는 파라미터들의 3개의 유형들이 아래에 설명된다.
제 1 유형 (예컨대, 유형 = 1) 에서, 파일 ID 및/또는 엘리먼트 ID 에 의해 식별되는 파일 콘텐츠가 연관될 수도 있는 가능한 다수의 파일들 또는 디렉토리 이름들을 식별하는, 프리픽스 매칭 스트링들이 포함될 수도 있다. 예를 들어, 브로드캐스트 스케쥴 레코드는 단지 하나의 프리픽스 매칭 스트링을 포함할 수도 있으며, 여기서, 그 데이터는 "/itv/res/svc_5/f2.jpg" 과 같은 파일 이름이다. 또 다른 예로서, 브로드캐스트 스케쥴 레코드는 다수의 프리픽스 매칭 스트링들을 포함할 수도 있으며, 여기서, 각각의 TLV 는 하나의 TLV 에서는 "/itv/res/svc_5/f2.jpg" 및 또 다른 TLV 에서는 "/itv/res/svc_15/f2.jpg" 와 같은, 상이한 파일 이름을 갖는다. 이 상황은 "f2.jpg" 가 "/itv/" 파일 디렉토리 구조에서 2개의 별칭들을 가지므로, 서비스 5 (예컨대, ESPN) 및 서비스 15 (예컨대, ESPN2) 상에서의 상호작용성을 위해 동일한 파일 "f2.jpg" 을 이용하는 상호작용성 (itv) 애플리케이션과 마찬가지일 수도 있다. 제 3 예에서, 수신기 디바이스는 singleCapture(/itv/res/svc_15/f2.jpg) 또는 captureAll(/itv/res/svc_5/) 형태로 파일들을 캡쳐하라는 요청들을 수신할 수도 있으며, 이 경우, 수신 디바이스는 프리픽스 매칭 스트링 LTV 들에서의 값들로 양방향 프리픽스 매칭을 수행할 수도 있다.
제 2 유형 (예컨대, 유형 = 2) 에서, 속성 스트링들은 파일 ID 및/또는 엘리먼트 ID 에 의해 식별되는 파일 콘텐츠, 또는 그 파일 콘텐츠가 적합한 애플리케이션들 또는 수신기 디바이스들을 특징화하는 다수의 속성들 (예컨대, 성별 = 남성; 나이 = 20 ~ 30 등) 을 제공할 수도 있다. 이 경우, 속성 스트링들을 이용하는 수신기 디바이스는 captureAll(성별 = 남성 && 나이 = 20 ~ 30) 와 같은, 다수의 속성들에 관한 논리적 표현에 일치하는 파일들을 캡쳐하라는 요청들을 수신할 것이며, 여기서, && 는 논리적 AND 연산을 나타낸다.
제 3 유형 (예컨대, 유형 = 3) 에서, 애플리케이션 또는 서비스 특정의 식별자들이 주어진 애플리케이션 또는 서비스의 범위에서 파일 ID 및/또는 엘리먼트 ID 를 식별하는 파일 (예컨대, itv:123, 또는 svc_3:2234 등) 에 제공된다. 애플리케이션 또는 서비스 식별자들을 이용하는 수신기 디바이스는 이용가능한 파일들, 연관되는 속성들, 및 그 파일에 대한 대응하는 애플리케이션 또는 서비스 식별자를 기술하기 위해서 카탈로그 파일을 이용할 것이다. 그 후, 애플리케이션 또는 서비스는 관심 파일의 캡쳐를 singleCapture(itv: 123) 과 같은 단일 캡쳐로서 요청할 수 있을 것이다.
도 10 은 또 다른 예시적인 브로드캐스트 스케쥴 메시지에 대한 하이-레벨 포맷을 도시한다. 도 10 에 도시된 바와 같이, BSM 은 다수의 브로드캐스트 스케쥴 정보 레코드들 (BSIR1 내지 BSIRM) 을 포함할 수도 있다. 각각의 브로드캐스트 스케쥴 정보 레코드는 하나 이상의 흐름들 상에서의 브로드캐스트 스케쥴에 관한 정보를 포함할 수도 있다. 각각의 브로드캐스트 스케쥴 정보 레코드는 수신기 디바이스들이 업데이트된 브로드캐스트 스케쥴들을 수신하는데 이용할 수 있는 모니터링 스케쥴을 포함할 수도 있다.
도 10 에 도시된 바와 같이, 각각의 브로드캐스트 스케쥴 정보 레코드 (예컨대, BSIR1 내지 BSIRM) 는 헤더 부분 (BSIR 헤더) 및 바디 부분 (BSIR 바디) 를 가질 수도 있다. 헤더 부분은 다음 모니터 시간 (예컨대, Next_Monitor_Time) 필드 및 모니터링 기간 (예컨대, Monitoring_Period) 필드를 포함할 수도 있다. 여러 실시형태들에서, 헤더 부분의 필드들 (예컨대, Next_Monitor_Time, Monitoring_Period 등) 은 파일 전달 프레임워크 (FDF) 로 하여금 데이터를 상이한 레이턴시들에서 전달할 수 있도록 하기 위해 사용될 수도 있다. 여러 실시형태들에서, 모니터링 기간 내에서 브로드캐스트 스케쥴 정보 레코드들 (BSIRs) 의 모두는, 수신기 디바이스들이 오직 제 1 브로드캐스트 스케쥴 정보 레코드만을 프로세싱하도록, 내림차순으로 정렬될 수도 있다. 여러 실시형태들에서, 브로드캐스트 스케쥴 정보 레코드는, 시스템이 초기 획득 흐름 (IAF) 시스템들을 지원하지 않는다고 결정될 때에만, 다음 모니터 시간 (예컨대, Next_Monitor_Time) 필드를 포함하도록 구성될 수도 있다.
여러 실시형태들에서, 브로드캐스트 스케쥴 정보 레코드 (BSIR 바디) 의 바디 부분은 다수의 흐름 브로드캐스트 스케쥴 레코드들 (FBSR1 내지 FBSRN) 을 포함할 수도 있다. 흐름 브로드캐스트 스케쥴 레코드는 브로드캐스트 스케쥴 기간 (BSP) 내에서 그 흐름 상에서 브로드캐스트되는 엘리먼트들의 브로드캐스트 스케쥴들을 기술하는 파일 전달 데이터 흐름 레코드이다. 각각의 흐름 브로드캐스트 스케쥴 레코드는 값 부분이 헤더 부분 (FBSR 헤더) 및 바디 부분 (FBSR 바디) 을 포함하는 유형-값-길이 (TLV) 구조를 가질 수도 있다. 흐름 브로드캐스트 스케쥴 레코드의 헤더 부분은 흐름 ID, 데이터 레이트 등과 같은, 데이터 흐름에 관한 정보를 포함할 수도 있다. 흐름 브로드캐스트 스케쥴 레코드의 바디 부분은 하나 이상의 브로드캐스트 스케쥴 레코드들 (BSR1 내지 BSRN) 을 포함할 수도 있다. 여러 실시형태들에서, 흐름 브로드캐스트 스케쥴 레코드의 바디 부분은 브로드캐스트 스케쥴 기간 (BSP) 내에서 그 흐름 상에서 브로드캐스트되는 각각의 엘리먼트에 대한 브로드캐스트 스케쥴 레코드를 포함할 수도 있다. 여러 실시형태들에서, 각각의 브로드캐스트 스케쥴 레코드는 각각의 엘리먼트 (즉, 그 데이터 흐름 상에서 브로드캐스트되는 데이터 유닛) 에 대한 엘리먼트 ID (Element_ID), 그 엘리먼트에서의 파일(들) 에 대한 하나 이상의 파일/디렉토리 이름들, 및 브로드캐스트 스케쥴 정보를 가질 수도 있다. 일 실시형태에서, 파일 및 디렉토리 이름들은 UNIX-기반의 파일 명명 규약 (naming convention) 을 따를 수도 있다. 일 실시형태에서, 엘리먼트 ID (예컨대, Element_ID) 들로 표현되는 엘리먼트들은 파일의 특정의 버전 또는 다수의 파일들로 이루어지는 파일 번들의 특정의 버전에 대응할 수도 있다. 여러 실시형태들에서, 동일한 파일 또는 파일 번들의 상이한 버전들은 상이한 엘리먼트들에 대응할 수도 있다. 여러 실시형태들에서, 엘리먼트 ID 들은 파일 전달 프레임워크 (FDF) 에 의해 각각의 엘리먼트에 할당되는 글로벌 고유 ID 일 수도 있다.
도 11 은 BSM 의 다음 모니터 시간 데이터 필드를 이용하는 일 실시형태 방법을 도시한다. 위에서 설명한 바와 같이, BSM 은 수신기 디바이스가 브로드캐스트 스케쥴 흐름을 업데이트된 BSM 에 대해 모니터링해야 하는 다음 시간을 특정하는 다음 모니터 시간 데이터 필드 (예컨대, 도 10 에서 Next_Monitoring_Time 필드) 를 포함할 수도 있다. 도 11 은 제 1 BSM (BSM1) 의 다음 모니터 시간 데이터 필드가 어떻게 제 2 BSM (BSM2) 을 다음 브로드캐스트 스케쥴 기간 (다음 BSP) 동안 브로드캐스트 스케쥴 흐름 (BSF) (70) 에서 업데이트하는데 사용될 수 있는지를 도시한다. 도 11 은 수신기 디바이스가 BSM (예컨대, BSM1) 을 수신할 때, 수신기는 브로드캐스트 스케쥴 흐름 (BSF) 을 BSM1 에서의 다음 모니터링 시간에 따라서 모니터링하도록 다음 웨이크-업 시간을 스케쥴링할 수도 있다는 것을 도시한다.
도 12 는 브로드캐스트 스케쥴 메시지들을 프로세싱하는 일 실시형태 방법 (1200) 이다. 도 12 는 결정 단계 (1201) 에서, 수신된 BSM 이 이전에 프로세싱된 브로드캐스트 스케쥴 메시지의 버전 속성과 동일한 버전 속성을 갖는지 여부를 수신기 디바이스가 먼저 결정할 수도 있다는 것을 도시한다. 버전이 동일하면 (즉, 결정 단계 1201 = "예"), 수신기 디바이스는 결정 단계 (1216) 로 진행할 수도 있다. 버전이 동일하지 않으면 (즉, 결정 단계 1201 = "아니오"), 단계 (1202) 에서, 수신기 디바이스는 이전 BSM 을 삭제하고 새로 수신된 BSM 을 저장할 수도 있다. 파일 전달 프레임워크 (FDF) 가 파일들을 캡쳐하라는 애플리케이션으로부터의 요청을 수신할 때마다 그 요청에서의 새로운 정보를 이용하여 그 저장된 BSM 을 다시 프로세싱해야 하기 때문에, 새로운 BSM 을 저장하는 것이 필요하다.
결정 단계 (1204) 에서, 수신기 디바이스는 브로드캐스트 스케쥴 메시지로부터 브로드캐스트 스케쥴 메시지 레코드를 판독하려고 시도할 수도 있다. 성공적이면 (즉, 결정 단계 1204 = "예"), 결정 단계 (1206) 에서, 수신기 디바이스는 그 BSM 에서의 레코드들 (예컨대, BSMR, FBSR) 을 프로세싱하여, 그 레코드가 브로드캐스트 스케쥴 모니터링 레코드 (BSMR) 인지 여부를 결정할 수도 있다. 그 레코드가 브로드캐스트 스케쥴 모니터링 레코드이면 (즉, 결정 단계 1206 = "예"), 단계 (1208) 에서, 디바이스는 브로드캐스트 스케쥴 모니터링 레코드에서의 다음 모니터링 시간 필드 (예컨대, NEXT_MONITORING_TIME) 를 새로운 다음 모니터링 시간으로서 이용할 수도 있다. 그 레코드가 브로드캐스트 스케쥴 모니터링 레코드이 아니면 (즉, 결정 단계 1206 = "아니오"), 결정 단계 (1212) 에서, 수신기 디바이스는 그 레코드가 흐름 브로드캐스트 스케쥴 레코드 (FBSR) 인지 여부를 결정할 수도 있다. 그 레코드가 흐름 브로드캐스트 스케쥴 레코드가 아니면 (즉, 결정 단계 1212 = "아니오"), 수신기 디바이스는 결정 단계 (1204) 로 되돌아가서, 새로운 브로드캐스트 스케쥴 메시지 레코드를 판독한다. 그 레코드가 흐름 브로드캐스트 스케쥴 레코드이면 (즉, 결정 단계 1212 = "예"), 단계 (1214) 에서, 디바이스는 흐름 브로드캐스트 스케쥴 레코드를 프로세싱하여, 데이터 필터링 결정을 행한 후, 결정 단계 (1204) 로 되돌아가서, 새로운 브로드캐스트 스케쥴 메시지 레코드를 판독할 수도 있다.
결정 단계 (1204) 에서, 수신기 디바이스가 BSM 으로부터 브로드캐스트 스케쥴 메시지 레코드를 판독하는 것을 실패하면 (즉, 결정 단계 1204 = "아니오"), 단계 (1210) 에서, 수신기 디바이스는 새로운 BSM 에 특정되지 않은 이전에 스케쥴링된 다운로드들을 취소하고, 결정 단계 (1216) 로 진행한다. 여러 실시형태들에서, 파일 전달 코어 (FDC) 는 새로운 BSM 에 특정되어 있지 않은 이전에 스케쥴링된 다운로드들을 취소할 수도 있다. 여러 실시형태들에서, 브로드캐스트 서버는 업데이트된 BSM 을 전송함으로써, 이 특징을 이용하여, 브로드캐스트된 엘리먼트를 취소할 수도 있다. 파일 전달 코어는 도 19 를 참조하여 아래에서 좀더 자세히 설명된다.
도 12 로 되돌아가서, 브로드캐스트 스케쥴 메시지에서 모든 필드들을 프로세싱한 후 또는 이전에 프로세싱된 BSM 을 수신하자 마자 (즉, 결정 단계 1201 = "예"), 결정 단계 (1216) 에서, 수신기 디바이스는 다음 모니터링 시간 (예컨대, NEXT_MONITORING_TIME) 이 현재 시간보다 늦은지 여부 - 그리고 현재 시간과 다음 모니터링 시간 사이의 차이가 단지 디바이스 프로비져닝 파라미터 (예컨대, MAX_BSF_MONITORING_PERIOD) 에 의해 특정되는 시간 기간에 지나지 않는지 여부를 체크할 수도 있다. 다음 모니터링 시간이 현재 시간보다 늦지 않으면 (즉, 결정 단계 1216 = "아니오"), 그 프로세스가 종료되고, 디바이스는 브로드캐스트 스케쥴 흐름을 모니터링하는 것을 중지하고, 다음 업데이트된 BSM 을 수신하기를 대기할 수도 있다. 다음 모니터링 시간이 현재 시간보다 늦고 현재 시간과 다음 모니터링 시간 사이의 차이가 그 특정된 시간 기간에 지나지 않으면 (즉, 결정 단계 1216 = "예"), 단계 (1218) 에서, 수신기 디바이스는 브로드캐스트 스케쥴 흐름을 등록 해제하고 (즉, 현재 브로드캐스트 스케쥴 흐름을 수신하는 것을 중지하고) 브로드캐스트 스케쥴 흐름을 다음 모니터링 시간에서 수신하도록 스케쥴링할 수도 있다. 그렇지 않으면, 디바이스는 브로드캐스트 스케쥴 흐름을 계속 수신할 수도 있다.
도 13 은 브로드캐스트 스케쥴 흐름 (BSF) (70) 상에서 업데이트 검출을 구현하는 일 실시형태 방법 (1300) 을 도시한다. 도 13 은 결정 단계 (1301) 에서, 수신된 브로드캐스트 스케쥴 메시지 (BSM) 에서의 제 1 브로드캐스트 스케쥴 정보 레코드 (BSIR) 의 버전이 이전에 프로세싱된 브로드캐스트 스케쥴 정보 레코드의 버전과 동일한지 여부를 디바이스가 먼저 체크할 수도 있다는 것을 도시한다. 그 버전이 동일하면 (즉, 결정 단계 1301 = "예"), 결정 단계 (1310) 로 진행할 수도 있다. 그 버전이 동일하지 않으면 (즉, 결정 단계 1301 = "아니오"), 단계 (1302) 에서, 수신기는 이전에 저장된 브로드캐스트 스케쥴 정보 레코드를 삭제하고 새로운 브로드캐스트 스케쥴 정보 레코드를 저장할 수도 있다. 새로운 브로드캐스트 스케쥴 정보 레코드를 저장하는 것은, 파일 전달 프레임워크 (FDF) 로 하여금, 파일 전달 프레임워크가 애플리케이션으로부터 새로운 파일 캡쳐 요청을 수신할 때마다, 그 요청에서의 새로운 정보를 이용하여, 저장된 브로드캐스트 스케쥴 정보 레코드를 재프로세싱할 수 있도록 한다. 단계 (1304) 에서, 디바이스는 브로드캐스트 스케쥴 정보 레코드에서의 다음 모니터링 시간 필드 (예컨대, NEXT_MONITORING_TIME) 를 새로운 다음 모니터링 시간으로 이용할 수도 있다. 단계 (1306) 에서, 수신기 디바이스는 브로드캐스트 스케쥴 정보 레코드에서의 흐름 브로드캐스트 스케쥴 레코드들 (FBSRs) 의 모두를 프로세싱할 수도 있다. 여러 실시형태들에서, 디바이스는 데이터 필터링 결정들을 하기 위해서, 흐름 브로드캐스트 스케쥴 레코드들의 프로세싱을 이용할 수도 있다. 단계 (1308) 에서, 파일 전달 코어 (FDC) 는 새로운 브로드캐스트 스케쥴 정보 레코드에 특정되어 있지 않은 이전에 스케쥴링된 다운로드들을 취소할 수도 있다. 여러 실시형태들에서, 브로드캐스트 서버는 업데이트된 브로드캐스트 스케쥴 메시지를 전송함으로써, 이 특징을 이용하여, 엘리먼트 브로드캐스트를 취소할 수도 있다.
브로드캐스트 스케쥴 정보 레코드 (BSIR) 에서의 모든 필드들을 프로세싱한 후, 결정 단계 (1310) 에서, 수신기 디바이스는 다음 모니터링 시간이 현재 시간보다 늦은지 여부 - 및 현재 시간과 다음 모니터링 시간 사이의 차이가 디바이스 프로비져닝 파라미터 (예컨대, MAX_BSF_MONITORING_PERIOD) 에 지나지 않는지 여부를 체크할 수도 있다. 여러 실시형태들에서, 다음 모니터링 시간이 현재 시간보다 늦지 않으면 (즉, 결정 단계 1310 = "아니오"), 디바이스는 브로드캐스트 스케쥴 흐름 (70) 을 모니터링하는 것을 중지할 수도 있다. 다음 모니터링 시간이 현재 시간보다 늦고, 현재 시간과 다음 모니터링 시간 사이의 차이가 디바이스 프로비져닝 파라미터 (MAX_BSF_MONITORING_PERIOD) 에 지나지 않으면 (즉, 결정 단계 1310 = "예"), 단계 (1312) 에서, 수신기 디바이스는 브로드캐스트 스케쥴 흐름을 등록 해제하고 (즉, BSF 를 수신하는 것을 중지하고), 브로드캐스트 스케쥴 흐름 (70) 을 다음 모니터링 시간에서 수신하도록 스케쥴링할 수도 있다. 그렇지 않으면, 디바이스는 브로드캐스트 스케쥴 흐름 (70) 을 계속 수신할 수도 있다.
도 12 및 도 13 을 참조하여 위에서 설명한 실시형태 방법들에서, 수신기 디바이스가 그 특정된 모니터링 시간에 흐름 커버리지로부터 벗어나면, 디바이스는 브로드캐스트 스케쥴 흐름 (70) 을 수신하기 위해서 다시 웨이크 업할 시기를 인식할 수 없을지도 모른다. 이 시나리오가 도 14 에 도시되며, 이 도면은 수신기 디바이스가 여러 시간들에서 커버리지 영역의 외부에 있을 수도 있음을 나타내고 있다.
도 14 는 수신기 디바이스가 어떻게 브로드캐스트 스케쥴 흐름 송신들의 타이밍에 관련되는 여러 시간들에서 브로드캐스트 네트워크의 및/또는 브로드캐스트 흐름의 커버리지 영역 (1401, 1402) 의 외부에 있을 수 있는지를 도시하는 타임라인도이다. 이런 경우, 수신기 디바이스는 블록 (1401) 으로 표현된 바와 같이, 다음 특정된 모니터링 시간 이전에 커버리지 영역에 재진입할 수도 있다. 다른 시간들에서, 수신기 디바이스는 블록 (1402) 으로 나타낸 바와 같이, 다음 특정된 모니터링 시간이 경과할 때까지 커버리지 영역에 재진입하지 않을 수도 있다. 도 14 는 여러 실시형태들에서, 수신기 디바이스가 흐름 커버리지 영역을 벗어난 후에 흐름 커버리지에 재진입할 때마다 브로드캐스트 스케쥴 흐름 (70) 을 수신할 수도 있다는 것을 도시한다. 일부 실시형태들에서, 수신기 디바이스는 특정된 모니터링 시간에서 흐름 커버리지로부터 벗어났다고 결정하는 것에 기초하여, 브로드캐스트 스케쥴 흐름 (70) 을 수신해야 하는지 여부에 관한 개개의 결정을 행할 수도 있다. 여러 실시형태들에서, 수신기 디바이스는 흐름 커버리지 영역으로 되돌아갈 때 브로드캐스트 스케쥴 흐름 (70) 을 수신하도록 강제될 수도 있다 ("BSF 를 수신하도록 강제됨" 으로서 도시됨). 다른 실시형태들에서, 수신기 디바이스는 서비스 코어가 시작할 때마다 브로드캐스트 스케쥴 흐름 (70) 을 수신하도록 구성될 수도 있다. 다른 실시형태들에서, 수신기 디바이스는 다음 특정된 모니터링 시간이 경과하였는지 여부에 관한 결정을 행하고, 브로드캐스트 스케쥴 흐름의 최신 버전을 수신하였다고 보증하는데 필요한 정도로 조정들을 행할 수도 있다.
도 15 는 초기 획득 흐름 (IAF) 을 지원하는 시스템들 상에서 브로드캐스트 스케쥴 흐름 (BSF) (70) 에 대한 업데이트들을 검출하는 일 실시형태 방법을 도시한다. 구체적으로 설명하면, 도 15 는 초기 획득 흐름에 기초하여 브로드캐스트 스케쥴 흐름 (70) 업데이트들을 검출하는 타임라인을 도시한다. 여러 실시형태들에서, 브로드캐스트 스케쥴 흐름 (70) 상에서의 브로드캐스트 스케쥴 메시지들 (BSMs) 에 대한 업데이트들의 검출은 초기 획득 흐름 상에서의 디렉토리 정보 메시지 (DIM) 메시지의 콘텐츠들에 기초할 수도 있다. 여러 실시형태들에서, 수신기 디바이스는 이전 디렉토리 정보 메시지에 특정되는 다음 모니터 시간 값 (예컨대, NEXT_MONITORING_TIME) 에 따라서 주기적으로 웨이크업할 수도 있다. 여러 실시형태들에서, 수신기 디바이스는 초기 획득 흐름으로부터 최신 디렉토리 정보 메시지를 수신하고, 브로드캐스트 스케쥴 메시지 버전 정보 (예컨대, BSM_VERSION) 를 최신의, 만료되지 않은, 프로세싱된 브로드캐스트 스케쥴 메시지의 버전 정보와 비교할 수도 있다. 이들 실시형태들에서, 그 비교된 버전들이 상이하면, 수신기 디바이스는 브로드캐스트 스케쥴 메시지에 대한 업데이트가 있었는지를 결정하고, 수신기 디바이스 내 수신기 회로를 활성화하여, 브로드캐스트 스케쥴 흐름 (70) 상에서 업데이트된 브로드캐스트 스케쥴 메시지를 수신할 수도 있다. 여러 실시형태들에서, 수신기 디바이스는 업데이트된 브로드캐스트 스케쥴 메시지를, 메커니즘들을 수신하는 공통 오버헤드 흐름을 이용하여 수신할 수도 있다. 여러 실시형태들에서, 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 는 브로드캐스트 스케쥴 메시지가 프로세싱된 후에 곧, 브로드캐스트 스케쥴 메시지가 만료하였다는 것을 나타내기 위해서, 브로드캐스트 스케쥴 메시지 디바이스 파라미터 (예컨대, FDF_BSM_EXPIRY_TIME) 를 설정할 수도 있다. 이들 실시형태들에서, 브로드캐스트 스케쥴 메시지가 만료하였다는 것을 나타냄으로써, 수신기 디바이스는 디바이스가 한동안 흐름 커버리지를 벗어났었고 그리고 효력없는 브로드캐스트 스케쥴 메시지를 갖고 있는 경우를 해결할 수 있다. 여러 실시형태들에서, 수신기 디바이스는 수신기 디바이스가 효력없는 브로드캐스트 스케쥴 메시지를 갖고 있다고 검출할 때마다, 새로운 브로드캐스트 스케쥴 메시지를 수신하기 위해서 수신기 회로를 활성화할 수도 있다.
도 16 은 동일한 슈퍼프레임 내에서, 브로드캐스트 스케쥴 메시지의 2개의 상이한 버전들 (예컨대, BSM1, BSM2) 을 수신하는 일 실시형태 방법을 도시하는 타임라인도이다. 위에서 설명한 바와 같이, 여러 실시형태들에서, 정보가 복수의 슈퍼프레임들로 편성되는 무선 신호들로 송신될 수도 있다. 각각의 슈퍼프레임은 주파수 대역 내, 및 브로드캐스트 콘텐츠를 통신하는 복수의 데이터 패킷들을 포함하는 설정 시간 경계들 내, 신호들을 포함할 수도 있다. 도 16 은 브로드캐스트 스케쥴 메시지의 2개의 상이한 버전들 (BSM1, BSM2) 이 단일 슈퍼프레임의 설정 시간 경계들 내에서 수신될 수도 있다는 것을 도시한다.
도 17 은 초기 획득 흐름 (IAF) 시스템으로부터의 지원에 의해 브로드캐스트 스케쥴 메시지들 (BSMs) 을 프로세싱하는 일 실시형태 방법 (1700) 을 도시한다. 결정 단계 (1701) 에서, 수신기 디바이스는 브로드캐스트 스케쥴 메시지에서의 버전 파라미터 (예컨대, BSM_VERSION) 이 디렉토리 정보 메시지 (DIM) 에 나타낸 버전 파라미터와 동일한지 여부를 결정할 수도 있다. 그 버전들이 상이하면 (즉, 결정 단계 1701 = "아니오"), 디바이스는 수신된 브로드캐스트 스케쥴 메시지를 무시하고 그 프로세싱을 종료할 수도 있다. 여러 실시형태들에서, 이것은 디바이스가 도 16 에 도시된 바와 같이, 슈퍼프레임 내에서 동일한 브로드캐스트 스케쥴 메시지들의 다수의 버전들을 수신하기 때문에, 필수적일 수도 있다. 이런 시나리오들에서, 디바이스는 오직 디렉토리 정보 메시지에 의해 표시되는 최신 버전 (예컨대, BSM2) 만을 프로세싱할 수도 있다. 여러 실시형태들에서, 서버는 업데이트된 브로드캐스트 스케쥴 메시지를 초기 획득 흐름의 다음 모니터링 시간 이전에 수 초 (또는 마이크로초) 브로드캐스트함으로써, 동일한 슈퍼프레임 내에서 브로드캐스트 스케쥴 메시지들의 다수의 버전들을 방지할 수 있다.
도 17 로 되돌아가서, 버전 파라미터들이 동일하다고 결정되면 (즉, 결정 단계 1701 = "예"), 단계 (1702) 에서, 수신기 디바이스는 이전에 저장된 브로드캐스트 스케쥴 메시지를 삭제하고 새로운 브로드캐스트 스케쥴 메시지를 저장할 수도 있다. 여러 실시형태들에서, 새로운 브로드캐스트 스케쥴 메시지를 저장하는 것은, 파일 전달 프레임워크가 파일들을 캡쳐하라는 애플리케이션으로부터의 요청을 수신할 때마다, 그 요청에서의 새로운 정보를 이용하여 그 저장된 브로드캐스트 스케쥴 메시지를 재프로세싱할 수도 있기 때문에, 중요할 수도 있다. 결정 단계 (1704) 에서, 수신기 디바이스는 브로드캐스트 스케쥴 메시지 레코드 (BSMR) 를 브로드캐스트 스케쥴 메시지로부터 판독하려고 시도할 수도 있다. BSMR 판독이 성공적이었으면 (즉, 결정 단계 1704 = "예"), 결정 단계 (1706) 에서, 수신기 디바이스는 수신된 브로드캐스트 스케쥴 메시지에서의 레코드들 (예컨대, BSMR) 을 프로세싱하고, 그 레코드가 흐름 브로드캐스트 스케쥴 레코드 (FBSR) 인지를 결정할 수도 있다. 그렇다면 (즉, 결정 단계 1706 = "예"), 단계 (1708) 에서, 수신기 디바이스는 흐름 브로드캐스트 스케쥴 레코드를 프로세싱하고 데이터 필터링 결정을 행할 수도 있다. 이 프로세스는, 실패된 BSMR 판독 시도에 의해 결정될 결정 단계 (1704) 로 되돌아감으로써 브로드캐스트 스케쥴 메시지에서의 모든 필드들이 프로세싱될 때까지 반복될 수도 있다. 수신기 디바이스가 결정 단계 (1704) 에서 브로드캐스트 스케쥴 메시지를 성공적으로 판독할 수 없었다면 (즉, 결정 단계 (1704) = "아니오"), 단계 (1710) 에서, 파일 전달 코어 (FDC) 는 새로운 브로드캐스트 스케쥴 메시지에서 특정되어 있지 않은 이전에 스케쥴링된 다운로드들을 취소할 수도 있다.
도 18 은 수신기 디바이스와 브로드캐스트 서버 사이에서 업데이트된 브로드캐스트 스케쥴 메시지들 (BSMs) 의 브로드캐스트의 타이밍을 제어하는 일 실시형태 방법을 도시하는 타임라인도이다. 도 18 은 여러 실시형태들에서, 브로드캐스트 서버가 다음 모니터링 필드 디바이스 프로비젼 파라미터 (예컨대, 다음 모니터링 시간) 를 브로드캐스트 스케쥴 기간 (BSP) 시작 시간 이전에 가변 수의 초 (variable number of seconds) (예컨대, BSF_MONITORING_ADVANCE_TIME) 이도록 설정할 수도 있다는 것을 도시한다. 이것은 수신기 디바이스로 하여금, 브로드캐스트 스케쥴 메시지 업데이트를 검출하여 대응하는 브로드캐스트 스케쥴 기간의 시작 이전에 그 업데이트된 브로드캐스트 스케쥴 메시지를 수신하는데 충분한 시간을 가질 수 있도록 할 수도 있다.
도 18 은 또한 여러 실시형태들에서, 서버가 그 업데이트된 브로드캐스트 스케쥴 메시지를 전송하기 시작하는 시작 시간을 결정하기 위해서 서버가 서버로부터 디바이스까지의 지연을 식별하는 최대 네트워크 지연 디바이스 프로비젼 파라미터 (예컨대, 최대 네트워크 지연) 을 이용할 수도 있다는 것을 도시한다. 여러 실시형태들에서, 서버는 로컬-영역 브로드캐스트 스케쥴 메시지 및 와이드-영역 브로드캐스트 스케쥴 메시지에서의 다음 모니터링 시간을 동일한 값으로 설정할 수도 있다. 이것은 디바이스로 하여금 에너지를 절약할 수 있도록 한다. 수신기 디바이스가 멀티플렉스들 사이에 (예컨대, 하나의 브로드캐스트 영역으로부터 또다른 영역으로) 이동할 수도 있기 때문에, 수신기 디바이스는 수신기가 새로운 멀티플렉스로 이동할 때마다 새로운 멀티플렉스 상에서 브로드캐스트 스케쥴 흐름 (BSF) (70) 을 수신할 수도 있다.
다음 모니터링 시간이 현재 시간보다 겨우 수 초 (예컨대, MAX_BSF_MONITORING_PERIOD) 만큼 늦으면, 수신기 디바이스는 수신된 브로드캐스트 스케쥴 메시지에서의 필드들을 프로세싱한 후에, 브로드캐스트 스케쥴 흐름 (70) 을 등록 해제할 수도 있다. 수신된 브로드캐스트 스케쥴 메시지에서의 필드들을 프로세싱한 후, 수신기 디바이스는 다음 모니터링 시간이 현재 시간보다 늦지 않는다는 조건하에서, 브로드캐스트 스케쥴 흐름 (70) 을 계속 수신할 수도 있다. 수신된 브로드캐스트 스케쥴 메시지에서의 필드들을 프로세싱한 후, 다음 모니터링 시간 현재 시간보다 수 초 (예컨대, MAX_BSF_MONITORING_PERIOD) 보다 많이 늦으면, 디바이스는 브로드캐스트 스케쥴 흐름 (70) 을 계속 수신할 수도 있다.
수신기 디바이스는 브로드캐스트 스케쥴 흐름 (BSF) (70) 을 다음 모니터링 시간에서 수신하도록 스케쥴링할 수도 있다. 디바이스가 브로드캐스트 스케쥴 흐름의 모니터링 시간에서 흐름 커버리지를 벗어나면, 디바이스는 흐름 커버리지 영역에 재진입할 때에 브로드캐스트 스케쥴 흐름 (70) 을 수신할 수도 있다. 수신기 디바이스는 디바이스 상의 파일 전달 프레임워크 (FDF) 가 시작할 때마다, 브로드캐스트 스케쥴 흐름 (70) 을 수신할 수도 있다. 디바이스 상의 파일 전달 프레임워크는 프로세싱된 후 수 초 (예컨대, FDF_BSM_EXPIRY_TIME) 에 브로드캐스트 스케쥴 메시지 (BSM) 를 만료시킬 수도 있다. 디바이스 상의 파일 전달 프레임워크는 최신 브로드캐스트 스케쥴 메시지에 더 이상 특정되어 있지 않으면, 이전에 스케쥴링된 다운로드를 취소할 수도 있다. 서버는 로컬-영역 및 와이드-영역 브로드캐스트 스케쥴 메시지들에서의 다음 모니터링 시간을 동일한 값으로 설정할 수도 있다. 서버는 브로드캐스트 스케쥴 흐름 (70) 에 대한 다음 모니터링 시간을 대응하는 브로드캐스트 스케쥴 기간 시작 시간 전 수 초 (예컨대, BSF_MONITORING_ADVANCE_TIME) 인 것으로 설정할 수도 있다. 수신기 디바이스는, 초기 획득 흐름 (IAF) 으로부터 수신된 디렉토리 정보 메시지 (DIM) 에서의 주어진 멀티플렉스에 대한 브로드캐스트 스케쥴 메시지의 버전 (예컨대, BSM_VERSION) 이 그 디바이스가 프로세싱된 동일한 멀티플렉스에 대한 최신 브로드캐스트 스케쥴 메시지의 버전과 상이할 때, 브로드캐스트 스케쥴 흐름 (70) 상에서 그 업데이트된 브로드캐스트 스케쥴 메시지를 수신할 수도 있다.
여러 실시형태들에서, 서버는 초기 획득 흐름의 (IAF) 다음 모니터링 시간을 다음 브로드캐스트 스케쥴 기간 (BSP) 의 시작 시간 이전의 수 초 (예컨대, BSF_MONITORING_ADVANCE_TIME) 로 설정할 수도 있다. 서버는 디렉토리 정보 메시지 (DIM) 에서 다음 모니터 시간에, 그에 대한 버전 식별자 (예컨대, BSM_VERSION) 를 올리기 전에, 업데이트된 브로드캐스트 스케쥴 메시지를 브로드캐스트할 수도 있다. 수신기 디바이스는 최신 디렉토리 정보 메시지에서 그의 버전 식별자 (예컨대, BSM_VERSION) 가 동일한 브로드캐스트 스케쥴 흐름 (70) 의 버전 식별자와 같으면, 브로드캐스트 스케쥴 흐름 (70) 상에서 수신된 브로드캐스트 스케쥴 메시지를 프로세싱할 수도 있다. 디바이스는 그의 BSM_VERSION 이 최신 디렉토리 정보 메시지에서의 동일한 브로드캐스트 스케쥴 흐름 (70) 에 대한 BSM_VERSION 과 동일하면, 브로드캐스트 스케쥴 흐름 (70) 상에서 수신된 브로드캐스트 스케쥴 메시지를 저장할 수도 있다. 디바이스가 새로운 멀티플렉스로 이동할 때, 새로운 멀티플렉스 상에서 브로드캐스트 스케쥴 흐름 (70) 을 수신할 수도 있다.
도 19 는 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 소프트웨어 아키텍처를 도시한다. 구체적으로 설명하면, 도 19 는 파일 전달 프레임워크가 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층을 포함할 수도 있다는 것을 도시한다. 파일 전달 코어는 데이터를 전송하고 (예컨대, BSF 들을 프로세싱하고), 데이터 흐름으로부터 데이터를 수신하고, 그 수신된 데이터에 대해 여러 다른 기능들 (예컨대, FEC 디코딩) 을 수행하는 것을 담당할 수도 있다. 파일 전달 파일 관리 계층은 파일 전달 코어 계층에 의해 수신된 데이터를 파일들로서 관리하는 것을 담당할 수도 있다. 파일 관리가 디바이스 플랫폼에 의존하기 때문에 (예컨대, 리눅스 및 윈도우들 모바일은 상이한 파일 이름 규약을 갖는다), 여러 실시형태들에서, 각각의 애플리케이션은 파일 전달 파일 관리 계층 자신의 인스턴스일 수도 있다. 이것은 파일 전달 코어가 실행되는 범용 모바일 수신기 (universal mobile receiver; UMR) 디바이스들로 하여금, 상이한 유형의 디바이스들 상의 애플리케이션들과 함께 동작할 수 있도록 한다.
도 20 은 상이한 애플리케이션들에 걸쳐서 파일 공유를 지원하는 파일 전달 프레임워크를 구현하는 일 실시형태 방법 (2000) 을 도시한다. 도 20 은 단계 (2002) 에서, 애플리케이션이 파일 전달 파일 관리 계층에 파일 또는 디렉토리를 캡쳐하라는 요청을 발할 수도 있다는 것을 도시한다. 이 캡쳐 요청은 "일회 캡쳐" 요청 또는 "자동-캡쳐" 요청일 수 있다. 단계 (2004) 에서, 파일 전달 파일 관리 계층은 파일 및 디렉토리 이름들을 파일 전달 코어에 전달하고, 여기서, 파일 전달 코어는 그들을 테이블에 "원하는 스트링들" 로서 저장한다.
단계 (2006) 에서, 파일 전달 코어는 하나 이상의 브로드캐스트 스케쥴 레코드들 (BSRs), 즉, 대응하는 브로드캐스트 스케쥴 기간 (BSP) 에서 브로드캐스트되는 각각의 엘리먼트에 대해 하나를 갖는 브로드캐스트 스케쥴 흐름 (BSF) 으로부터, 업데이트된 브로드캐스트 스케쥴 메시지 (BSM) 를 수신할 수도 있다. 단계 (2008) 에서, 파일 전달 코어는 각각의 브로드캐스트 스케쥴 레코드에 대해, 브로드캐스트 스케쥴 레코드에서의 파일/디렉토리 이름들을 원하는 스트링들과 비교한다. 매칭이 있으면, 단계 (2010) 에서, 파일 전달 코어는 디바이스가 그 매칭된 브로드캐스트 스케쥴 레코드에서의 엘리먼트 ID 에 의해 식별되는 엘리먼트를 이미 갖고 있는지 여부를 파악하기 위해서, 파일 전달 파일 관리 (FDM) 계층을 체크할 수도 있다. 그렇지 않으면, 단계 (2014) 에서, 파일 전달 코어 (FDC) 는 그 엘리먼트를 그 매칭된 브로드캐스트 스케쥴 레코드 (BSR) 에서의 브로드캐스트 스케쥴 정보에 따라서 수신하도록 스케쥴링할 수도 있다. 단계 (2016) 에서, 파일 전달 코어는 하나 이상의 파일 전달 프로토콜 (FDP) 및/또는 파일 전달 제어 프로토콜 (FDCP) 메시지들을 원하는 엘리먼트에 대해 그 스케쥴링된 시간에서 수신하고, 순방향 에러 정정 (FEC) 디코딩을 수행하여 엘리먼트 데이터를 복구할 수도 있다. 단계 (2018) 에서, 파일 전달 코어는 수신된 엘리먼트를 파일 전달 파일 관리 계층으로 포워딩할 수도 있다. 단계 (2020) 에서, 파일 전달 파일 관리 계층은 애플리케이션의 스토리지 정책에 따라서, 엘리먼트를 (파일들의 형태로) 애플리케이션의 스토리지 공간에 저장할 수도 있다. 여러 실시형태들에서, 파일 전달 파일 관리 계층은 또한 엘리먼트가 저장되는 메모리 로케이션 및 엘리먼트의 ID 와 같은, 추가적인 여러 정보들을 유지할 수도 있다. 단계 (2022) 에서, 파일 전달 파일 관리 계층은 애플리케이션에, 파일이 수신되었다는 것을 통지할 수도 있다.
도 21 내지 도 23 은 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름을 도시하는 소프트웨어 아키텍처도들이다. 도 21 은 상이한 계층들 사이의 상호작용을 관리하고 "원하는 스트링들" 테이블을 추적하여 유지하는데 프레임워크에 의해 이용될 수도 있는 구조, 데이터흐름 및 하이-레벨 단계들을 도시한다. 구체적으로 설명하면, 도 21 은 파일 전달 파일 관리 (FDM) 계층과 파일 전달 코어 (FDC) 계층 사이에 파티셔닝하는 일 실시형태 기능을 도시하며, 여기서, 파일 전달 파일 관리 계층은 애플리케이션 요청들을 파일 전달 코어 계층으로 전달한다. 예를 들어, 도 20 은 애플리케이션이 파일 전달 파일 관리 계층에 파일을 한번 캡쳐하거나, 또는 파일 또는 디렉토리를 자동-캡쳐하라는 요청 (화살표 2101) 을 발하는 것을 도시한다. 이 요청 (2001) 은 도 20 을 참조하여 위에서 설명한 단계 (2002) 에 대응한다. 도 21 에 도시된 실시형태에서, 파일들 및 디렉토리들은 그들의 이름들로 특정된다. 다른 실시형태들에서, 파일들 및 디렉토리들은 다양한 명명 및/또는 식별 규약들을 이용하여 특정될 수도 있으며, 이의 일부 예들이 아래에 설명된다.
도 21 을 참조하면, 일단 요청이 애플리케이션에 의해 발해지면, 파일 전달 프레임워크 (FDF) 는 (예컨대, Capture_Once 지령을 통해서) 한번 캡쳐되게 요청된 파일 또는 디렉토리의 이름을, 그 디렉토리의 파일 또는 일부 파일들이 성공적으로 수신될 때까지 유지할 수도 있다. 파일 전달 프레임워크는 또한 (예컨대, Auto_Capture 지령을 통해서) 애플리케이션에 의해 자동적으로 캡쳐되게 요청된 파일 또는 디렉토리의 이름을, 애플리케이션이 그 요청을 취소할 때까지 유지할 수도 있다. 파일 전달 파일 관리 계층은 파일 및 디렉토리 이름들을 파일 전달 코어에 전달할 수도 있다 (화살표 2102). 파일 전달 코어는 파일 및 디렉토리 이름들을 테이블에 "원하는 스트링들"로 저장할 수도 있다.
도 22 는 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름, 및 파일 전달 프레임워크가 파일을 수신하도록 선택하는 결정 프로세스를 도시한다. 예를 들어, 파일 전달 코어 (FDC) 계층은 브로드캐스트 스케쥴 흐름 (BSF) 으로부터, 업데이트된 브로드캐스트 스케쥴 메시지 (BSM) 를 수신할 수도 있다 (화살표 2201). 브로드캐스트 스케쥴 메시지는 하나 이상의 브로드캐스트 스케쥴 레코드들 (BSR1, BSR2), 즉, 대응하는 브로드캐스트 스케쥴 기간 (BSP) 에 브로드캐스트되는 각각의 엘리먼트에 대해 하나를 가질 수도 있다. 브로드캐스트 스케쥴 레코드는 대응하는 엘리먼트에 대한 엘리먼트 ID, 그 엘리먼트에서의 파일(들) 에 대한 하나 이상의 파일/디렉토리 이름들, 및 브로드캐스트 스케쥴 정보를 포함할 수도 있다. 파일 전달 코어는 각각의 브로드캐스트 스케쥴 레코드에 대해 브로드캐스트 스케쥴 레코드에서의 파일/디렉토리 이름들을 원하는 스트링들과 비교할 수도 있다 (화살표 2202). 매칭이 있으면, 파일 전달 코어는 디바이스가 그 매칭된 브로드캐스트 스케쥴 레코드에서의 엘리먼트 ID 에 의해 식별되는 엘리먼트를 이미 갖고 있는지 여부를 파악하기 위해서, 파일 전달 파일 관리 계층을 체크할 수도 있다 (화살표 2203). 그렇지 않으면, 파일 전달 코어는 엘리먼트를 그 매칭된 브로드캐스트 스케쥴 레코드에서의 브로드캐스트 스케쥴 정보에 따라서 수신하도록 스케쥴링할 수도 있다. 여러 실시형태들에서, 파일의 상이한 버전들이 상이한 엘리먼트 ID 들을 가질 수도 있음에 유의해야 한다. 여러 실시형태들에서, 엘리먼트 ID 들에 기초하는 필터링이, 아래에서 좀더 자세하게 설명하는 바와 같이, 파일 전달 프레임워크로 하여금, 디바이스 상에 이미 존재하는 파일들에 대한 업데이트들을 수신할 수 있게 하는데 이용될 수도 있다는 점에 유의해야 한다.
도 22 는 또한 여러 실시형태들에서, 파일 전달 파일 관리 (FDM) 계층이 관리된 엘리먼트 테이블 (MET) 을 유지할 수도 있다는 것을 도시한다. 관리된 엘리먼트 테이블은 파일 전달 프레임워크에 의해 수신되는 모든 엘리먼트들에 관한 정보를 포함할 수도 있다. 여러 실시형태들에서, 관리된 엘리먼트 테이블은 또한 엘리먼트 ID 들, 파일 이름들, (엘리먼트가 다수의 파일 이름들을 가질 수 있는 실시형태들에서) 별칭들, 스토리지 이름들, 및 다른 속성들과 같은, 추가적인 여러 정보들을 포함할 수도 있다. 관리된 엘리먼트 테이블이 도 40 및 도 57 를 참조하여 아래에서 좀더 자세하게 설명된다.
도 22 로 되돌아가서, 여러 실시형태들에서, 파일 전달 파일 관리 (FDM) 계층은 원하는 스트링 테이블 (예컨대, 원하는 스트링들) 을 유지할 수도 있다. 원하는 스트링 테이블은 애플리케이션에 의해 요청되는 파일 또는 디렉토리 이름 (예컨대, 스트링) 과 같은 여러 정보 피스들을 포함할 수도 있다. 원하는 스트링 테이블은 또한 애플리케이션으로부터의 요청을 고유하게 식별하는 요청 핸들 (예컨대, Req Inst) 을 포함할 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 이 요청 핸들을 이용하여, 파일 전달 코어가 특정의 요청에 매칭하는 엘리먼트를 수신할 때 통지되어야 하는 파일 전달 파일 관리 계층 인스턴스들을 식별할 수도 있다.
도 22 는 또한 파일 전달 코어 (FDC) 가 브로드캐스트 스케쥴 흐름 (BSF) 상에서 업데이트된 브로드캐스트 스케쥴 메시지들 (BSMs) 을 수신할 수도 있다는 것을 도시한다. 파일 전달 코어는 또한 애플리케이션들이 관심을 갖는 엘리먼트들만을 선택적으로 수신하는 데이터 필터링 유닛 (2210) 을 가질 수도 있다. 즉, 데이터 필터링 유닛 (2210) 은 브로드캐스트 스케쥴 메시지에 의해 결정하는 바와 같이, 애플리케이션들이 수신하도록 등록하고 있는 엘리먼트들을 선택적으로 수신하는 것을 담당할 수도 있다. 여러 실시형태들에서, 데이터 필터링 유닛은 애플리케이션들이 관심을 갖는 엘리먼트들의 임의의 엘리먼트가 브로드캐스트될지 여부를 결정하기 위해서, 최신 브로드캐스트 스케쥴 메시지에서의 흐름 브로드캐스트 스케쥴 레코드들 (FBSRs) 을 프로세싱할 수도 있다. 여러 실시형태들에서, 데이터 필터링 유닛은 흐름 브로드캐스트 스케쥴 레코드들을, 브로드캐스트 스케쥴 메시지 내에 포함되는 브로드캐스트 스케쥴 정보와 함께, 이용하여, 애플리케이션들이 관심을 갖는 엘리먼트들의 수신기 디바이스들 다운로딩을 스케쥴링할 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 이 스케쥴을 이용하여, 수신기 회로를 스케쥴링된 시간에서 웨이크업하여, 애플리케이션들이 관심을 갖는 엘리먼트들을 수신할 수도 있다.
도 23 은 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 예시적인 구조 및 데이터흐름, 및 수신기 디바이스 상의 파일 전달 프레임워크가 파일들을 수신하여 저장할 수도 있는 프로세스를 도시한다. 도시된 예에서, 파일 전달 코어 (FDC) 는 원하는 엘리먼트에 대해 FDP/FDCP 메시지들을 스케쥴링된 시간에 수신하여 (화살표 2301), 스크래치 공간 (2310) 에 저장한다. 일부 실시형태들에서, 파일 전달 코어는 또한 엘리먼트 데이터를 복구하기 위해서, (FEC 인코딩된 심볼들 및 FEC 인코딩 정보를 각각 운반하는) FDP/FDCP 메시지들에 대해 순방향 에러 정정 디코딩을 수행할 수도 있다. 파일 전달 코어는 그 수신된 엘리먼트를 파일 전달 파일 관리 (FDM) 계층으로 포워딩할 수도 있다 (화살표 2302). 파일 전달 파일 관리 계층은 애플리케이션의 스토리지 정책에 따라서, 엘리먼트를 파일들의 형태로 애플리케이션의 스토리지 공간 (2315) 에 저장할 수도 있다 (화살표 2303). 여러 실시형태들에서, 파일 전달 파일 관리 계층은 또한 엘리먼트가 저장되는 장소 (스토리지 (Storage)) 및 엘리먼트의 ID (EID) 와 같은, 여러 정보 피스들을 유지할 수도 있다. 엘리먼트를 애플리케이션의 스토리지 공간에 저장한 후, 파일 전달 파일 관리 계층은 애플리케이션에, 파일이 그 애플리케이션용으로 수신되었다는 것을 통지할 수도 있다 (화살표 2304).
도 24 는 브로드캐스트 스케쥴 메시지들에서의 정보에 기초하여 결정되는 수신에 의해서, 애플리케이션들이 관심을 갖는 엘리먼트들만을 선택적으로 수신하도록 파일 전달 코어에서 데이터 필터링 유닛 (2210) 을 구현하는 일 실시형태 방법 (2400) 을 도시한다. 단계 (2402) 에서, 데이터 필터링 유닛 (2210) 은 브로드캐스트 스케쥴 레코드들 (BSRs) 이름들 또는 특성들을 식별하기 위해서 흐름 브로드캐스트 스케쥴 레코드 (FBSR) 헤더들을 프로세싱할 수도 있다. 결정 단계 (2404) 에서, 데이터 필터링 유닛 (2210) 은 그 수신된 브로드캐스트 스케쥴 메시지에 임의의 프로세싱되지 않은 관심 브로드캐스트 스케쥴 레코드들이 존재하는지 여부 (즉, 레코드들이 요청 애플리케이션들에 의해 특정되는 명명 규약들 또는 선택 기준들을 만족하는지 여부) 를 결정할 수도 있다. 존재하지 않으면 (즉, 결정 단계 2404 = "아니오"), 데이터 필터링 유닛 (2210) 은 정지 (shut down) 될 수도 있다. 그러나, 프로세싱되지 않은 관심 브로드캐스트 스케쥴 레코드들이 있으면 (즉, 결정 단계 2404 = "예"), 단계 (2406) 에서, 데이터 필터링 유닛 (2210) 은 프로세싱되지 않은 브로드캐스트 스케쥴 레코드들을 흐름 브로드캐스트 스케쥴 레코드 바디 (예컨대, FBSR 바디) 로부터 판독할 수도 있다. 단계 (2408) 에서, 데이터 필터링 유닛 (2210) 은 브로드캐스트 스케쥴 레코드들을 프로세싱한 후, 모든 관심 흐름 브로드캐스트 스케쥴 레코드들이 프로세싱되었는지 여부를 결정하기 위해서 결정 단계 (2404) 로 되돌아갈 수도 있다. 이 프로세스는 모든 관심 흐름 브로드캐스트 스케쥴 레코드들이 프로세싱될 때 (즉, 결정 단계 2404 = "아니오") 까지 계속될 수도 있다.
도 25 는 흐름 브로드캐스트 스케쥴 레코드에서 브로드캐스트 스케쥴 레코드들을 프로세싱하는 일 실시형태 방법 (2500) 을 도시한다. 결정 단계 (2502) 에서, 파일 전달 코어의 데이터 필터링 유닛 (2210) 은 브로드캐스트 스케쥴 레코드에서 임의의 프로세싱되지 않은 필드들이 있는지 여부를 결정한다. 있으면 (즉, 결정 단계 2502 = "예"), 파일 전달 코어는 브로드캐스트 스케쥴 레코드에 의해 기술되는 엘리먼트를 수신해야 하는지 여부를 결정한다. 여러 실시형태들에서, 파일 전달 코어는, 대응하는 브로드캐스트 스케쥴 레코드가 원하는 스트링과 양방향-토큰-프리픽스-매칭하는 적어도 하나의 속성 스트링을 가질 때; 엘리먼트가 파일 전달 코어의 스크래치 공간에 존재하지 않을 때; 그리고, 엘리먼트가 애플리케이션의 스토리지 공간에 존재하지 않을 때마다, 엘리먼트를 수신하도록 결정할 수도 있다. 파일 전달 코어가 엘리먼트를 수신하기로 결정하는 프로세스가 아래에서 좀더 자세하게 설명된다.
도 25 로 되돌아가서, 엘리먼트가 수신되어야 하는지 여부를 결정하는 것은 데이터 필터링 유닛 (2210) 이 관심 필드를 프로세싱되지 않은 브로드캐스트 스케쥴 레코드로부터 판독하는 단계 (2504) 에서 시작할 수도 있다. 결정 단계 (2506) 에서, 데이터 필터링 유닛 (2210) 은 관심 필드, 또는 엘리먼트가 프리픽스-매칭 필드인지 여부를 결정할 수도 있다. 그 엘리먼트가 프리픽스-매칭 필드가 아니면 (즉, 결정 단계 2506 = "아니오"), 데이터 필터링 유닛 (2210) 은 브로드캐스트 스케쥴 레코드에 임의의 더 많은 프로세싱되지 않은 필드들이 있는지 여부를 결정하기 위해서 결정 단계 (2502) 로 되돌아갈 수도 있다. 그러나, 관심 필드가 프리픽스-매칭 필드이면 (즉, 결정 단계 (2506) = "예"), 결정 단계 (2510) 에서, 데이터 필터링 유닛 (2210) 은 그 엘리먼트가 원하는 스트링과 "양방향-토큰-프리픽스-매칭하는지" 여부를 결정할 수도 있다.
여러 실시형태들에서, s1 이 s2 의 토큰-프리픽스이거나 또는 s2 가 s1 의 토큰-프리픽스일 때마다 스트링 s1 은 스트링 s2 와 "양방향-토큰-프리픽스-매칭한다". 여러 실시형태들에서, 파일 전달 프레임워크에서 토큰-프리픽스 매치는 그 파일의 구성요소들로서 정의되는 토큰들에, 또는 슬래시 "/" 구두 문자에 의해 구분되는 디렉토리 이름들로서 정의되는 토큰들에 기초할 수도 있다. 예를 들어, 이런 실시형태들에서, 파일 이름 "/cnn/tech/f1.mp4" 은 3개의 토큰들: cnn; tech; 및 f1.mp4 를 갖도록 결정될 것이다. 따라서, 파일 전달 프레임워크는, s1 이 토큰들 t1, 1, t1, 2,..., t1, K 을 갖는다; s2 가 토큰들 t2, 1, t2, 2, t2, 3,..., t2, L 을 갖는다; k 가 L 보다 작거나 또는 같다; j=1, 2,..., K 에 대해서 t1, j 가 t2, j 와 같다 중 어느 것이 참이면, 스트링 s1 이 스트링 s2 의 프리픽스인 것으로 간주될 수도 있다. 이들 실시형태들에서, 파일이 "/cnn/tech" 에 대해 브로드캐스트되고 그 애플리케이션이 "/cnn/" 아래의 임의의 파일들을 원한다는 것을 브로드캐스트 스케쥴 레코드가 나타내면, - 파일 전달 코어는 /cnn/tech/ 에 대해 브로드캐스트된 파일을 수신해야 한다. 이와 유사하게, 파일이 "/cnn" 에 대해서 브로드캐스트되고 그 애플리케이션이 "/cnn/tech/" 아래의 임의의 파일들을 원한다는 것을 브로드캐스트 스케쥴 레코드가 나타내면, 파일 전달 코어는 "/cnn/tech/" 아래에 있을 수 있는 임의의 파일들이 분실되는 것을 피하기 위해서, /cnn 에 대해서 브로드캐스트된 파일을 수신해야 한다. 일 실시형태에서, 모든 스트링 매칭들은 대소문자 구분될 수도 있다. 일 실시형태에서, 파일 전달 코어는 브로드캐스트 스케쥴 레코드가 파일에 대한 것인지 또는 파일 번들에 대한 것인지 여부에 무관하게, 동일한 스트링 매칭 알고리즘을 적용할 수도 있다.
도 25 로 되돌아가서, 원하는 스트링에 양방향-프리픽스-매칭하면 (즉, 결정 단계 2510 = "예"), 흐름은 결정 단계 (2512) 로 진행하여, 파일 전달 파일 관리 (FDM) 계층이 엘리먼트를 이미 포함하고 있는지 여부를 데이터 필터링 유닛 (2210) 이 결정할 수도 있다. 포함하고 있으면 (즉, 결정 단계 2512 = "예"), 프로세싱이 중지된다. 파일 전달 파일 관리 계층이 엘리먼트를 포함하고 있지 않으면 (즉, 결정 단계 2512 = "아니오"), 데이터 필터링 유닛 (2210) 은 아직 스케쥴링되지 않았으면, 단계 (2514) 에서, 대응하는 엘리먼트를 수신하도록 스케쥴링할 수도 있다. 여러 실시형태들에서, 대응하는 엘리먼트는 흐름 id (예컨대, FLOW_ID) 에 대한 브로드캐스트 스케쥴 레코드 (예컨대, BCAST_SCHEDULE_RECORD) 에 따라서 스케쥴링될 수도 있다. 단계 (2516) 에서, 데이터 필터링 유닛 (2210) 은 브로드캐스트 스케쥴 레코드 내의 다른 필드들을 프로세싱할 수도 있다.
도 26 은 수신기 디바이스 상의 파일 전달 프레임워크 (FDF) 의 구조 및 데이터흐름, 및 브로드캐스트 스케쥴 레코드들이 프로세싱될 수도 있는 프로세스를 도시한다. 위에서 설명한 바와 같이, 파일 전달 코어 (FDC) 는 대응하는 브로드캐스트 스케쥴 레코드 (BSR) 가 원하는 스트링에 양방향-토큰-프리픽스-매칭하는 적어도 하나의 속성 스트링을 갖고 그 엘리먼트가 파일 전달 코어의 스크래치 공간에 존재하지 않으면, 엘리먼트를 수신할 수도 있다. 화살표 2601 는 파일 전달 코어의 데이터 필터링 유닛 (2210) 이 엘리먼트를 프로세싱되지 않은 브로드캐스트 스케쥴 레코드로부터 판독하고, 그 엘리먼트가 프리픽스-매칭 필드인지 여부를 결정하고, 그 엘리먼트가 원하는 스트링에 양방향-토큰-프리픽스-매칭하는지 여부를 결정하는 데이터흐름 및 프로세스를 도시한다. 화살표 2602 는 파일 전달 파일 관리 (FDM) 계층이 엘리먼트를 이미 포함하고 있는지 여부를 파일 전달 코어의 데이터 필터링 유닛 (2210) 이 결정하는 데이터흐름 및 프로세스를 도시한다. 파일 전달 파일 관리 계층이 엘리먼트를 포함하지 않으면, 파일 전달 코어는 아직 스케쥴링되어 있지 않은 경우에 대응하는 엘리먼트를 수신하도록 스케쥴링할 수도 있다. 그 결정이 엘리먼트를 수신하도록 하는 것이면, 파일 전달 코어의 스케쥴러 (2605) 는 그 엘리먼트를 브로드캐스트 스케쥴 레코드에 특정되는 브로드캐스트 윈도우에서 수신하도록 스케쥴링할 수도 있다. 여러 실시형태들에서, 수신기 디바이스 상의 파일 전달 프레임워크는, 브로드캐스트 스케쥴 레코드가 애플리케이션들에 의해 요청되는 파일 또는 디렉토리 이름에 양방향-토큰-프리픽스-매칭하는 적어도 하나의 속성 스트링을 갖고 엘리먼트가 그 디바이스 상에 이미 존재하지 않으면, 브로드캐스트 스케쥴 레코드에 의해 기술되는 엘리먼트를 수신하도록 스케쥴링할 수도 있다.
도 27 은 파일이 브로드캐스트되고 있는 시간 동안 파일의 수신이 차단되는 상황을 도시하는 타임라인도이다. 여러 실시형태들에서, 부분 파일을 스크래치 공간 (2310) 에 저장함으로써, 파일 전달 코어는 파일 전송의 재개를 대기하고, 그 다운로드된 파일들에 대해 순방향 에러 정정 코드를 적용할 가능성 (feasibility) 에 관련한 제 2 결정을 행할 수 있다.
도 28 은 다운로드된 데이터 (2805) 가 어떻게 스크래치 공간 메모리 (2310) 에 전달되어 저장되는지를 도시한다. 위에서 설명한 바와 같이, 파일 전달 코어는 그 다운로드된 파일들에 대해 순방향 에러 정정 (FEC) 디코딩을 적용하기 전에 그 다운로드된 파일들을 저장할 뿐만 아니라, 그 디코딩된 파일들을 유지하는 스크래치 공간 메모리 (2310) 를 가질 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 미완료된 다운로드들, 완료되었지만 디코딩되지 않은 다운로드들, 및 디코딩된 다운로드들을 스크래치 공간 (2310) 에 저장한다.
다양한 상황들에서, 스크래치 공간 (2310) 은 미완료된 다운로드들을 저장할 수도 있다. 예를 들어, 다운로드된 데이터는 순방향 에러 정정 디코딩을 위해서 스크래치 공간에 저장된다 (즉, 그 다운로드가 완료되지 않는다). 여러 실시형태들에서, 다운로드된 데이터는 브로드캐스트가 끝날 때까지 스크래치 공간 (2310) 에 유지될 수도 있어, 도 27 에 도시된 바와 같이, 차단된 데이터 수신의 상황들을 도모할 수도 있다.
위에서 설명한 바와 같이, 스크래치 공간 (2310) 은 또한 완료되었지만 디코딩되지 않은 다운로드들을 저장할 수도 있다. 즉, 여러 상황들에서, 다운로드들은 성공적인 순방향 에러 정정 (FEC) 디코딩을 위한 충분한 데이터를 갖지만, 순방향 에러 정정 디코딩이 아직 완료되지 않았을 수도 있다 (즉, 다운로드들이 완료되었지만 디코딩되지 않는다). 이들 상황들에서, 파일 전달 코어는 이들 파일들을, 디코딩될 수 있을 때까지, 스크래치 공간에 저장할 수도 있다. 일부 실시형태들에서, 프로세서 사용을 제한하기 위해서, 순방향 에러 정정 디코더는 한번에 하나의 파일을 디코딩할 수도 있다. 일부 실시형태들에서, 순방향 에러 정정 디코더는, 그 디바이스가 파일 전달 데이터를 다운로드하고 있을 때, 파일을 디코딩하는 것이 방지될 수도 있다. 일부 실시형태들에서, 스크래치 공간 (2310) 은 요청 애플리케이션에 아직 전달되지 않은 디코딩된 다운로드들을 저장할 수도 있다.
일 실시형태에서, 스크래치 공간 (2310) 은 수신 디바이스의 내부 메모리 상에 로케이트될 수도 있다. 다른 실시형태들에서, 수신기 디바이스들은 내부 메모리 및 외부 메모리 양자 상에 스크래치 공간 (2310) 을 가질 수도 있다. 이들 실시형태들에서, 파일 전달 프레임워크 애플리케이션은 내부 메모리 스토리지 정책 뿐만 아니라, 외부 메모리 스토리지 정책 양자를 가질 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 내부 메모리 스토리지 정책을 이용하는 그들 애플리케이션들에 대해서는 내부 스크래치 공간을 이용하고, 외부 메모리 스토리지 정책을 이용하는 그들 애플리케이션들에 대해서는 외부 스크래치 공간을 이용할 수도 있다.
여러 실시형태들에서, 스크래치 공간 관리 정책들은 여러 메모리 로케이션들 간에 데이터를 이동시키는 정책들 및 기능들을 포함할 수도 있다. 스크래치 공간 관리 정책들은 성공적으로 디코딩된 엘리먼트들을 스크래치 공간 (2310) 으로부터 애플리케이션 스토리지 공간으로 이동시키는 기능들을 포함할 수도 있다. 스크래치 공간 관리 정책들은 스크래치 공간 (2310) 상의 쓸모없는 데이터를 주기적으로 삭제하는 기능들을 포함할 수도 있다. 스크래치 공간 관리 정책들은 스크래치 공간 (2310) 이 공간을 다 소모하거나, 또는 막 다 소모하려고 할 때 스크래치 공간 (2310) 상의 데이터를 삭제하는 기능들을 포함할 수도 있다. 디바이스 상의 파일 전달 프레임워크는 여러 애플리케이션들에 대해서 내부 메모리 또는 외부 메모리들의 스크래치 공간 (2310) 을 이용할 수도 있다. 디바이스 상의 파일 전달 프레임워크는 내부 메모리 스토리지 정책을 이용하는 애플리케이션들에 대해서는 내부 메모리의 스크래치 공간 (2310) 을 이용할 수도 있다. 디바이스 상의 파일 전달 프레임워크는 외부 메모리 스토리지 정책을 이용하는 애플리케이션들에 대해서는 외부 메모리의 스크래치 공간 (2310) 을 이용할 수도 있다. 디바이스 상의 파일 전달 프레임워크는 스크래치 공간 (2310) 을 내부 및 외부 메모리들과 스토리지 정책들의 임의의 조합으로 이용할 수도 있다.
도 29 는 엘리먼트들을 프로세싱하여 저장하는 일 실시형태 방법 (2900) 을 도시한다. 단계 (2902) 에서, 파일 전달 코어는 단일 파일에 대응하는 엘리먼트를 성공적으로 순방향 에러 정정 (FEC) 디코딩한다. 단계 (2904) 에서, 파일 전달 코어는 파일 전달 파일 관리 (FDM) 계층에 엘리먼트가 수신되었다는 것을 통지할 수도 있다. 단계 (2906) 에서, 파일 전달 파일 관리 계층은 그 엘리먼트의 파일에 대한 스토리지 로케이션을 결정할 수도 있다. 단계 (2908) 에서, 파일 전달 파일 관리 계층은, 파일 전달 코어로 하여금, 엘리먼트를 스크래치 공간 (2310) 으로부터 스토리지 로케이션으로 이동시키도록 안내할 수도 있다. 단계 (2910) 에서, 디바이스 상의 파일 전달 프레임워크는 애플리케이션의 스토리지 공간에 충분한 공간이 있으면, 애플리케이션에 대한 엘리먼트들을 성공적으로 수신한 후에 엘리먼트들을 애플리케이션의 스토리지 공간 (2310) 으로 이동시킬 수도 있다.
여러 실시형태들에서, 파일 전달 코어는 스크래치 공간 상의 쓸모없는 데이터를 주기적으로 삭제할 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 브로드캐스트들이 종료되고 그들에 대한 유니캐스트 폴백 (fallback) 메커니즘이 없는 미완료된 다운로드들에서의 데이터를 삭제함으로써, 스크래치 공간을 주기적으로 클린업할 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 애플리케이션 스토리지 공간으로 이동되는 것이 실패되고 스크래치 공간에 디바이스 프로비젼 파라미터 (예컨대, FDF_MAX_ELEMENT_TIME_IN_SCRATCH_SPACE) 에 의해 표시되는 수 초 동안 있었던, 성공적으로 디코딩된 엘리먼트들에서의 데이터를 삭제함으로써, 스크래치 공간을 주기적으로 클린업할 수도 있다. 여러 실시형태들에서, 클린업 기간은 FDF_SCRATCH_SPACE_CLEAN_UP_PERIOD 와 같은 디바이스 구성 파라미터에 의해 제어될 수도 있다. 여러 실시형태들에서, 주기적 스크래치 공간 클린업 메커니즘은 스크래치 공간의 풋프린트를 작게 유지할 수도 있다. 일 실시형태에서, 파일 전달 프레임워크는 브로드캐스트들이 종료되었고 그들에 대한 유니캐스트 폴백이 없는 미완료된 다운로드 데이터 (데이터가 성공적인 FEC 디코딩에 충분하지 않다) 를, 수 (예컨대, FDF_SCRATCH_SPACE_CLEAN_UP_PERIOD) 초마다 한번 삭제한다. 일 실시형태에서, 파일 전달 프레임워크는 가변 수 (variable number) 의 초 (예컨대, DF_MAX_ELEMENT_TIME_IN_SCRATCH_SPACE 초) 보다 많은 초 이전에 성공적으로 디코딩되었으나 애플리케이션 스토리지 공간에 이동시키는 것을 실패한 데이터를 삭제한다.
여러 실시형태들에서, 파일 전달 코어는 스크래치 공간 사이즈가 임계 상한에 도달하면, 스크래치 공간을 다 소모하였다고 결정할 수도 있다. 파일 전달 코어는 또한 스크래치 공간이 상주하는 메모리 공간이 가득차면, 스크래치 공간을 다 소모하였다고 결정할 수도 있다. 일 실시형태에서, 내부 스크래치 공간 상한은 OEM (original equipment manufacturer) 프로비져닝 디바이스 파라미터 (예컨대, FDF_MAX_INTERNAL_SCRATCH_SPACE_SIZE) 에 의해 특정될 수도 있다. OEM 프로비져닝 디바이스 파라미터 (예컨대, FDF_MAX_INTERNAL_SCRATCH_SPACE_SIZE) 가 부재하면, 수신기 디바이스는 파라미터의 디폴트 값을 내부 스크래치 공간 상한으로서 이용할 수도 있다. 여러 실시형태들에서, 외부 스크래치 공간 상한은 FDF_MAX_EXTERNAL_SCRATCH_SPACE_SIZE 와 같은 디바이스 디버그 파라미터에 의해 특정될 수도 있다.
도 30 은 아이템들을 스크래치 공간 메모리로부터 삭제하도록 선택하는 일 실시형태 방법 (3000) 을 도시한다. 여러 실시형태들에서, 파일 전달 코어는 일련의 규칙들을 이용하여, 데이터가 스크래치 공간으로부터 삭제될 필요가 있는 시기 및 어느 데이터가 삭제되어야 하는지를 결정한다. 예를 들어, 파일 전달 코어는 어느 데이터가 삭제되어야 하는지를 결정하기 위해서 다수의 우선순위 정렬된 규칙들 (예컨대, 규칙 1 및 규칙 2) 을 이용할 수도 있으며, 여기서, 규칙들은 우선순위 순서로 실행된다 (예컨대, 규칙 1 이 규칙 2 보다 더 높은 우선순위를 갖는다). 예를 들어, 제 1 규칙 (규칙 1) 은 디코딩된 엘리먼트들이 최고 우선순위를 갖는다는 것일 수도 있으며 한편, 제 2 규칙 (규칙 2) 은 완료된 다운로드들이 미완료된 다운로드들보다 더 높은 우선순위를 갖는다는 것일 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 스크래치 공간에서 각각의 데이터 피스에 대한 엔트리를 가진 정렬된 리스트를 유지할 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 도 30 에 도시된 바와 같이 우선순위 정렬된 규칙들 (예컨대, 규칙 1 및 규칙 2) 을 이용하여, 리스트를 정렬할 수도 있다.
도 30 의 단계 (3002) 에서, 파일 전달 코어는 제 1 규칙 (규칙 1) 을 적용하여 그 리스트를 정렬할 수도 있다. 단계 (3004) 에서, 파일 전달 코어는 동일한 레벨 (예컨대, 레벨 1) 버킷에서의 엔트리들이 제 1 규칙 (예컨대, 규칙 1) 에 따라 동일한 순서 또는 우선순위를 갖도록, 어느 정도의 레벨 1 버킷들을 생성할 수도 있다. 단계 (3006) 에서, 파일 전달 코어는 제 2 규칙 (예컨대, 규칙 2) 을 단계 (3004) 에서 발생된 제 1 레벨 (예컨대, 레벨 1) 버킷들의 각각에 적용할 수도 있다. 이것은 단계 (3008) 에 도시된 바와 같이, 제 1 레벨 (예컨대, 레벨 1) 버킷들의 각각을 조금 더 작은 제 2 레벨 버킷들로 분할할 것이다. 이로 인해, 동일한 레벨 (예컨대, 레벨 2) 버킷들에서 엔트리들이 제 1 및 제 2 규칙들 (예컨대, 규칙 1 및 규칙 2) 에 따라 동일한 순서 또는 우선순위를 갖게 될 수도 있다. 일 실시형태에서, 이 프로세스는 모든 규칙들이 스크래치 공간에 저장된 아이템들의 리스트에서의 엔트리들에 적용될 때까지 계속될 수도 있다.
도 31 은 스크래치 공간에 저장된 아이템들의 리스트에의 방법 (3000) 의 적용을 도시한다. 구체적으로 설명하면, 도 31 은 제 1 규칙 (예컨대, 규칙 1) 이 삭제에 적격인 스크래치 공간의 모든 데이터에 적용될 수도 있다는 것을 도시한다. 제 1 규칙의 적용은 스크래치 공간의 데이터를 다수의 제 1 레벨 버킷들 (레벨 1 버킷들) 로 분리한다. 그 후, 제 2 규칙 (예컨대, 규칙 2) 이 그 데이터를 다수의 제 2 레벨 버킷들 (레벨 2 버킷들) 로 추가로 분리하기 위해서 제 1 레벨 버킷들의 각각에 적용된다. 일 실시형태에서, 제 2 레벨 버킷들은 그들의 최대 공간 사이즈들에 따라서 편성될 수도 있다.
여러 실시형태들에서, 파일 전달 코어는 파일 전달 코어가 데이터를 엘리먼트에 대한 데이터 흐름으로부터 수신할 때마다, 그리고 또한 그 스크래치 공간에서 완료되었지만 디코딩되지 않은 다운로드가 순방향 에러 정정 (FEC) 디코딩용으로 선택될 때, 스크래치를 다 소모할 것인지를 결정할 수도 있다. 후자의 체크는 상이한 사이즈들의 인코딩된 엘리먼트들이 순방향 에러 정정 디코딩을 위한 스크래치 공간에서 상이한 양들의 임시 메모리를 필요로 할 수도 있기 때문에 필수적일 수도 있다.
여러 실시형태들에서, 파일 전달 코어가 스크래치 공간을 다 소모하는 것으로 검출하면, 그 정렬된 리스트에서 최저 순서를 가진 데이터를 삭제할 수도 있다. 파일 전달 코어는 새로운 공간 요구사항들이 만족될 때까지 데이터를 계속 삭제할 수도 있다. 여러 실시형태들에서, 최저 순서를 갖는 다수의 데이터 유닛들이 있으면, 파일 전달 코어는 삭제할 하나 이상을 무작위로 선택할 수도 있다. 미완료된 다운로드가 삭제되는 것을 필요로 하고 그의 다운로드가 여전히 진행중이면, FDF 는 삭제 전에 다운로드를 중단할 수도 있다. 파일 전달 코어가 엘리먼트를 다운로드하기 시작할 때, 그에 대한 엔트리를 정렬된 리스트에 추가할 수도 있다. 다운로드되고 있는 엘리먼트가 스크래치 공간을 소모하는 것에 기인하여 삭제하도록 선택되면, 파일 전달 프레임워크는 그의 다운로드를 취소할 수도 있다.
여러 실시형태들에서, 디바이스 상의 파일 전달 프레임워크는 바이트 단위의 내부 스크래치 공간 사이즈가 OEM 프로비져닝 디바이스 파라미터 (예컨대, FDF_MAX_INTERNAL_SCRATCH_SPACE_SIZE) 와 같거나 또는 더 큰지 여부에 기초하여, 내부 스크래치 공간을 다 소모할 것이라고 결정할 수도 있다. 일 실시형태에서, OEM 프로비져닝 디바이스 파라미터 (예컨대, FDF_MAX_INTERNAL_SCRATCH_SPACE_SIZE) 가 디바이스 상에 부재하면, 디바이스는 그 파라미터의 디폴트 값을 내부 스크래치 공간의 상한으로서 이용할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 외부 스크래치 공간 사이즈가 디바이스 디버그 파라미터 (예컨대, FDF_MAX_EXTERNAL_SCRATCH_SPACE_SIZE) 와 같거나 또는 더 큰지 여부에 기초하여, 외부 스크래치 공간을 다 소모할 것이라고 결정할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 스크래치 공간이 상주하는 메모리 카드가 공간을 다 소모하는지 여부에 기초하여, 스크래치 공간을 다 소모할 것이라고 결정할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 내부 메모리 스토리지 정책을 이용하는 애플리케이션에 대한 데이터 흐름으로부터 데이터를 수신할 때, 내부 스크래치 공간을 다 소모할 것인지 여부를 결정하기 위해서 체크할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 외부 메모리 스토리지 정책을 이용하는 애플리케이션에 대한 데이터 흐름으로부터 데이터를 수신할 때, 외부 스크래치 공간을 다 소모할 것인지 여부를 결정하기 위해서 체크할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 그 스크래치 공간에서의 엘리먼트를 순방향 에러 정정 (FEC) 디코딩하기 시작할 때, 스크래치 공간을 다 소모할 것인지 여부를 결정하기 위해서 체크할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 스크래치 공간을 다 소모하면, 데이터를 스크래치 공간에 기록하는 것을 중지할 수도 있다. 일 실시형태에서, 새로운 요구에 대한 스크래치 공간이 충분하지 못하다고 검출할 때, 디바이스 상의 파일 전달 프레임워크는 새로운 스토리지 요구사항이 만족될 수 있도록 하는 스크래치 공간으로부터 단지 최소 필요한 양의 데이터를 삭제할 수도 있다. 일 실시형태에서, 스크래치 공간을 다 소모하는 것에 응답하여 데이터를 그 스크래치 공간으로부터 삭제할 때, 디바이스 상의 파일 전달 프레임워크는 규칙 1 - 디코딩된 엘리먼트가 최고 우선순위를 갖는다; 및 규칙 2 - 완료된 다운로드들이 미완료된 다운로드보다 더 높은 우선순위를 갖는다 (여기서 규칙 1 은 규칙 2 보다 더 높은 우선순위를 갖는다) 의 2 개의 규칙들에 따라서 결정되는 바와 같이, 최저 순서 또는 우선순위를 갖는 데이터를 삭제할 수도 있다. 일 실시형태에서, 다운로드되고 있는 엘리먼트가 스크래치 공간을 다 소모하는 것에 응답하여 삭제되도록 선택되면, 디바이스 상의 파일 전달 프레임워크는 그의 다운로드를 취소할 수도 있다.
여러 실시형태들에서, 파일 전달 프레임워크는 파일 전달 서비스들에 대한 요구를 충분히 지원하기 위해서, 다수의 파일 전달 데이터 흐름들을 이용할 수도 있다. 이것은, 다수의 멀티플렉스들 (예컨대, 와이드 멀티플렉스 및 로컬 멀티플렉스, 또는 다중-주파수 네트워크 배치에서 다수의 무선 주파수들 상의 하나 보다 많은 멀티플렉스) 이 있고, 멀티플렉스들 중 하나보다 많은 멀티플렉스가 하나 이상의 파일 전달 데이터 흐름들을 가질 때와 마찬가지일 수도 있다. 여러 실시형태들에서, 이들 멀티플렉스들은 모두 MediaFLO? 기술, 상이한 브로드캐스트 기술들 (예컨대, MediaFLO?, ISDB-T 등), 또는 브로드캐스트 기술들의 임의의 조합과 같은 동일한 브로드캐스트 기술을 이용할 수도 있다.
위에서 설명한 바와 같이, 파일 전달 프레임워크는 다수의 멀티플렉스들이 있을 때 다수의 파일 전달 데이터 흐름들을 이용할 수도 있다. 일 실시형태에서, 파일 전달 프레임워크는 또한 하나 보다 많은 데이터 흐름을 가진 단일 멀티플렉스가 있을 때 다수의 파일 전달 데이터 흐름들을 이용할 수도 있다. 예를 들어, 도 32 는 다수의 파일 전달 데이터 흐름들이 어떻게 파일 송신들을 운반하기 위해 2 개의 데이터 흐름들을 갖는 단일 멀티플렉스 상에서 이용될 수도 있는지를 도시하는 타임라인도이다. 구체적으로 설명하면, 도 32 는 제 1 데이터 흐름이 어떻게 규칙적인 파일 송신들을 운반하는데 제공되며 또 다른 데이터 흐름이 더 긴급한 파일 송신들을 운반하는데 제공되는지를 도시한다. 이 실시형태에서, 더 큰 더 낮은 우선순위 파일 (예컨대, 파일 1) 이 송신되고 있는 동안, 긴급한 파일 (예컨대, 파일 2) 이 송신을 위해 수신되면, 긴급한 파일 (즉, 파일 2) 이 다른 더 낮은 우선순위 파일 (즉, 파일 1) 의 송신의 종료를 대기하지 않고, 긴급한 데이터 흐름 상에서 송신될 수 있다. 이러한 방법으로, 파일 전달 프레임워크는 단일 멀티플렉스를 이용하는 동안에, 낮은 및 높은 우선순위 파일들을 도모할 뿐만 아니라, 늦게 도달하는 긴급한 파일들의 송신을 프롬프트할 수 있다.
여러 실시형태들에서, 파일 전달 프레임워크는 적어도 하나의 파일 전달 데이터 흐름을 갖는 각각의 멀티플렉스에 대한 브로드캐스트 스케쥴 흐름을 포함할 수도 있다. 도 33 에 도시된 바와 같이, 브로드캐스트 스케쥴 흐름 상에서 브로드캐스트된 브로드캐스트 스케쥴 메시지는 단지 각각의 멀티플렉스 상에서의 데이터 흐름들에 대한 브로드캐스트 스케쥴들을 기술할 수도 있다. 즉, 여러 실시형태들에서, 단지 멀티플렉스 당 하나의 브로드캐스트 스케쥴 메시지 (BSM) 가 있을 수도 있다. 따라서, 여러 실시형태들에서, 단일 브로드캐스트 스케쥴 메시지는 상이한 멀티플렉스들 상에서의 송신들을 위한 브로드캐스트 스케쥴 정보를 운반할 수도 있다. 도 33 은 이들 실시형태들에서, 상이한 멀티플렉스들 (WM1, WM2) 상에서, 또는 심지어, 상이한 브로드캐스트 네트워크들 상에서의, 브로드캐스트 스케쥴 흐름들 (BSF1, BSF2) 의 상이한 버전들 (버전 1, 버전 2) 이 어떻게 디렉토리 정보 메시지 (DIM) 내의 상이한 레코드들에 의해 시그널링될 수도 있는지를 도시한다. 수신기 디바이스들은 업데이트된 브로드캐스트 스케쥴 메시지들을 다른 브로드캐스트 스케쥴 흐름들 (예컨대, BSF2) 과는 독립적인 브로드캐스트 스케쥴 흐름 (예컨대, BSF1) 상에서 검출하여 수신할 수도 있다. 따라서, 도 33 에 도시된 바와 같이, 디렉토리 정보 메시지 (DIM) 는, 제 1 와이드 멀티플렉스 (예컨대, WM1) 가 제 1 버전 (예컨대, 버전 1) 의 제 1 브로드캐스트 스케쥴 흐름 (예컨대, BSF1) 을 포함하고 제 2 와이드 멀티플렉스 (예컨대, WM1) 가 제 2 버전 (예컨대, 버전 2) 의 제 2 브로드캐스트 스케쥴 흐름 (예컨대, BSF2) 을 포함한다고 특정할 수도 있다. 여러 실시형태들에서, 브로드캐스트 스케쥴 흐름들 (예컨대, BSF1, BSF2) 은 상이한 무선 주파수 네트워크들 (예컨대, RF1, RF2) 상에서 동시에 브로드캐스트될 수도 있다. 여러 실시형태들에서, 디렉토리 정보 메시지는 그들 네트워크들에서의 전송 스트림 식별자들 (예컨대, 브로드캐스트 스케쥴 흐름에 대한 흐름 ID) 이 브로드캐스트 스케쥴 메시지들을 운반하는데 사용되는 브로드캐스트 네트워크들에 관한 부트스트래핑 (bootstrapping) 정보를 제공하기 위해서 초기 획득 흐름 (IAF) 으로 운반되는 오버헤드 메시지일 수도 있다.
도 34 는 다중-주파수 네트워크 (MFN) 에서, 수신기 디바이스가 브로드캐스트 스케쥴 흐름에 대한 업데이트가 있다고 검출하지만 동시에 그 업데이트를 수신할 수 없다고 식별하는 것이 가능한지의 일 예를 도시한다. 도 34 에 도시된 예에서, 초기 획득 흐름 (예컨대, IAF) 은, 제 2 무선 주파수 네트워크 (예컨대, RF2) 상에서의 브로드캐스트 스케쥴 흐름 (예컨대, BSF2) 이 업데이트되는 것을 나타내고 있다. 그러나, 그 디바이스는 제 2 무선 주파수 네트워크 (예컨대, RF2) 로 스위칭될 수 없다. 이런 상황들에서, 파일 전달 프레임워크는 수신기 디바이스가 제 2 무선 주파수 네트워크 (예컨대, RF2) 상에서의 (BSF2 로 설명한 바와 같이) 파일 전달 데이터 흐름을 수신할 수 없기 때문에, 여분의 데이터 손실을 경험할 수도 있다. 일 실시형태에서, 수신기 디바이스는 업데이트의 존재를 검출하고 그 업데이트를 수신불가능으로 식별할 수도 있다. 일 실시형태에서, 수신기 디바이스가 그 업데이트를 수신불가능으로 식별할 때, 수신기 디바이스는 데이터 손실을 경감하기 위해서 복구 프로세스를 활성화할 수도 있다.
도 35 는 디바이스가 새로운 멀티플렉스로 이동할 때 디바이스가 새로운 멀티플렉스에 대한 브로드캐스트 스케쥴 메시지를 수신하도록 강제될 수도 있게, 수신기 디바이스들이 어떻게 구성될 수 있는지를 도시한다. 여러 실시형태들에서, 이 이동성 거동은 로컬 멀티플렉스들 (예컨대, LM1, LM2) 및 와이드 멀티플렉스들 (예컨대, WM1, WM2) 양자에 적용가능하도록 구현될 수도 있다.
도 36 은 동일한 무선 주파수 상에서 하나 보다 많은 멀티플렉스를 지원하는 파일 전달 프레임워크 구성을 도시한다. 즉, 여러 실시형태들에서, 상이한 멀티플렉스들이 반드시 상이한 무선 주파수들 상에 있어야 할 필요는 없다. 예를 들어, 제 1 무선 주파수 (예컨대, RF1) 는 로컬 멀티플렉스 (예컨대, LM_B) 및 와이드 멀티플렉스 (예컨대, WM1) 양자를 포함할 수도 있다. 파일 전달 코어가 동일한 무선 주파수 상에서 다수의 데이터 흐름들을 수신할 때, 흐름들의 전체 레이트는 겨우 디바이스 플랫폼 특정의 파라미터 (예컨대, FDF_MAX_FD_RECEIVE_RATE) 정도 이어야 한다. 파일 전달 프레임워크가 백그라운드에서 실행될 수도 있기 때문에, 전체 흐름 레이트에 대한 이 제한이 실시간 비디오 수신 및 디스플레이와 같은 전경 작업들에 대한 파일 전달 프레임워크의 영향을 감소시킬 수도 있다. 여러 실시형태들에서, 데이터 흐름 레이트들이 브로드캐스트 스케쥴 메시지들로 시그널링되거나 또는 특정될 수도 있다. 일 실시형태에서, 파일 전달 코어가 데이터 필터링 결정에 따라서 다수의 데이터 흐름들을 동시에 동일한 무선 주파수 상에서 수신하는 것을 필요로 하고 그 흐름들의 전체 레이트가 특정의 파라미터 (예컨대, FDF_MAX_FD_RECEIVE_RATE) 보다 크면, 파일 전달 코어는 선택한 (picked) 데이터 흐름들의 전체 레이트가 겨우 특정의 파라미터 (예컨대, FDF_MAX_FD_RECEIVE_RATE) 정도가 되도록 수신하기 위해서, 데이터 흐름들의 서브세트를 무작위로 선택할 수도 있다. 여러 실시형태들에서, 파일 전달 프레임워크는 그들의 무선 주파수 ID 들을 흐름 프로토콜 스택 (FPS) 으로부터 획득함으로써, 2 개의 상이한 멀티플렉스들 상에서의 2 개의 데이터 흐름들이 동일한 무선 주파수 상에 있는지 여부를 결정할 수도 있다.
도 37 은 파일 전달 코어가 파일 다운로드들을 상이한 무선 주파수들 상에서 독립적으로 스케쥴링하도록 구성되는 파일 전달 프레임워크 구성을 도시한다. 즉, 다중-주파수 네트워크 배치에서, 파일 전달 코어는 파일 전달 데이터 흐름들 (예컨대, 데이터 흐름 1 ~ 데이터 흐름 2) 을 무선 주파수 (예컨대, RF1) 상에서 수신하도록 스케쥴링하고, 다른 무선 주파수들 (예컨대, RF2) 의 존재와 상관없이, 그들을 흐름 프로토콜 스택 (예컨대, FPS) 에 등록할 수도 있다. 동시에 상이한 무선 주파수들 (예컨대, RF1, RF2) 상에서 브로드캐스트될 다수의 파일들 (예컨대, 파일들 1-4) 이 있으면, 파일 전달 코어는 비록 단지 하나의 무선 주파수를 수신할 수 있더라도 그들 모두를 수신하도록 스케쥴링할 수도 있다. 이 실시형태에서, 단지 흐름 프로토콜 스택이 디바이스가 처리하는데 필요로 하는 (파일 전달 서비스보다 더 높은 우선순위를 갖는 실시간 서비스들을 포함한) 서비스들 모두에 관한 정보를 소유하기 때문에, 어느 무선 주파수가 수신할 수 있는지를 결정하는 것은 흐름 프로토콜 스택에 달려있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크가 다수의 데이터 흐름들을 동시에 동일한 무선 주파수 상에서 수신하는 것을 필요로 하고 그 흐름들의 전체 데이터 레이트가 특정의 파라미터 (예컨대, FDF_MAX_FD_RECEIVE_RATE) 보다 클 때, 파일 전달 프레임워크는 선택한 데이터 흐름들의 전체 레이트가 겨우 특정의 파라미터 (예컨대, FDF_MAX_FD_RECEIVE_RATE) 정도가 되도록 수신하기 위해서, 데이터 흐름들의 서브세트를 무작위로 선택할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 다른 무선 주파수들의 존재에 상관없이, 파일 전달 데이터 흐름(들) 을 무선 주파수 상에서 수신하도록 스케쥴링할 수도 있다.
도 38 은 어떻게 파일 전달 파이프 (FDP) 페이로드 (즉, FDCP/FDP 서브-층에 의해 수행되는 FEC 디코딩의 결과) 가 2개의 부분들, 즉 파일 전달 코어 페이로드 (FDC 페이로드); 및 주기적 리던던시 체크 (CRC) 트레일러 (trailer) 를 포함할 수 있는지를 도시한다. 파일 전달 파이프 페이로드는 엘리먼트 및 파일 전달 코어 페이로드 트레일러를 포함할 수도 있다. 일 실시형태에서, 주기적 리던던시 체크 트레일러는 표준 CRC-CCITT 생성 다항식을 이용하여 발생되는 16-비트 체크섬 (checksum) 일 수도 있다. 여러 실시형태들에서, 파일 전달 코어는 주기적 리던던시 체크를 수신된 파일 전달 코어 페이로드 상에서 16 비트 주기적 리던던시 체크 체크섬 트레일러에 기초하여 수행할 수도 있다. 그 주기적 리던던시 체크가 성공적이면, 파일 전달 코어는 주기적 리던던시 체크 체크섬을 제거하고 파일 전달 코어 페이로드를 파일 전달 파일 관리 (FDM) 계층으로 전달할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 주기적 리던던시 체크를 그 수신된 파일 전달 코어 페이로드 상에서 그 페이로드 내의 16-비트 주기적 리던던시 체크 체크섬에 기초하여 수행하기 위해서, CRC-CCITT 생성 다항식을 이용할 수도 있다. 일 실시형태에서, 그 디바이스 상의 파일 전달 프레임워크는 수신된 파일 전달 코어 페이로드를, 그 페이로드 상에서의 체크섬이 실패하면, 폐기할 수도 있다. 여러 실시형태들에서, 애플리케이션이 나갈 때, 파일 전달 프레임워크는 애플리케이션에 할당된 리소스들을 해제할 수도 있다. 해제된 할당된 리소스들은 원하는 스트링 테이블에서의 엔트리들을 포함할 수도 있다.
위에서 설명한 바와 같이, 파일 전달 파일 관리 (FDM) 계층은 파일들로서 파일 전달 코어 (FDC) 에 의해 수신된 데이터를 관리하는 것을 담당할 수도 있다. 파일 전달 프레임워크에 의해 전달되는 각각의 파일은 UNIX 파일 명명 규약 (예컨대, 루트 디렉토리는 "/" 로 표현되며 디렉토리들 또는 파일 기본 이름들은 "/" 에 의해 구분된다) 을 따르는 하나 이상의 디바이스 플랫폼 독립적인 파일 이름들을 가질 수도 있다. 디바이스 상의 파일 전달 프레임워크에 의해 수신되는 각각의 파일은 또한 파일의 물리적인 스토리지 로케이션을 특정하는 스토리지 이름을 가질 수도 있다. 스토리지 이름들은 디바이스 플랫폼 의존적일 수도 있다. 예를 들어, 파일 이름 "/tad/f1.mp4" 을 가진 파일이 윈도우 모바일 (Window Mobile) 및 리눅스 (Linux) 기반의 디바이스들 상에, "c:\fdroot\tad\f1.mp4" 및 "/ext/fdroot/tad/f1.mp4" 에 각각 저장될 수도 있다. 여러 실시형태들에서, 파일 전달 프레임워크와 디바이스 애플리케이션들 사이의 통신이 디바이스 플랫폼 독립적인 파일 이름에 기초하고 디바이스 플랫폼 의존적인 스토리지 이름에 기초하지 않을 수도 있다는 점에 유의해야 한다.
파일 전달 프레임워크가 애플리케이션용 파일을 수신할 때, 애플리케이션의 스토리지 정책에 따라서 그의 파일 이름을 스토리지 이름에 자동적으로 맵핑하고, 그 파일을 그 스토리지 이름에 의해 지시되는 로케이션에 저장할 수도 있다. 애플리케이션의 스토리지 정책은 파일 전달 프레임워크가 그 애플리케이션용으로 수신하는 파일들을 저장하는데 사용할 수 있는 메모리 (내부 또는 외부) 의 유형을 특정할 수도 있다. 일 실시형태에서, 파일 전달 프레임워크에 등록할 때, 애플리케이션은 다음의 스토리지 정책들 중 하나를 특정할 수도 있다: 내부 메모리 전용; 먼저 내부 및 그 후 외부; 외부 메모리 전용; 및 먼저 외부 및 그 후 내부. 일 실시형태에서, 수신기 디바이스는 "내부 메모리 전용" 정책만을 지원하도록 구성될 수도 있다. 또다른 실시형태에서, 수신기 디바이스는 "내부 메모리 전용" 및 "외부 메모리 전용" 정책들만을 지원하도록 구성될 수도 있다. 또한, 다른 실시형태들에서, 수신기 디바이스들은 모든 스토리지 정책들, 또는 이들의 임의의 조합을 지원하도록 구성될 수도 있다.
도 39 는 일 실시형태에 따른, 예시적인 파일 명명 규약 및 스토리지 이름들에의 파일 이름들의 맵핑을 도시한다. 이 예에서, 파일 전달 프레임워크는 파일 이름을 스토리지 이름에 다음과 같이 맵핑한다: 파일 이름 내의 각각의 분리자 "/" 는 디바이스 플랫폼 의존적인 분리자 (예컨대, "\") 로 변환되고; 변환된 스트링은 애플리케이션의 스토리지 정책에 의해 선택되는 메모리 유형 (예컨대, 내부, 외부) 에 대응하는 물리적인 기본 디렉토리 (예컨대, C:, D:) 다음에 첨부된다. 일 실시형태에서, 애플리케이션은 물리적인 기본 디렉토리들을 등록 단계 동안 제공할 수도 있다. 일 실시형태에서, 애플리케이션이 먼저 파일 전달 프레임워크에 의해 수신되는 파일에 액세스하기 전에, 애플리케이션은 파일 전달 프레임워크에 그의 파일 이름을 스토리지 이름에 맵핑할 것을 요청한 후, 그 스토리지 이름을 그 파일에 액세스하는데 이용할 수도 있다.
도 40 은 예시적인 관리된 엘리먼트 테이블 (MET) 을 도시한다. 위에서 설명한 바와 같이, 각각의 애플리케이션의 파일 전달 파일 관리 (FDM) 계층은 파일 전달 프레임워크가 애플리케이션용으로 수신하였고 여전히 그 디바이스 상에 존재하는 모든 엘리먼트들 (파일 또는 파일 번들) 에 관한 정보를 갖는 관리된 엘리먼트 테이블을 유지할 수도 있다. 관리된 엘리먼트 테이블은 엘리먼트 ID 들 (EID), 파일 이름들 (Name), 스토리지 이름들 (Storage), 참조 번호들 (Ref) 및 다른 속성들 (Attr) 과 같은, 여러 정보 피스들을 포함할 수도 있다. 일 실시형태에서, 파일 전달 프레임워크는 파일 이름 "/" 내의 루트 디렉토리를 스토리지 정책에 따라서 선택되는 물리적인 메모리의 루트에서의 "fdroot" 에 맵핑하고, 루트 디렉토리 "/" 뒤의 파일 이름의 나머지에서의 각각의 분리자 "/" 를 디바이스 플랫폼 의존적인 분리자로 변환하고, 그 변환된 스트링을 "fdroot/" 뒤에 첨부함으로써, 파일 이름을 스토리지 이름에 맵핑할 수도 있다.
일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 그 파일 이름 내의 각각의 분리자 "/" 를 디바이스 플랫폼 의존적인 분리자로 변환한 후 그 변환된 스트링을 애플리케이션의 스토리지 정책에 의해 선택되는 메모리 유형에 대응하는 물리적인 기본 디렉토리 뒤에 첨부함으로써, 파일 이름을 스토리지 이름에 맵핑할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 애플리케이션들에 대해 "내부 메모리 전용" 스토리지 정책을 지원할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 애플리케이션들에 대해 "외부 메모리 전용" 스토리지 정책을 지원할 수도 있다.
여러 실시형태들에서, 애플리케이션이 파일 전달 프레임워크에 등록될 때, 다음을 특정할 수도 있다: 애플리케이션의 스토리지 정책; 애플리케이션의 물리적인 기본 디렉토리들, 여기서 파일 전달 프레임워크는 그 애플리케이션용으로 수신되는 모든 파일들을 저장할 수도 있다; 및 애플리케이션의 스토리지 할당량. 여러 실시형태들에서, 다수의 기본 디렉토리들, 즉 각각의 메모리 유형 마다 하나의 기본 디렉토리가 있을 수도 있다. 이들 실시형태들에서, 파일 전달 프레임워크는 애플리케이션의 스토리지 정책을 이용하여, 어느 기본 디렉토리가 사용되어야 하는지를 결정할 수도 있다. 일 실시형태에서, 등록은 파일 전달 파일 관리 계층에 의해 처리될 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 스토리지 정책, 물리적인 기본 디렉토리들, 및 스토리지 할당량에 따른 애플리케이션 등록을 지원할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 등록 동안에 특정되는 애플리케이션의 스토리지 공간에 대한 할당량을 강제할 수도 있다.
도 41 은 파일 전달 파일 관리 (FDM) 계층이 애플리케이션의 스토리지 공간을 관리하고 상호작용하도록 구성될 수도 있는 일 실시형태 방법 (4100) 을 도시한다. 단계 (4102) 에서, 파일 전달 파일 관리 계층은 파일 전달 프레임워크 (FDF) 에의 애플리케이션의 등록을 처리하고 애플리케이션이 등록 동안 그 스토리지 정책을 특정하는 것을 허용할 수도 있다. 단계 (4104) 에서, 파일 전달 파일 관리 계층은 수신되는 파일들에 대한 애플리케이션 스토리지 공간이 있는지 여부를 체크할 수도 있다. 단계 (4106) 에서, 파일 전달 파일 관리 계층은 애플리케이션의 스토리지 정책에 따라서 그 수신된 파일들을 애플리케이션 스토리지 공간에 저장할 수도 있다. 단계 (4108) 에서, 파일 전달 파일 관리 계층은 애플리케이션의 요청에 따라서 애플리케이션의 스토리지 공간에 저장된 파일들을 삭제할 수도 있다.
도 42 는 수신되는 엘리먼트에 대한 애플리케이션의 스토리지 공간을 체크하는 파일 전달 프레임워크 (FDF) 에 구현될 수도 있는 일 실시형태 방법 (4200) 을 도시한다. 단계 (4201) 에서, 파일 전달 프레임워크는 엘리먼트 사이즈 정보를 FDP/FDCP 메시지로부터 획득하여, 그 엘리먼트에 대한 애플리케이션의 스토리지 공간에 충분한 공간이 있는지 여부를 결정할 수도 있다. 단계 (4202) 에서, 파일 전달 프레임워크는 수신되는 엘리먼트를 저장할 충분한 애플리케이션 스토리지 공간이 없는 경우에는, 그 애플리케이션에, 통지할 수도 있다. 단계 (4203) 에서, 파일 전달 프레임워크는 다운로드가 애플리케이션에 의해 취소되지 않는 한, 그 엘리먼트를 계속 수신할 수도 있다.
도 43 은 브로드캐스트 스케쥴 레코드에서의 속성 스트링들에 매칭하는 수신되는 엘리먼트 (예컨대, 파일 또는 파일 번들) 에 대해 충분한 공간을 애플리케이션의 스토리지가 갖고 있는지 여부를 결정하는 위에서 설명한 방법 (4200) 에서 구현될 수도 있는 파일 전달 프레임워크 (FDF) 와 애플리케이션 계층 (App 계층) 사이의 데이터흐름 및 호출 흐름 상호작용들을 도시한다. 동작 (4301) 에서, 파일 전달 프레임워크는 엘리먼트 사이즈 정보를 FDP/FDCP 메시지로부터 획득하고, 그 엘리먼트를 수신하여 저장하기 위해 애플리케이션의 스토리지 공간에 충분한 공간이 없는지 여부를 결정할 수도 있다. 호출 흐름 (4302) 에서, 파일 전달 프레임워크는 수신되는 엘리먼트에 대해 n 개의 불충분한 애플리케이션 스토리지 공간이 있을 경우에, 그 애플리케이션에 통지한다. 동작 (4303) 에서, 파일 전달 프레임워크는 애플리케이션이 일부 데이터를 그의 스토리지 공간으로부터 삭제하기를 대기하고 그 엘리먼트를 계속 수신할 수도 있다. 호출 흐름 (4304) 에서, 애플리케이션은 취소 통지를 파일 전달 프레임워크에 발하여, 엘리먼트를 수신하는 것을 중지할 것을 명령할 수도 있다.
도 44 는 대응하는 애플리케이션의 스토리지 공간으로의 수신된 파일의 이동을 위해서 파일 전달 프레임워크에서 구현될 수도 있는 일 실시형태 방법 (4400) 을 도시한다. 단계 (4402) 에서, 파일 전달 코어는 파일에 대응하는 파일 전달 코어 페이로드를 성공적으로 수신한다. 단계 (4404) 에서, 파일 전달 코어는 파일 전달 파일 관리 계층에, 파일 전달 코어 페이로드가 수신되었다는 것을 통지하고 파일 전달 파일 관리 계층에 대한 스크래치 공간에 그의 스토리지 로케이션을 전달할 수도 있다. 단계 (4406) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어 페이로드 내의 트레일러를 프로세싱하여, 그 전달된 파일 전달 코어 페이로드에서의 엘리먼트가 단일 파일에 대응하는지 여부를 결정할 수도 있다. 파일 전달 파일 관리 계층은 그 파일의 이름을 스토리지 이름 (예컨대, PI) 에 맵핑할 수도 있다. 일 실시형태에서, 파일이 다수의 이름들을 가지면, 파일 전달 파일 관리 계층은 단지 제 1 이름 (first name) 을 스토리지 이름에 맵핑할 수도 있다. 단계 (4408) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어 페이로드에 대한 충분한 애플리케이션 스토리지 공간이 있는지 여부를 결정할 수도 있으며, 그 페이로드를 스크래치 공간 메모리로부터 스토리지 이름 (예컨대, P1) 에 의해 식별되는 애플리케이션 스토리지 공간 로케이션으로 이동시킬 수도 있다. 일 실시형태에서, 파일 이름들 중 하나가 관리된 엘리먼트 테이블 (MET) 에 이미 존재하면, 파일 전달 코어 페이로드에 대한 여분의 메모리가 충분한 애플리케이션 스토리지 공간이 있는지 여부를 결정하는데 사용될 수도 있다. 일 실시형태에서, 이 여분의 메모리는 FDC_payload_size 와 old_file_size 사이의 차이와 같은, 2개의 변수들의 값 사이의 차이를 나타내는 로케이션으로서 정의될 수도 있다. 단계 (4410) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어에게 파일들의 이동이 완료되었다는 것을 통지할 수도 있다. 단계 (4412) 에서, 파일 전달 파일 관리 계층은 트레일러를 저장된 파일 전달 코어 페이로드 (예컨대, P1 에 저장된 페이로드) 로부터 제거하고, 그 파일에 대한 엔트리를 관리된 엘리먼트 테이블 (예컨대, 도 40 참조) 에 추가할 수도 있다. 일 실시형태에서, 파일이 다수의 파일 이름들을 갖고 있다고 파일 전달 코어 페이로드에서의 트레일러가 나타내면, 파일 전달 파일 관리 계층은 그 정보를 파일 이름들의 모두를 그 명명된 스토리지 로케이션 (예컨대, P1) 에 맵핑하는 관리된 엘리먼트 테이블에 추가할 수도 있다. 단계 (4414) 에서, 파일 전달 파일 관리 계층은 애플리케이션에게 파일이 캡쳐되었다는 것을 통지할 수도 있다.
도 45 는 방법 (4400) 에서 일어날 수도 있는, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 데이터 흐름들 및 상호작용들이 파일 전달 프레임워크 (FDF) 가 그 수신된 파일을 애플리케이션 스토리지 공간으로 이동시키는 것을 성공하는 것을 도시한다. 동작 (4501) 에서, 파일 전달 코어는 파일 전달 코어 페이로드를 수신한다. 호출 흐름 (4502) 에서, 파일 전달 코어는 파일 전달 파일 관리 계층에게 파일 전달 코어 페이로드가 수신되었다는 것을 통지한다. 동작 (4503) 에서, 파일 전달 파일 관리 계층은 그 파일 이름을 스토리지 이름 (예컨대, P1) 에 맵핑한다. 동작 (4504) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어 페이로드를 스크래치 공간으로부터, 충분한 스토리지 공간이 있으면, 스토리지 로케이션 (예컨대, P1) 으로 이동시킨다. 호출 흐름 (4505) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어에게 파일 전달 코어 페이로드의 이동이 완료되었다는 것을 통지한다. 동작 (4506) 에서, 파일 전달 파일 관리 계층은 트레일러를 스토리지 로케이션 (예컨대, P1) 에 저장되는 파일 전달 코어 페이로드로부터 제거한다. 호출 흐름 (4507) 에서, 파일 전달 파일 관리 계층은 애플리케이션 계층에게 캡쳐가 완료되었다는 것을 통지한다.
일 실시형태에서, 그 수신된 파일이 디바이스 상에 이미 존재하는 파일의 구 버전을 대체하기로 결정되고, 그 대체가 실패하면 (예컨대, 구 버전이 도 45 의 제 5 단계 (4505) 에서 잠겨 있으면), 호출 흐름 (4507) 에서, 파일 전달 코어는 에러 메시지를 파일 전달 파일 관리 계층에 전달할 수도 있다. 이 에러 메시지를 수신한 후, 파일 전달 파일 관리 계층은, "이동 완료 (move complete)" 메시지를 파일 전달 코어로부터 수신할 때까지, 또는 호출 흐름 (4505) 에서 그 요청을 미리 결정된 횟수 (예컨대, FDF_MAX_FILE_REPLACE_RETRY_NUM) 만큼 반복할 때까지, 호출 흐름 (4505) 에서 그 요청을 주기적으로 재시도할 수도 있다. 일 실시형태에서, 재시도 기간 (또는, 횟수) 은 수 초와 같이, 디바이스 파라미터 (예컨대, FDF_FILE_REPLACE_RETRY_PERIOD) 에 의해 정의될 수도 있다. 모든 시도들이 실패하면, 파일 전달 프레임워크는 그 데이터를 스크래치 공간으로부터 애플리케이션 스토리지 공간으로 이동시키는 것을 포기할 수도 있다.
일 실시형태에서, 디바이스 파라미터 (예컨대, FDF_MAX_ELEMENT_TIME_IN_SCRATCH_SPACE) 에 의해 표시되는, 미리 정의된 수보다 많은 초 동안, 스크래치 공간에 있었던 완료된 다운로드들이, 주기적 클린업 메커니즘으로 삭제될 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크가 수신된 파일을 애플리케이션 스토리지 공간으로 이동시키는 것을 실패하면, 이동이 성공적일 때까지 또는 미리 정의된 최대 수의 재시도들이 시도될 때까지, 수 초마다 그 파일을 이동하는 것을 계속 재시도할 수도 있다. 그 후, 주기적 클린업 메커니즘은 미이동된 파일을 스크래치 공간으로부터 적당한 시간에 삭제할 수도 있다.
도 46 은 다수의 파일 이름들이 어떻게 단일 스토리지 이름에 맵핑되어질 수도 있는지를 도시하는 소프트웨어 아키텍처 및 데이터 구조도이다. 구체적으로 설명하면, 도 46 은 다수의 파일 이름들 (예컨대, /mpv/cnn/f1.mp4, /mpv/cnnhl/f1.mp4) 이 관리된 엘리먼트 테이블 (MET) 의 동일한 스토리지 이름 (예컨대, D:\fdroot\cnn\f1.mp4) 에 맵핑되어지는 일 실시형태를 도시한다. 파일이 수신되면 (호출 흐름 4602), 재명명될 수도 있으며, 파일 이름 및 스토리지 로케이션이 관리된 엘리먼트 테이블에 저장될 수도 있다 (호출 흐름 4603). 이 도면은 또한 다수의 파일 이름들이 어떻게 그 관리된 엘리먼트 테이블에서 식별되는 단일 스토리지 이름에 맵핑될 수도 있는지를 도시한다.
도 47 은 수신된 파일을 저장하기 위해 불충분한 애플리케이션 스토리지 공간이 있는 상황들을 처리하는, 파일 전달 프레임워크에서 구현될 수도 있는 일 실시형태 방법 (4700) 을 도시한다. 위에서 설명한 바와 같이, 파일 전달 코어 페이로드에 대한 불충분한 애플리케이션 스토리지 공간이 있다고, 또는 애플리케이션 스토리지 공간이 가득차 있다고 파일 전달 파일 관리 (FDM) 계층이 결정하면, 단계 (4702) 에서 전달 파일 관리 계층은 애플리케이션이 공간을 해방할 것을 요청하는 요청을 애플리케이션 계층으로 발할 수도 있다. 이 메시지에 응답하여, 단계 (4704) 에서 애플리케이션은 일부 파일들을 삭제할 수도 있다. 단계 (4706) 에서, 애플리케이션은 파일 전달 프레임워크에게 일부 스토리지 공간이 파일 삭제들을 통해서 해방되었다는 것을 통지할 수도 있다. 단계 (4708) 에서, 파일 전달 프레임워크는 수신된 파일을 스크래치 공간으로부터 애플리케이션 스토리지 공간으로 이동시킬 수도 있다. 단계 (4710) 에서, 파일 전달 파일 관리 계층은 애플리케이션에게 파일이 캡쳐되었다는 것을 통지할 수도 있다. 파일 전달 프레임워크가 스토리지 공간이 해방되었다는 통지를 애플리케이션으로부터 전혀 수신하지 않으면, 그 수신된 파일은 스크래치 공간에 스크래치 공간 주기적 클린업 메커니즘에 의해 삭제될 때까지 유지될 수도 있다.
도 48 은 방법 (4700) 의 실행에서 애플리케이션 계층 (App 계층) 과 파일 전달 프레임워크 (FDF) 사이의 데이터흐름 및 호출 흐름 상호작용들을 도시한다. 호출 흐름 (4801) 에서, 파일 전달 프레임워크는 애플리케이션 계층에, 파일 전달 코어 페이로드에 대한 불충분한 애플리케이션 스토리지 공간이 있다는 것을 애플리케이션에게 통지하는 통지를 전송한다. 호출 흐름 (4802) 에서, 애플리케이션 계층은 파일 전달 네트워크에, 그 파일들의 일부를 애플리케이션 스토리지 공간으로부터 직접 삭제하라는 명령을 전송한다. 호출 흐름 (4803) 에서, 애플리케이션 계층은 파일 전달 프레임워크로, (예컨대, 파일을 삭제함으로써) 스토리지 공간이 이용가능하게 되었다는 것을 나타내는 통지를 전송한다. 동작 (4804) 에서, 파일 전달 프레임워크는 그 파일을 스크래치 공간으로부터 애플리케이션 스토리지 공간으로 이동시킨다. 호출 흐름 (4805) 에서, 파일 전달 프레임워크는 애플리케이션 계층에, 파일 캡쳐가 완료되었다는 것을 통지한다.
도 49 는 파일 전달 프레임워크가 파일을 삭제하라는 애플리케이션 요청에 응답하여, 그 파일들을 애플리케이션 스토리지 공간으로부터 삭제하기 위해, 파일 전달 프레임워크에 의해 구현될 수도 있는 예시적인 방법 (4900) 을 도시한다. 파일 이름에 의해 식별되는 파일을 삭제하라는 애플리케이션으로부터의 요청에 응답하여, 단계 (4902) 에서, 파일 전달 프레임워크는 그 파일 이름에 대응하는 관리된 엘리먼트 테이블 (MET) 내의 엔트리를 탐색하여 발견할 수도 있다. 결정 단계 (4903) 에서, 파일 전달 프레임워크는 관리된 엘리먼트 테이블로부터, 그 파일이 하나 보다 많은 파일 이름을 갖고 있는지 여부를 결정할 수도 있다. 그 엔트리가 하나 보다 많은 파일 이름을 갖고 있으면 (즉, 결정 단계 4903 = "예"), 단계 (4904) 에서, 파일 전달 프레임워크는 그 파일 이름을 엔트리로부터 간단히 제거하고 프로세스를 종료할 수도 있다. 따라서, 일 실시형태에서, 삭제로 지정되는 파일이 다수의 파일 이름들을 갖고 있으면, 파일 전달 프레임워크는 그 파일을 삭제하지 않고 파일 이름을 제거할 수도 있다. 삭제로 식별되는 파일과 연관되는 단지 하나의 파일 이름만이 있다고 파일 전달 프레임워크가 결정하면 (즉, 결정 단계 4903 = "아니오"), 단계 (4906) 에서, 파일 전달 프레임워크는 스토리지 로케이션에서 파일을 삭제하고 그 엔트리를 관리된 엘리먼트 테이블로부터 제거할 수도 있다. 결정 단계 (4908) 에서, 파일 전달 프레임워크는 파일 삭제가 성공적이었는지 여부를 결정할 수도 있다. 그 삭제가 성공적이었으면 (즉, 결정 단계 4908 = "예"), 그 절차는 종료될 수도 있다. 삭제가 성공적이지 않았으면 (즉, 결정 단계 4908 = "아니오"), 단계 (4910) 에서, 파일 전달 프레임워크는 에러를 애플리케이션에 반환하고, 삭제 요청을 재시도함이 없이 그 절차를 종료할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 애플리케이션이 파일 이름들에 의해 특정되는 파일들의 삭제를 요청할 수도 있는 인터페이스를 제공할 수도 있다.
위에서 설명한 바와 같이, 파일 전달 프레임워크는 다수의 파일들을 함께 번들하고 그 파일 번들을 단일 엘리먼트로서 브로드캐스트하는 것을 지원할 수도 있다. 앞에서 언급한 바와 같이, 이것은 순방향 에러 정정 (FEC) 오버헤드를 감소시키고 (즉, 엘리먼트가 더 클 수록, 더 적은 FEC 오버헤드가 요구된다), 전달 신뢰성을 향상시키는 (즉, 엘리먼트가 더 클 수록, 시간 다이버시티가 더 많다) 것을 돕는다. 파일 번들링은 특히 다수의 작은 파일들을 전달하는데 유용하다. 여러 실시형태들에서, 파일 번들링 피쳐는 파일 전달 코어에 아주 작은 영향을 미치는 파일 전달 파일 관리 계층 피쳐로서 구현될 수도 있다. 여러 실시형태들에서, 파일 번들링 피쳐는 애플리케이션들에 명료한 (transparent) 피쳐를 부여하는 방식으로 구현될 수도 있다.
도 50 은 파일 전달 프레임워크 내에서 파일 번들링 피쳐로서 구현될 수도 있는 예시적인 방법 (5000) 을 도시한다. 단계 (5002) 에서, 파일 전달 코어는 파일 번들에 대한 브로드캐스트 스케쥴 레코드 (BSR) 가 임의의 애플리케이션 요청에 매칭하는지 여부를 결정하기 위해서, 양방향-프리픽스-매칭 방식을 이용할 수도 있다. 일 실시형태에서, 이것은 도 25 및 도 26 을 참조하여 위에서 설명한 바와 같이, 개개의 파일들 상에서 이용되는 동일한 양방향-프리픽스-매칭 방식일 수도 있다. 결정 단계 (5004) 에서, 파일 전달 코어는 양방향-프리픽스-매칭이 있는지 여부를 결정할 수도 있다. 매칭이 없으면 (즉, 결정 단계 5004 = "아니오"), 파일 전달 코어는 파일 번들을 무시할 수도 있다. 매칭이 있으면 (즉, 결정 단계 5004 = "예"), 단계 (5006) 에서, 파일 전달 코어는 선택 스트링을 파일 전달 파일 관리 계층에 전달할 수도 있다. 이 선택 스트링은 애플리케이션이 수신하는데 관계된다고 파일 번들 내의 파일들을 특정할 수도 있다. 단계 (5008) 에서, 파일 전달 코어는 파일 전달 파일 관리 계층에, 파일 번들이 수신되어야 할지 아닌지 여부를 결정하도록 요청하는 메시지를 전송할 수도 있다. 일 실시형태에서, 단계 (5008) 에서 선택 스트링은 파일 전달 파일 관리 계층에 이 요청의 부분으로서 전달될 수도 있다. 일 실시형태에서, 단계 (5006) 및 단계 (5008) 는 그 선택 스트링을 파일 번들이 수신되어야 하는지 여부를 결정하는 요청의 부분으로서 전달하는 하나의 유닛/함수 (function) 호출로 결합될 수도 있다.
결정 단계 (5010) 에서, 파일 전달 파일 관리 계층은, 파일 번들이 파일 전달 파일 관리 계층에 의해 수신될 수 있는지 여부 뿐만 아니라, 파일 번들이 수신될 필요가 있는지 여부를 결정할 수도 있다. 그 파일 번들이 수신될 필요가 없다고 파일 전달 파일 관리 계층이 결정하면 (즉, 결정 단계 5010 = "아니오"), 파일 번들은 무시될 수도 있다. 그 파일 번들이 파일 전달 파일 관리 계층에 의해 수신되는 것이 필요하면 (즉, 결정 단계 5010 = "예"), 단계 (5012) 에서, 파일 전달 파일 관리 계층은 파일 번들에 대응하는 엘리먼트에 대해 엘리먼트 ID 및 선택 스트링을 유지할 수도 있다. 단계 (5014) 에서, 파일 전달 코어는 파일 번들에 대응하는 파일 전달 코어 페이로드를 수신하여, 파일 전달 파일 관리 계층으로 전달할 수도 있다. 단계 (5016) 에서, 파일 전달 코어는 파일 전달 코어 페이로드를 파일 전달 파일 관리 계층에 전달할 수도 있다. 단계 (5018) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어 페이로드 트레일러를 프로세싱하여, 그 파일 전달 코어 페이로드가 파일 번들인지 여부를 결정할 수도 있다. 단계 (5020) 에서, 파일 전달 파일 관리 계층은 저장되어야 하는 파일 번들 내의 파일들을 식별하기 위해 파일 번들용으로 저장한 선택 스트링을 이용할 수도 있다.
도 51 은 방법 (5000) 의 동작들을 구현할 때에 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 데이터 흐름들 및 상호작용 호출 흐름들을 도시한다. 동작 (5101) 에서, 파일 번들 브로드캐스트 스케쥴 레코드 (BSR) 가 브로드캐스트 스케쥴 레코드 매칭 엔트리를 발생하기 위해서 파일 전달 코어에 의해 수신되어, 양방향-프리픽스-매칭된다. 호출 흐름 (5102) 에서, 파일 전달 코어는 선택 스트링, 엘리먼트 id 및 엘리먼트 유형을 그 파일이 이미 존재하는지 여부, 및 그 파일 번들이 파일 전달 파일 관리 계층에 의해 수신되어야 하는지 여부를 체크하는 파일 전달 파일 관리 계층으로 전달된다. 동작 (5103) 에서, 파일 번들에 대응하는, 엘리먼트, 또는 파일 전달 코어 페이로드가 파일 전달 코어에 의해 수신되어, 파일 전달 파일 관리 계층으로 전달된다. 동작 (5104) 에서, 파일 전달 파일 관리 계층은, 특정의 파일들을 수신된 파일 번들 중에서 선택하고 그 선택된 파일들을 메모리에 저장하기 위해서, 파일 전달 코어 페이로드를 프로세싱한다.
도 52 는 저장을 위한 수신된 파일 번들에서 파일들을 선택하기 위해서 파일 전달 파일 관리 계층에 의해 이용될 선택 스트링을 발생하는데 사용될 수도 있는 예시적인 방법 (5200) 을 도시한다. 단계 (5202) 에서, 파일 전달 코어는 브로드캐스트 스케쥴 레코드에서의 스트링이 원하는 스트링 (즉, 수신을 위한 파일들을 선택하기 위해 애플리케이션에 의해 식별되는 스트링) 에 양방향-토큰-프리픽스-매칭하는지 여부를 결정할 수도 있다. 그렇다면, 단계 (5204) 에서, 파일 전달 코어는 가장 긴 스트링을 그의 선택 스트링으로서 설정하고, 그 선택 스트링을 파일 전달 파일 관리 계층으로 전달할 수도 있다. 단계 (5206) 에서, 파일 전달 파일 관리 계층은 그 파일이 이미 존재하는지 여부를 체크할 수도 있다. 단계 (5208) 에서, 파일 전달 파일 관리 계층은 그 파일 번들이 파일 전달 파일 관리 계층에 의해 수신되어야 하는지 여부를 결정한다. 그 파일 번들이 수신되어야 한다고 파일 전달 파일 관리 계층이 결정하면, 단계 (5210) 에서, 파일 전달 파일 관리 계층은 그 파일 번들에 대응하는 엘리먼트에 대해 선택 스트링을 유지한다.
도 53 은 방법 (5200) 에서 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 데이터 흐름들 및 상호작용 호출 흐름들의 일 예를 도시한다. 위에서 설명한 바와 같이, 선택 스트링은 저장될 파일 번들에서 파일들을 선택하기 위해서 파일 전달 파일 관리 계층에 의해 이용될 수도 있다. 브로드캐스트 스케쥴 레코드 상의 스트링이 원하는 스트링에 양방향-토큰-프리픽스-매칭하면, 파일 전달 코어는 이들 2 개의 가장 긴 스트링을 선택 스트링으로서 이용하여, 파일 전달 파일 관리 계층으로 전달할 수도 있다. 도 53 의 도시된 예에서, 동작 (5301) 에서, (스트링 "/itv/cnn/" 을 갖는) 파일 번들 브로드캐스트 스케쥴 레코드가 파일 전달 코어에 의해 수신되어, 원하는 스트링 "/itv/cnn/e1/" 에 양방향-프리픽스-매칭된다. 동작 (5302) 에서, 파일 전달 코어는 선택 스트링 "/itv/cnn/e1/" 을 발생하고, 선택 스트링, 엘리먼트 id 및 엘리먼트 유형을 그 파일이 이미 존재하고 있는지 여부 및 파일 번들이 파일 전달 파일 관리 계층에 의해 수신되어야 하는지 여부를 결정할 때에 사용되는 파일 전달 파일 관리 계층으로 전달한다. 파일 번들이 파일 전달 파일 관리 계층에 의해 수신될 수 있고 수신될 필요가 있다고 파일 전달 파일 관리 계층이 결정하면, 동작 (5303) 에서, 파일 전달 파일 관리 계층은 파일 번들에 대응하는 엘리먼트에 대해 선택 스트링 "/itv/cnn/e1" 을 유지한다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 파일 번들 브로드캐스트 스케쥴 레코드에서의 속성 스트링이 원하는 스트링의 프리픽스인 것으로 결정하면, 그 파일 번들에 대해 원하는 스트링을 선택 스트링으로서 이용한다.
도 54 는 예시적인 방법 (5400) 이 파일 번들이 수신되어야 하는지 여부를 결정하는데 사용될 수도 있다는 것을 도시한다. 단계 (5402) 에서, 파일 전달 코어는 파일 번들 정보 및 선택 스트링을 포함한, 파일 번들이 수신되어야 하는지 여부를 파일 전달 파일 관리 계층이 표시할 것을 요청하는 요청을, 파일 전달 파일 관리 (FDM) 계층에 전송할 수도 있다. 결정 단계 (5404) 에서, 파일 전달 파일 관리 계층은 파일 번들에 대응하는 엘리먼트에 대한 엔트리가 관리된 엘리먼트 테이블에 있는지 여부를 결정할 수도 있다. 이런 엔트리가 존재하지 않으면 (즉, 결정 단계 5404 = "아니오"), 단계 (5406) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어에게 그 파일 번들이 수신되어야 한다고, 표시할 수도 있다. 그 엔트리가 관리된 엘리먼트 테이블에 존재하고 있으면 (즉, 결정 단계 5404 = "예"), 결정 단계 (5408) 에서, 파일 전달 파일 관리 계층은 그 엔트리와 연관되는 임의의 기존 선택 스트링의 프리픽스가 관리된 엘리먼트 테이블에 없는 파일 전달 코어 요청에서 적어도 하나의 선택 스트링이 있는지 여부를 결정할 수도 있다. 있으면 (즉, 결정 단계 5408 = "예"), 단계 (5406) 에서 파일 전달 파일 관리 계층은 파일 전달 코어에게 파일 번들이 수신되어야 한다고 표시할 수도 있다. 그렇지 않으면 (즉, 결정 단계 5408 = "아니오"), 단계 (5410) 에서 파일 전달 파일 관리 계층은 파일 전달 코어에게, 그 파일이 수신되지 않아야 한다고 표시할 수도 있다.
도 55 는 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터 흐름들 및 상호작용 호출 흐름들이 방법 (5400) 에서 일어날 수도 있다는 것을 도시한다. 동작 (5501) 에서, 스트링 "/itv/cnn/" 을 갖는 파일 번들 브로드캐스트 스케쥴 레코드 (BSR) 는 파일 전달 코어에 의해 수신되어, 원하는 스트링 "/itv/cnn/e1/" 에 양방향-프리픽스-매칭될 수도 있다. 호출 흐름 (5502) 에서, 파일 전달 코어는 선택 스트링 "/itv/cnn/e1/" 을 발생하고, 그 선택 스트링, 엘리먼트 id 및 엘리먼트 유형을, 그 파일이 이미 존재하는지 여부 및 파일 번들이 파일 전달 파일 관리 계층에 의해 수신되어야 하는지 여부를 결정하기 위해 이 스트링을 이용할 수도 있는 파일 전달 파일 관리 계층으로 전달할 수도 있다. 즉, 호출 흐름 (5502) 에서, 파일 전달 코어는 파일 전달 파일 관리 계층에, 파일 번들이 수신되어야 하는지 여부에 관한 결정에 대한 요청을 전송한다. 동작 (5503) 에서, 파일 전달 파일 관리 계층은 그 파일을 수신할지 여부를 결정한다. 파일 번들에 대응하는 엘리먼트에 대한 어떤 엔트리도 관리된 엘리먼트 테이블 (MET) 에 없으면, 파일 전달 파일 관리 계층은 이 결정을 행하여 그 파일을 수신할 수도 있다.
그 파일 번들에 대한 엔트리가 관리된 엘리먼트 테이블에 존재한다고 파일 전달 파일 관리 계층이 결정하면, 파일 전달 파일 관리 계층은 선택 스트링들 중 적어도 하나가 엔트리에서 임의의 기존 선택 스트링의 프리픽스가 아니면 그 파일을 수신하도록 여전히 선택할 수도 있다. 이것은 도 55 에 도시되어 있으며, 여기서 디바이스의 파일 전달 파일 관리 계층은 /itv/cnn/e1 아래에 파일들을 이미 갖고 있다. 이것은 관리된 엘리먼트 테이블의 제 2 로우 (EID =1988) 의 선택 스트링들 (Selection Strings) 컬럼에 선택 스트링 값 "/itv/cnn/e1/" 으로 표시된다. 애플리케이션이 /itv/cnn/ 아래의 모든 파일들을 수신하라는 새로운 요청을 발하였고 스트링 "/itv/cnn" 이 스트링 "/itv/cnn/e1" 보다 더 넓기 때문에, 디바이스는 전체 파일 번들을 다시 다운로드하는 것을 필요로 한다. 따라서, 호출 흐름 (5504) 에서, 파일 전달 파일 관리 계층은 디바이스가 파일 번들을 다시 다운로드할 수 있도록, 파일 전달 코어가 파일 번들을 수신할 것을 요청할 수도 있다. 따라서, 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는, 브로드캐스트 스케쥴 레코드가 원하는 (wanted) 스트링에 양방향-토큰-프리픽스-매칭하는 적어도 하나의 속성 스트링을 가지며, 파일 번들이 그 디바이스 상에 존재하고, 선택 스트링들 중 하나가 (브로드캐스트 스케쥴 레코드로부터 결정될 때에) 브로드캐스트될 것이며; 그리고 그 원하는 스트링들이 기존 파일 번들과 연관되는 임의의 기존 선택 스트링들의 토큰-프리픽스가 아니면, 브로드캐스트 스케쥴 레코드에 의해 기술되는 파일 번들 엘리먼트를 수신하도록 스케쥴링할 수도 있다.
도 56 은 파일 번들들에서의 파일들이 어떻게 파일 이름 프리픽스들에 기초하여 선택되어 저장될 수 있는지를 도시한다. 위에서 설명한 바와 같이, 파일 전달 파일 관리 계층은 애플리케이션들에 의해 요청되는 file/dir 이름들 중 하나가 파일의 이름의 프리픽스이면, 그 파일 번들에 파일을 저장할 수도 있다. 이것은 도 56 에 도시되어 있으며, 이 도면은 단지 파일 이름 프리픽스들 "/itv/att" 을 갖는 그들 파일들만이 저장되므로, 결국 그 번들에는 4 개의 파일들 중 2 개의 파일이 저장되어진다는 것을 나타낸다. 애플리케이션이 "/itv/vzw/s1/f3" 을 수신하게 되면, 파일 전달 프레임워크는 파일 번들을 다시 수신해야 할 수도 있다.
도 57 은 관리된 엘리먼트 테이블 (MET) 에서의 예시적인 파일 번들 엔트리를 도시하는 데이터 구조도이다. 도 57 에 도시된 바와 같이, 일 실시형태에서, 관리된 엘리먼트 테이블에서의 파일 번들에 대응하는 엘리먼트에 대한 엔트리는 다음의 정보, 즉, 파일 번들에 대응하는 엘리먼트의 ID (EID); 그 엘리먼트가 파일 번들인 것을 나타내는 플래그 (FB); 어느 파일 번들 내 파일들이 저장되었는지를 특정하는 선택 스트링들 (Selection Strings); 및 그 파일 번들에서의 각각의 엘리먼트에 대한, 파일 이름(들) (File Names), 엘리먼트 ID 및 스토리지 이름을 갖는 서브-엔트리 (Sub-Entry) 를 가질 수도 있다.
도 58 은 파일 번들을 수신하여 애플리케이션 스토리지 공간에 저장하는 예시적인 방법 (5800) 을 도시한다. 위에서 설명한 바와 같이, 파일 번들에 대응하는 엘리먼트를 성공적으로 수신한 후, 파일 전달 프레임워크는 그 번들 내 파일들을 애플리케이션 스토리지 공간에 저장할 수도 있다. 단계 (5802) 에서, 파일 전달 코어는 파일 번들에 대응하는 파일 전달 코어 페이로드를 성공적으로 수신한다. 단계 (5804) 에서, 파일 전달 코어는 파일 전달 파일 관리 계층에게, 파일 전달 코어 페이로드가 수신되었다는 것을 통지하고, 스크래치 공간에서의 그의 로케이션을 파일 전달 파일 관리 계층에 전달할 수도 있다. 단계 (5806) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어 페이로드를 위한 충분한 공간이 있다는 것을 결정하고 그 파일 전달 코어 페이로드를 스크래치 공간으로부터 애플리케이션의 스토리지 공간으로 이동시킬 수도 있다. 단계 (5808) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어에게, 파일 전달 코어 페이로드가 스크래치 공간으로부터 제거되었다는 것을 통지할 수도 있다. 단계 (5810) 에서, 파일 전달 파일 관리 계층은 메모리 (예컨대, P1) 에 저장된 파일 전달 코어 페이로드로부터 트레일러를 제거할 수도 있다. 단계 (5812) 에서, 파일 전달 파일 관리 계층은 그 파일 번들 내 파일들을 적합한 로케이션에 애플리케이션의 메모리 관리 정책에 따라서 저장할 수도 있다. 단계 (5814) 에서, 파일 전달 파일 관리 계층은 그 파일 번들에 대한 엔트리를 관리된 엘리먼트 테이블에 추가할 수도 있다. 단계 (5816) 에서, 파일 전달 파일 관리 계층은 애플리케이션에게, 파일이 캡쳐되었다는 것을 통지할 수도 있다.
도 59 는 방법 (5800) 에서 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 데이터 흐름들 및 상호작용 호출 흐름들의 일 예이다. 동작 (5901) 에서, 파일 전달 코어는 파일 번들에 대응하는 파일 전달 코어 페이로드를 성공적으로 수신한다. 호출 흐름 (5902) 에서, 파일 전달 코어는 파일 전달 파일 관리 계층에게, 파일 전달 코어 페이로드가 수신되었다는 것을 통지할 수도 있다. 그 후, 파일 전달 코어는 스크래치 공간에서의 파일 전달 페이로드의 로케이션을 파일 전달 파일 관리 계층에 전달한다. 동작 (5903) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어 페이로드를 위한 충분한 공간이 있는지 여부를 결정하고 그 파일을 스크래치 공간으로부터 애플리케이션의 스토리지 공간으로 이동시킨다. 호출 흐름 (5904) 에서, 파일 전달 파일 관리 계층은 파일 전달 코어에게, 파일 전달 코어 페이로드가 스크래치 공간으로부터 제거되었다는 것을 통지할 수도 있다. 동작 (5905) 에서, 파일 전달 파일 관리 계층은 메모리 (예컨대, P1) 에 저장된 파일 전달 코어 페이로드로부터 트레일러를 제거하고, 그 파일 번들 내 파일들을 저장하고, 그 파일 번들에 대한 엔트리를 관리된 엘리먼트 테이블에 추가한다. 호출 흐름 (5906) 에서, 파일 전달 파일 관리 계층은 애플리케이션에게, 파일이 캡쳐되었다는 것을 통지할 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 그 파일 번들 내에 포함되는 파일들을 성공적으로 저장한 후에, 수신된 파일 번들을 삭제할 수도 있다.
도 60 은 파일 번들로부터 수신되는 파일들을 삭제하는 예시적인 방법 (6000) 을 도시한다. 단계 (6002) 에서, 애플리케이션은 파일 번들에서 수신되는 파일을 삭제하라는 요청을 파일 전달 프레임워크에 발할 수도 있다. 단계 (6004) 에서, 파일 전달 파일 관리 계층은 그 파일에 대한 서브-엔트리를 갖는 관리된 엘리먼트 테이블에서 파일 번들 엔트리를 찾을 수도 있다. 결정 단계 (6006) 에서, 파일 전달 파일 관리 계층은 그 서브-엔트리가 그와 연관되는 하나 보다 많은 파일 이름들을 갖고 있는지 여부를 결정할 수도 있다. 그 서브-엔트리가 하나 보다 많은 파일 이름을 갖고 있다고 파일 전달 파일 관리 계층이 결정하면 (즉, 결정 단계 6006 = "예"), 단계 (6008) 에서, 파일 전달 파일 관리 계층은 그 서브-엔트리로부터 파일 이름을 제거할 수도 있다. 서브-엔트리가 하나 보다 많은 파일 이름을 갖지 않으면 (즉, 결정 단계 6006 = "아니오"), 단계 (6010) 에서, 파일 전달 파일 관리 계층은 그 파일을 스토리지 로케이션에서 삭제하고 관리된 엘리먼트 테이블에서 그 서브-엔트리를 제거할 수도 있다. 파일 번들 엔트리에 어떤 파일 서브-엔트리도 없으면 (즉, 파일 번들에서 수신되는 모든 파일들이 삭제되었으면), 단계 (6012) 에서, 파일 전달 파일 관리 계층은 메모리에서 파일 번들 엔트리를 삭제할 수도 있다. 일 실시형태에서, 그의 파일들의 서브세트가 삭제되었다면, 파일 번들 엘리먼트가 존재하는 것으로 간주될 수도 있다. 일 실시형태에서, 파일 전달 프레임워크는 삭제된 파일들이 다시 다운로드되지 않게 파일 삭제 프로세스가 애플리케이션에 의해 개시될 때마다 통지받을 수도 있다. 일 실시형태에서, 디바이스 상의 파일 전달 프레임워크는 그 파일 번들 내 적어도 하나의 파일이 그 디바이스 상에 존재하는 경우, 존재하는 것으로 파일 번들 엘리먼트를 간주할 수도 있다.
도 61 은 파일 번들로부터 수신되는 파일들을 삭제하는 것에 관련되는 논리적 및 예시적인 데이터 흐름들을 도시하는 데이터 구조도이다. 도 61 은 서브-엔트리가 그와 연관되는 오직 하나의 파일 이름 (예컨대, EID 2009) 만을 가질 때, 파일 전달 파일 관리 계층이 어떻게 그 파일을 스토리지 로케이션에서 삭제하고 전체 서브-엔트리를 어떻게 제거할 수도 있는지를 도시한다 (EID 2009 를 관통하는 라인으로 표시됨). 도 61 은 또한 서브-엔트리가 그와 연관되는 하나 보다 많은 파일 이름들 (예컨대, EID 1988) 을 갖는 경우, 파일 전달 파일 관리 계층이 어떻게 오직 그 파일 이름을 서브-엔트리로부터 제거될 수도 있는지를 도시한다 (파일 이름 /itv/att/s1/f1 2001 및 스토리지 경로 D:/fdroot/att/s1/f1 를 관통하는 라인으로 표시됨).
도 62 는 이전에 수신된 파일 번들을 수신할 때, 애플리케이션 계층 (App 계층), 파일 전달 코어 (FDC) 계층 및 파일 전달 파일 관리 (FDM) 계층 사이의 예시적인 데이터 흐름들 및 상호작용 호출 흐름들을 도시한다. 동작 (6201) 에서, 파일 번들 브로드캐스트 스케쥴 레코드 (BSR) 가 파일 전달 코어에 의해 수신되어 양방향-프리픽스-매칭된다. 호출 흐름 (6202) 에서, 파일 전달 코어는, 그 파일이 이미 존재하는지 여부를 결정하고 그 파일 번들이 수신되어야 하는지 여부를 결정하기 위해서, 선택 스트링들, 엘리먼트 id 및 엘리먼트 유형을 파일 전달 파일 관리 계층에 전달한다. 동작 (6203) 에서, 파일 전달 파일 관리 계층은 그 파일 번들에 대응하는 엘리먼트에 대한 선택 스트링들 ("/itv/vwz/s1/f3" 및 "/itv/vwz/s1/f4") 을 유지한다. 호출 흐름 (6204) 에서, 파일 번들에 대응하는, 엘리먼트, 또는 파일 전달 코어 페이로드가 파일 전달 코어에 의해 수신되어 파일 전달 파일 관리 계층으로 전달된다. 도 62 에 도시된 바와 같이, 파일 번들은 4 개의 파일들, 즉, /itv/vzw/s1/f3, /itv/vzw/s2/f4, /itv/att/s1/f1, 및 /itv/att/s2/f2 을 가질 수도 있다. 도시된 예에서, 파일 전달 파일 관리 계층은 파일 전달 프레임워크가 파일 번들을 수신하였지만 이전에는 단지 그 파일들 중 2 개, 즉, /itv/vzw/s1/f3 및 /itv/vzw/s2/f4 만이 저장하고 있다고 결정한다. 이것은 예를 들어, 애플리케이션 계층 상에서 실행하는 애플리케이션이 그 파일 번들에서 파일들 중 2 개 (예컨대, /itv/att/s1/f1, 및 /itv/att/s2/f2) 를 이전에 요청받은 후, 처음 2 개의 파일들과 동일한 파일 번들에 있는 것으로 발생하는 2 개의 새로운 파일들 (예컨대, /itv/att/s1/f3 및 /itv/att/s2/f4) 에 대해 또 다른 요청을 발할 때와 마찬가지일 수도 있다. 호출 흐름 (6203) 에서, 파일 전달 파일 관리 계층은 파일 번들을 파일 전달 코어로부터 다시 수신하고 그 파일 번들에서 단지 2 개의, 새로 요청된, 파일들 (예컨대, /itv/vzw/s1/f3 및 /itv/vzw/s2/f4) 만을 메모리에 저장한다.
도 63 은 파일 전달 코어와 파일 전달 파일 관리 계층 사이에 데이터를 교환하는데 사용될 수도 있는 예시적인 파일 전달 코어 페이로드 포맷을 도시한다. 일 실시형태에서, 파일 전달 코어 및 파일 전달 파일 관리 계층은 다수의 파일 전달 코어 페이로드 포맷들을 동시에 지원하도록 구성될 수도 있다. 일 실시형태에서, 파일 전달 코어 페이로드 포맷은 브로드캐스트 스케쥴 레코드에 파라미터, 플래그, 또는 비트 (예컨대, FD_MODE) 로 특정될 수도 있다. 일 실시형태에서, FD_MODE 비트를 0 으로 설정하는 것은 제 1 포맷을 선택하는 반면, FD_MODE 비트를 1 로 설정하는 것은 제 2 포맷을 선택한다.
도 64 는 도 63 에 도시된 BCF (backward compatible format) 에 대응하는 예시적인 파일 전달 코어 페이로드 포맷을 도시한다. 도 64 에 도시된 파일 전달 코어 페이로드 포맷은 단일 파일, 또는 다수의 파일들을 포함하는 파일 번들을 포함할 수도 있다. BCF 파일 전달 코어 페이로드 포맷은 끝에 클립 메타 데이터를 포함할 수도 있다. 파일 전달 코어 페이로드 포맷은 클립 메타 데이터의 clip_def_rec XML 엘리먼트에 그 파일 번들 내 파일 또는 파일들에 대한 non_realtime_presentation XML 엘리먼트에 추가되는 옵션적인 엘리먼트 ID 및 파일 이름(들) 을 포함할 수도 있다. 여러 실시형태들에서, 수신기 디바이스들은 엘리먼트 ID들 및 파일 이름들을 수신하고 액세스할 수도 있다. 일 실시형태에서, 수신기 디바이스들은 그들이 인지하지 못하는 임의의 새로운 필드들을 무시할 수도 있다.
도 65 및 도 66 은 도 63 에 도시된 포맷에 대응하는 예시적인 파일 전달 코어 페이로드 포맷을 도시한다. 구체적으로 설명하면, 도 65 는 2 개의 이름들을 갖는 단일 파일인 엘리먼트에 대한, 예시적인 파일 전달 코어 페이로드 포맷을 도시한다. 도 66 은 2 개의 이름들을 갖는 파일 (예컨대, 파일 1) 을 포함하는 파일 번들인 엘리먼트에 대한, 예시적인 파일 전달 코어 페이로드 포맷을 도시한다. 도 65 및 도 66 에 도시된 파일 전달 코어 페이로드 포맷들은 단일 파일, 또는 일련의 파일들을 포함하는 파일 번들인 엘리먼트 부분을 포함할 수도 있다. 예시된 파일 전달 코어 페이로드 포맷들은 다음의 정보 필드들: 트레일러 데이터 길이; 트레일러 데이터; 및 엘리먼트 ID 를 포함하는 트레일러 섹션을 갖는다. 트레일러 데이터 필드는 파일 전달 코어 페이로드의 엘리먼트 부분에 걸쳐서 적용되는 압축 방식을 특정하는 압축 유형 필드를 추가로 포함할 수도 있다. 일 실시형태에서, 엘리먼트 유형 필드는 그 엘리먼트가 파일인지 또는 파일 번들인지 여부를 나타낼 수도 있다. 그 엘리먼트가 파일이면, 도 65 에 도시된 바와 같이, 트레일러는 또한 엘리먼트 유형들 및 파일 이름들에 대한 추가 정보 필드들을 포함할 수도 있다. 그 엘리먼트가 파일 번들이면, 도 66 에 도시된 바와 같이, 트레일러는 그 번들 내 각각의 파일에 대한 엘리먼트 ID 들, 오프셋들, 및 파일 이름들에 대한 정보 필드들을 포함할 수도 있다.
도 4 을 참조하여 위에서 설명한 바와 같이, 애플리케이션들 (예컨대, 헤드엔드 애플리케이션들 (42, 43)) 은 송신을 위한 파일들을 파일 수취 서버 (31) 에 제공한다. 파일 수취 서버 (31) 는 파일들을, 브로드캐스트 스케쥴 메시지들과 함께, 파일 전송 네트워크 (41) 를 경유해서 수신기 디바이스들에 전달한다. 도 67 은 파일들을 수취하고, 송신을 위한 파일들을 스케쥴링하고, 브로드캐스트 스케쥴 메시지들을 발생하고 그 발생된 브로드캐스트 스케쥴 메시지들을 브로드캐스트하는 예시적인 방법 (6700) 을 도시한다. 방법 (6700) 의 단계 (6702) 에서, 파일 수취 서버 (31) 와 같은, 헤드엔드 시스템의 서버는 송신을 위한 파일들을 하나 이상의 헤드엔드 애플리케이션들 (42, 43) 로부터 수신할 수도 있다. 단계 (6704) 에서, 서버는 파일 및/또는 엘리먼트를 발생하고, 수취 프로세스의 부분으로서 브로드캐스트될 파일들에 대한 파일 또는 엘리먼트 식별자들을 획득/발생할 수도 있다. 단계 (6706) 에서, 수취 프로세스의 부분으로서, 서버는 파일 사이즈 뿐만 아니라, 파일들에 관련한 다른 정보, 예컨대, 위에서 설명한 바와 같은, 파일 속성 스트링들, 또는 애플리케이션/서비스 식별자들을 획득할 수도 있다. 단계 (6708) 에서, 수취 프로세스의 부분으로서, 서버는 데이터 파일들을 운반하는 콘텐츠 흐름의 데이터 레이트를 결정할 수도 있다. 데이터 레이트는 브로드캐스트 리소스 이용가능성에 따라서 변할 수도 있다. 데이터 레이트는 또한 예컨대, 특정의 파일 전달 유형에 대해 특정되어 있다면, 고정적으로 유지할 수도 있다.
수취 프로세스의 부분으로서, 단계 (6710) 에서, 서버는 예컨대, 파일 사이즈를 파일 전달 데이터 레이트로 분할함으로써 각각의 파일의 브로드캐스트 지속기간을 결정할 수도 있다. 단계 (6711) 에서, 서버는 송신 지속기간에 기초하여, 어느 파일들이 다음 브로드캐스트 스케쥴 기간 (BSP) 내에 브로드캐스트될 것인지를 결정할 수도 있다. 스케쥴링 프로세스 및 BSM 발생 프로세스가 따로 떨어진 프로세스들임에 유의해야 하며, 여기서는 간결성을 위해 함께 설명한다. 예를 들어, 파일 스케쥴링 프로세스는 다음 15분 기간에 제한되지 않을 수도 있으며 (예컨대, 파일이 송신을 위해 수취로부터 3 시간 스케쥴링될 수도 있다), 한편, BSM 발생 프로세스는 BSM의 콘텐츠들을 다음 기간 (예컨대, 15 분) 에 대해 정의되는 현재 송신 스케쥴로서 주기적으로 (예컨대, 15 분마다) 결정할 수도 있다. 이하, 수취 및 BSM 발생에서 파일 스케쥴링의 프로세스들을 더욱더 자세하게 설명한다.
단계 (6712) 에서, 서버는 송신을 위한 파일들을 브로드캐스트 스케쥴 기간 내에서 스케쥴링할 수도 있다. 송신을 위한 파일들을 브로드캐스트 스케쥴 기간 내에서 스케쥴링하는 것의 부분으로서, 단계 (6714) 에서, 서버는 브로드캐스트 스케쥴 기간 내에서 각각의 파일에 대한 브로드캐스트 윈도우 시작 시간들을 식별할 수도 있다. 단계 (6716) 에서, 서버는 브로드캐스트 스케쥴 메시지, 및 레코드 유형, 레코드 데이터 링크 및 브로드캐스트 스케쥴 메시지에 대한 다음 업데이트의 시간 (예컨대, 다음 모니터링 시간) 을 특정하는 브로드캐스트 스케쥴 모니터링 레코드 (BSMR) 를 발생할 수도 있다.
브로드캐스트 스케쥴 메시지를 발생하는 것의 부분으로서, 단계 (6718) 에서 서버는 하나 이상의 흐름 브로드캐스트 스케쥴 레코드들 (FBSR) 을 발생할 수도 있다. 브로드캐스트 스케쥴 메시지를 발생하는 것의 부분으로서, 단계 (6720) 에서, 서버는 BSP 내에 브로드캐스트될 파일들의 각각에 대한 브로드캐스트 윈도우를 식별하는 것을 포함하여, 그 수신된 및 발생된 정보로부터 브로드캐스트 스케쥴 메시지를 조합할 수도 있다. 단계 (6722) 에서, 서버는 반복된 송신을 브로드캐스트 스케쥴 흐름을 통해서 개시하기 위해서 그 조합된 브로드캐스트 스케쥴 메시지를 브로드캐스트 네트워크에 실행의뢰할 수도 있으며, 단계 (6724) 에서, 서버는 브로드캐스트를 위한 파일들을, 그 파일들이 브로드캐스트 스케쥴 메시지에 특정되는 브로드캐스트 스케쥴에 따라서 파일 전달 데이터 흐름을 통해서 송신될 수 있도록, 브로드캐스트 네트워크에 실행의뢰할 수도 있다. 이 프로세스는 다음 BSP 에 대해 브로드캐스트 스케쥴 메시지를 전개하는 것을 시작하기 위해서 단계 (6702) 로 되돌아가는 서버에 의해 반복될 수도 있다.
위에서 설명한 바와 같이, 일단 파일 콘텐츠 제공자 (9) 내의 파일 전달 애플리케이션이 전송을 위한 파일들을 브로드캐스트 네트워크 (1) 를 통해서 실행의뢰하면, 파일 수취 시스템 (31) 은 브로드캐스트를 위한 그들 파일들을 파일 전송에 전용되는 브로드캐스트 리소스들을 이용하여 스케쥴링할 수도 있다. 이들 전용 브로드캐스트 리소스들은 파일 전달 파이프들로서 개념적으로 간주될 수도 있다. 위에서 설명한 바와 같이, 여러 실시형태들에서, 하나 보다 많은 파일 전달 파이프들은 그 파일들을 브로드캐스트 네트워크를 통해서 브로드캐스트하는데 이용될 수도 있다. 하나 이상의 파일 전달 파이프들에서의, 수취된 파일들의 스케쥴링 및 파일들의 시간 멀티플렉싱이 도 7 에 도시된다.
위에서 설명한 바와 같이, 파일 수취 시스템 (31) 은 파일들을 다양한 상이한 소스들 (즉, 헤드엔드 애플리케이션들) 로부터 다양한 상이한 포맷들로 수신할 수도 있다. 파일 수취 시스템 (31) 은, 그 파일들이 브로드캐스트 스케쥴 메시지 내에 광고되는 브로드캐스트 윈도우 내에서 브로드캐스트되도록 보장하기 위해서, 브로드캐스트 스케쥴 메시지를 발생하고 파일 전송 네트워크 (41) 와 조정하여, 여러 수신된 파일들을 스케쥴링한다.
도 68 은 2 개의 헤드엔드 애플리케이션들이 파일 전송 네트워크 (41) 를 통한 전송을 위해서 파일들을 파일 수취 시스템 (31) 에 실행의뢰하는 예시적인 실시형태를 도시한다. 이 도시된 예에서, 2 개의 헤드엔드 애플리케이션들은 날씨 애플리케이션 (43) 및 상호작용성 애플리케이션 (49) 이다. 이 예에서, 날씨 애플리케이션 (43) 은 애플리케이션 파일들을 수신기 디바이스 상에서 동작하는 날씨 애플리케이션 (46) 에 전달하기 위해 파일 전송 네트워크 (41) 를 이용하고 있다. 이와 유사하게, 상호작용성 애플리케이션 (49) 은 상호작용성 리소스들 및 파일들을 수신기 디바이스 상의 상호작용성 애플리케이션 (47) 에 전달하기 위해서 파일 전송 네트워크 (41) 를 이용하고 있다. 여러 실시형태들에서, 헤드엔드 애플리케이션들 (43, 49) 은 그 파일을 적합한 파일 지령, 예컨대, sendFile(/weaApp/LA/f1.jpg) 및 도 68 에 나타낸 데이터 스키마의 다른 파라미터들과 함께 제공함으로써, 간단히 파일 수취 시스템 (31) 과 상호작용할 수 있다. 일련의 파일들을 전송하기 위해서, 헤드엔드 애플리케이션들 (43, 49) 은 그 파일들을 단일 지령, 예컨대, sendFile(/itv/sig/cat.xml; itv/res/svc_5/f1.jpg; /itv/res/svc_5/f2.jpg; /itv/res/svc_5/f3.jpg) 으로 특정할 수도 있다.
도 68 이 도시하는 바와 같이, 일부 애플리케이션들이 콘텐츠 파일들을 단지 실행의뢰할 수도 있으며 (예컨대, 날씨 애플리케이션이 jpeg 이미지들을 실행의뢰할 수도 있다), 한편 다른 애플리케이션들은 콘텐츠 및 오버헤드 파일들을 실행의뢰할 수도 있다 (예컨대, 상호작용성 애플리케이션이 jpeg 이미지들 및 cat.xml 오버헤드 파일을 실행의뢰할 수도 있다). 또한, 다른 애플리케이션들은 콘텐츠 파일들을, 추가적인 속성 정보와 함께 실행의뢰할 수도 있다 (예컨대, 상호작용성 애플리케이션이 jpeg 이미지들 및 그 파일들에 대한 특성들을 기술하는 연관 속성들을 대안적으로 실행의뢰할 수도 있다).
오버헤드 파일들을 파일 수취 시스템에 실행의뢰하는 애플리케이션은 이런 오버헤드 파일들에 대해 상이한 목적들을 가질 수도 있다. 이런 오버헤드 파일은 수신기 디바이스들에 디바이스 애플리케이션에 이용가능한 파일들에 관한 정보를 제공하는데 사용될 수도 있다. 일 실시형태에서, 이런 오버헤드 파일은 카탈로그 파일 또는 cat.xml 파일의 형태일 수 있다. cat.xml 파일은 수신기 디바이스들로 하여금 수신을 위한 파일들을 선택가능하게 할 수도 있는 속성들의 리스트를 제공하는데 사용될 수도 있다. 동일한 속성 리스트 정보는 또한 수취 인터페이스를 통해서, 예컨대, 도 69 에 도시된 데이터 스키마를 제공함으로써, 이용가능해질 수도 있다. 추가적으로 또는 이의 대안으로, 속성 리스트는 브로드캐스트 스케쥴 메시지로 운반될 수 있다.
파일들을 파일 수취 시스템 (31) 에 실행의뢰하는데 사용될 수도 있는 예시적인 데이터 스키마가 도 69 및 도 70 에 도시된다. 파일 수취 시스템은 또한 송신될 파일에 관련한 정보, 예컨대, 전달 기준들을 수신하는 인터페이스를 제공할 수도 있다. 예를 들어, 도 70 에 나타낸 데이터 스키마에 도시된 바와 같이, 파일 수취 인터페이스 파일 전달 요청은 원하는 시작 시간, 및 만료 시간, 또는 송신될 파일들에 대한 브로드캐스트 스케쥴을 특정할 수도 있다. 브로드캐스트 스케쥴이 특정되면, 파일 전달 요청은 파일이 송신되어야 하는 기간 및 파일 송신들이 시도되어야 하는 횟수를 식별할 수도 있다. 브로드캐스트 스케쥴은 또한 이후에는 파일이 송신되지 않아야 하는 종료 시간을 포함할 수도 있다.
파일 전달 요청 동작은 파일 전달 애플리케이션들에, 다음의 특징들: 송신을 위해 실행의뢰되는 파일을 식별하는 메커니즘; 다수의 파일들을 동시에 실행의뢰하는 메커니즘; 애플리케이션 레벨에서 함께 관련될 수도 있는 파일들을 그룹화하는 메커니즘; 관련된 파일들의 각각의 그룹에 대한 상이한 전달 기준 요구사항들의 정의; 및 이전에 실행의뢰된 아이템들의 전달 기준들이 업데이트될 수 있도록, 제 2 시간에 실행의뢰되는 파일들이 재실행의뢰 (resubmission) 로서 인식되게 할 수 있는 메커니즘을 제공할 수도 있다.
송신을 위해 실행의뢰되는 파일을 식별하는 메커니즘은 파일 수취 동작을 통해서 실행의뢰될 수도 있다. 이 동작에서, 파일 수취 서비스에 의한 브로드캐스트를 위해 파일이 취출될 수 있는 로케이션을 제공하는, 콘텐츠 URL (universal resource locator) 이 식별될 수도 있다. 이 메커니즘은 또한 브로드캐스트를 위해서 수취될 파일의 콘텐츠 및 컨텍스트와 추가로 연관되는 추가적인 파라미터들을 식별할 수도 있다. 예를 들어, 추가적인 파라미터들은 그 파일에 대한 디렉토리를 애플리케이션 디렉토리 구조로 표시하는데 사용될 수 있는 파일 이름을 포함할 수도 있다. 추가적인 파라미터들은 수신기 디바이스들로 하여금 수신을 위한 특정의 파일을 필터링하여 선택할 수 있도록 파일을 특징화하는 파라미터들을 제공하는 속성 리스트를 포함할 수도 있다.
다수의 파일들의 실행의뢰를 동시에 가능하게 하는 메커니즘은 애플리케이션들로 하여금 관련되는 그들 파일들을 식별가능하게 할 수도 있다. 예를 들어, 파일 전달 요청에서 단일 파일 정보 유닛 상의 특정의 디렉토리 아래에서의 모든 상호작용성 파일들은 관련되는 것으로 간주될 수도 있다. 헤드엔드 애플리케이션들은, 교차 의존성들을 가진 파일들이 브로드캐스트를 위해 함께 번들링되고 스케쥴링되는 것을 보장할 수도 있다. 예를 들어, 도 68 에 리스트된 상호작용성 파일들은 새로운 파일들이 수신기 디바이스에 이용가능하게 될 때 상호작용성 카탈로그 파일을 업데이트할 수도 있다. 이 인터페이스에 의해, 디렉토리 /itv/res/svc_5/ 아래의 새로운 파일들이 아마도, 번들로서 송신되기 전에, /itv/sig/cat.xml 파일이 수신기 디바이스 상에 송신되어 이용가능하게 되도록 요청될 수도 있다.
관련된 파일들이 애플리케이션 계층에서 함께 그룹화가능하게 하는 메커니즘은 관련된 파일들이 동일한 전달 기준들의 지배를 받고 수신기 디바이스에 의해 동일하게 요구되는 것을 보장할 수도 있다. 파일 수취 시스템은 공중을 통해서 파일을 송신할 때 순방향 에러 정정 코딩의 좀더 효율적인 사용을 위해 유사한 파일들을 번들링할 수도 있다. 파일 투입 서비스는 관련되는 파일들을 함께 번들하기 위해 이 관련성 정보를 이용할 수도 있다. 파일들의 번들링에 관해 결정하는 다른 기준들이 또한 고려될 수도 있다. 예를 들어, 파일 수취 시스템은 서비스들에 가입되는 것과 관련되는 상이한 파일들을 함께 그룹화할 수도 있다. 따라서, 하나의 서비스에 대해 하나의 파일을 수신하도록 권한이 부여되는 수신기 디바이스는 함께 가입된 다른 서비스들에 대한 파일들을 수신하도록 권한이 부여될 수도 있다.
헤드엔드 애플리케이션들로 하여금, 관련된 파일들의 각각의 그룹에 대한 송신 요구사항들에 대해서 상이한 전달 기준들을 정의할 수 있게 하는 메커니즘은, 애플리케이션으로 하여금 그 수취된 파일들의 브로드캐스트를 위한 서비스 품질 (QoS) 의 레벨 또는 송신 요구사항들을 요청할 수 있도록 할 수도 있다. 서비스 품질은 시의성 (timeliness) (예컨대, 신선도) 및 성공적인 전달 (예컨대, 전달 실패들이 극복되는 것을 보장하는 여분의 송신들) 에 있어서, 의도되는 사용자 인구에 대한 전송 서비스의 품질을 나타낼 수도 있다. 파일 수취 시스템 (31) 은 관련된 파일들의 각각의 그룹을, 그들의 요청된 전달 기준들이 만족되도록, 스케쥴링할 수도 있다. 새로운 파일들을 스케쥴링하면, 파일 수취 시스템은 우선순위 스케쥴링이 고려될 때, 이전에 수취된 파일들의 전달 기준들이 타협되지 않도록 보장할 수도 있다. 이전에 스케쥴링된 파일들은 우선순위-기반의 스케쥴링에서 새로운 파일들을 위한 공간을 만들기 위해서 폐기될 수도 있다. 파일 수취 시스템은 동일한 파일이 제 2 또는 제 3 시간에 실행의뢰될 때, 이전에 송신된 파일의 재실행의뢰 또는 업데이트로서 인식되어, 이전에 실행의뢰된 파일들에 대한 전달 기준들이 재사용될 수 있게, 구성될 수도 있다.
파일 수취 시스템 (31) 이 수취를 위한 파일들을, 예컨대 제 1 브로드캐스트 스케쥴 기간 동안 수신하기 때문에, 새로운 파일들이 송신을 위해 스케쥴링될 수 있는 가장 이른 것이 도 71 에 도시된 바와 같이, 다음 브로드캐스트 스케쥴 기간에 존재한다. 예를 들어, 파일들 f8, f9 및 f10 이 파일 콘텐츠 제공자 (9) 로부터 제 1 브로드캐스트 스케쥴 기간 (BSP1) 동안 수신되기 때문에, 파일 수취 시스템 (31) 은 다음 또는 이후의 브로드캐스트 스케쥴 기간 (BSP2) 동안 파일 송신들을 스케쥴링할 수도 있다. 파일들이 송신을 위해 스케쥴링되기 때문에, 그 파일들은 데이터 스토어 (32) 에 저장될 수도 있다. 최종 업데이트된 브로드캐스트 스케쥴은 또한 데이터베이스에서와 같은 메모리에 저장될 수도 있다.
현재 브로드캐스트 스케쥴 기간 동안 수신되는 파일들이 단지 도 71 에 도시된 바와 같이 다음 또는 후속 브로드캐스트 스케쥴 기간들에서 송신을 위해 스케쥴링되는 것이 가능해진다. 이것은 현재 브로드캐스트 스케쥴 기간에서의 스케쥴 정보가 수신기 디바이스들에게 현재 브로드캐스트 스케쥴 메시지를 통해서 이미 광고되었기 때문이다. 일단 브로드캐스트 스케쥴 메시지가 브로드캐스트되면, 수신기 디바이스들이 어떤 관심 파일들도 브로드캐스트 스케쥴 동안 송신을 위한 브로드캐스트 스케쥴 메시지에 리스트되어 있지 않으면 전력을 절약하기 위해서, 수신기 회로들을 비활성화하였을 수도 있기 때문에, 수신기 디바이스들은 후속 스케쥴 변경들을 브로드캐스트 스케쥴 메시지에 의해 포괄되는 브로드캐스트 스케쥴 기간에서 검출하지 못할 수도 있다. 따라서, 브로드캐스트 스케쥴 기간 지속기간의 선택은, 콘텐츠의 가능한 신선도와, 얼마나 자주 디바이스들이 업데이트된 브로드캐스트 스케쥴 메시지를 수신하는 것을 필요로 할 것인지 사이의 타협일 수도 있다. 더 적은 브로드캐스트 스케쥴 기간은 새로 수신된 파일들이 더 빠르게 송신될 수 있게 한다; 그러나, 수신기 디바이스들이 업데이트된 브로드캐스트 스케쥴 메시지를 빈번하게 수신하도록 하는 요구는 그들의 배터리 수명에 영향을 미칠 수도 있다.
따라서, 파일 수취 시스템 (31) 내의 스케쥴러는 현재 브로드캐스트 스케쥴 기간이 새로 수신된 파일들을 운반하는데 이용불가능한 것으로 간주한다. 그러나, 현재 브로드캐스트 스케쥴 기간을 초과하는 임의의 시간 기간은, 그 스케쥴이 수신기 디바이스들에게 아직 광고되지 않았기 때문에, 변경될 수도 있다. 도 72a 내지 도 72d 는 파일들이 수신되는 시기 및 그들의 긴급성에 따라서 어떻게 브로드캐스트 스케쥴들이 변경될 수 있는지를 도시한다.
예를 들어, 도 72a 는 새로운 파일들 f8 - f10 이 전송을 위해 파일 수취 서비스 (31) 로 실행의뢰되기 전의 스케쥴링 상태를 도시한다. 도 72b 는 파일 f8 이 긴급한 전달 요구사항들을 특정하는 상황에 대한 스케쥴링 상태를 도시한다. 이 상황에서, 파일 수취 시스템 (31) 은 더 낮은 우선순위 또는 덜 제한적인 시간 전달 요구사항들을 가진 다른 파일들 (예컨대, f51) 이 지연되게 할 수도 있다 (즉, 그들의 스케쥴링된 브로드캐스트 윈도우들이 연기된다). 추가적인 지연들을 견딜 수 없는 다른 파일들 (예컨대, f5) 은 재스케쥴링되지 않으며, 그들은 그들의 원래 브로드캐스트 윈도우들에서 브로드캐스트를 위해 계속 스케쥴링된다. 도 72c 는 다음 브로드캐스트 스케쥴 기간에서 파일들이, 파일 f9 이 수취되어 파일 f9 이 후속 브로드캐스트 스케쥴 기간에서 송신을 위해 스케쥴링될 때까지, 추가적인 지연을 견딜 수 없는 상황을 도시한다. 도 72d 는 다음 브로드캐스트 스케쥴 기간에서 파일들이 추가적인 지연을 견디지 못하는 시간에서 파일 f10 이 수취되고, 파일 f10 이 파일 f9 보다 더 긴급성을 갖고, 그 결과, 파일 f9 이 이후의 브로드캐스트 스케쥴 기간으로 밀려지는 상황을 도시한다.
파일 수취 시스템은 또한 브로드캐스트 네트워크로의 파일들의 전달 또는 브로드캐스트 송신을 조정하는 것을 담당할 수도 있다. 이 프로세스는 도 73 에 도시된 바와 같이 브로드캐스트 스케쥴 메시지 (BSM) 정보의 브로드캐스트를 수반할 수도 있다. 이 프로세스는 도 74 에 도시된 바와 같이 브로드캐스트 네트워크로의 파일들의 급송 (dispatching) 을 수반할 수도 있다.
공중을 통해서 송신되는 브로드캐스트 스케쥴 메시지를 업데이트하는 것에 관련되는 프로세스들이 도 73 에 도시되며, 도 75 에 도시된 예시적인 방법 (7500) 의 프로세스 흐름도에서 끝난다. 현재 브로드캐스트 스케쥴 기간의 끝 이전의 일부 시간에, 단계 (7502) 에서, 파일 수취 시스템 (31) 은 현재 스케쥴 정보를 그의 스토리지 (32) 로부터 페치할 수도 있으며, 단계 (7503) 에서, 다음 브로드캐스트 스케쥴 기간을 기술하기 위해 새로운 브로드캐스트 스케쥴 메시지를 생성할 수도 있다 (동작 A). 단계 (7504) 에서, 파일 수취 시스템은 브로드캐스트 스케쥴 메시지 버전을 OSS 로 업데이트할 수도 있으며, 이 OSS 는 오버헤드 버전 변경들을 관리하고 광고하는 보충물이다. 단계 (7506) 에서, 파일 수취 시스템은 그 업데이트된 브로드캐스트 스케쥴 메시지를 배포 서버 (DIST) 로 전송할 수도 있으며, 이 배포 서버는 파일들 및 오버헤드 메시지들을 구성되는 레이트에서 브로드캐스트를 위해 송신하는 구성요소이다. 단계 (7508) 에서, OSS 는 그 업데이트된 브로드캐스트 스케쥴 메시지 버전을 초기 획득 흐름 (IAF) 에서 운반되는 메시지에 추가할 수도 있으며, 단계 (7510) 에서 그 업데이트된 IAF 메시지를 배포 서버로 전송할 수도 있다 (통신 B). 배포 서버는 그 업데이트된 브로드캐스트 스케쥴 메시지를 브로드캐스트 스케쥴 흐름을 통해서 그 구성된 브로드캐스트 스케쥴 흐름 데이터 레이트에서 흐름 서비스 노드 (FSN) 로 전송할 수도 있으며, 이 흐름 서비스 노드는 그 송신을 걸쳐서 실제로 관련되는 브로드캐스트 네트워크 내의 구성요소이다.
송신된 브로드캐스트 스케쥴 메시지들을 업데이트하는 것에 관련되는 프로세스들이 도 74 및 도 75 에 도시된다. 파일 수취 시스템 (31) 은 또한 현재 브로드캐스트 스케쥴 메시지에 관한 스케쥴 정보를 이용하며, 그 메시지의 버전은 OSS 를 경유해서 광고되고, 그 메시지의 콘텐츠는 위에서 설명한 바와 같이 배포 서버를 경유해서 전송된다. 단계 (7516) 에서, 파일 수취 시스템은 파일들을 송신을 개시하여, 파일들이 수신기 디바이스들에 광고되는 브로드캐스트 스케쥴 메시지들에 따라서 공중을 통해서 브로드캐스트되게, 배포 서버에 시그널링할 수도 있다 (동작 1). 그렇게 함으로써, 파일 수취 서비스는 현재 브로드캐스트 스케쥴 메시지에 기술되는 정보에 부합하는 파일들을 송신할 때 사용되는 흐름 ID 및 데이터 레이트를 기술할 수도 있다. 단계 (7518) 에서, 배포 서버는 다음으로 브로드캐스트되는 파일 콘텐츠들을 페치하고 (동작 2), 그 후, 단계 (7520) 에서, 파일들의 송신을 위해 사용되는 흐름 ID 에 대해 정의되는 데이터 레이트에서 그 파일을 FSN 으로 송신할 수도 있다 (동작 3).
위에서 설명한 바와 같이, MediaFLO? 기술 브로드캐스트 네트워크와 같은 브로드캐스트 네트워크에서의 송신 리소스들은, MediaFLO? 에서 하나의 제 2 지속기간인 슈퍼 프레임들 내에서, OFDM 심볼들의 관점에서 정의될 수도 있다. 이런 슈퍼 프레임들 상의 심볼들은 로컬-영역 멀티플렉스 심볼 및 와이드-영역 멀티플렉스 심볼로 추가로 분할될 수도 있다. 상이한 브로드캐스트 네트워크들은 그 공유되는 브로드캐스트 리소스들을 통한 매체들의 전송을 위해 다른 (즉, OFDM 과는 상이한) 시간, 주파수 또는 코드 멀티플렉싱 메커니즘들을 가질 수도 있다. 용어 "멀티플렉스" 는 본원에서 (예컨대, 주어진 무선 주파수 대역폭에 걸쳐서) 브로드캐스트 네트워크를 통한 매체 전송에 이용가능한 브로드캐스트 리소스들을 일반적으로 지칭하기 위해 사용된다. 파일들을 전송하는데 이용가능한 브로드캐스트 리소스들의 양은 무선 주파수 대역폭, 전송 인코딩 메커니즘, 및 브로드캐스트 신호에 의해 운반되는, 실시간 콘텐츠 및 오버헤드 데이터와 같은, 다른 매체들 또는 데이터의 양의 함수일 수도 있다.
MediaFLO? 네트워크와 같은 멀티미디어 브로드캐스트 네트워크에서, 로컬 영역 콘텐츠 또는 로컬 멀티플렉스 (LM) 로서 지칭되는, 로컬 영역용으로 설계되는 콘텐츠, 및 와이드 멀티플렉스 (WM) 를 위한 와이드 영역 콘텐츠로서 지칭되는, 다수의 로컬 영역 브로드캐스터들에게 제공되는 콘텐츠를 포함한, 다양한 콘텐츠가 동시에 브로드캐스트될 수도 있다. 로컬 멀티플렉스 및 와이드 멀티플렉스는 주어진 무선 주파수 대역폭을 이용하는 멀티플렉스의 (예컨대, OFDM 프레임의) 상이한 부분들일 수도 있다. 로컬 영역 콘텐츠는 지역적인 브로드캐스트와 같은 로컬 동작 기반구조 (LOI) 에 고유한 콘텐츠일 수도 있다.
도 76 은 임의의 주어진 로컬 동작 기반구조에서, 다수의 무선 주파수 신호들이 존재할 수도 있다는 것을 도시한다. 도시된 예에서, 로컬 동작 기반구조 1 (LOI1) 은 단일 무선 주파수 신호 (RF1) 를 포함하며, 이 단일 무선 주파수 신호는 제 1 와이드 멀티플렉스 (WM1) 및 제 1 로컬 멀티플렉스 (LM1) 구성요소를 포함한다. 로컬 동작 기반구조 2 (LOI2) 는 2 개의 무선 주파수 신호들 (RF2 및 RF3) 을 포함하며, 각 신호들은 와이드 멀티플렉스 (WM2, WM1) 및 로컬 멀티플렉스 (LM2, LM1) 로 이루어진다. 도시된 예에서, 로컬 동작 기반구조 3 (LOI3) 은 와이드 멀티플렉스 (WM2) 및 로컬 멀티플렉스 (LM3) 로 이루어지는 단일 무선 주파수 신호 (RF4) 를 포함한다.
도 76 에 도시된 바와 같이, 임의의 무선 주파수 신호로 운반되는 와이드 멀티플렉스 구성요소 및 로컬 멀티플렉스 구성요소는 다른 무선 주파수 신호들에서의 와이드 멀티플렉스 구성요소 및 로컬 멀티플렉스 구성요소와 같거나 또는 상이할 수도 있다. 게다가, 상이한 무선 주파수 신호들은 또한 MediaFLO? 기술, ISDB-T, ATSC-M/H 등과 같은 상이한 전송 기술들을 이용할 수도 있다. 도 76 은 주어진 멀티플렉스 (예컨대, WM1 또는 LM2) 가 상이한 로컬 동작 기반구조들에서 상이한 무선 주파수 신호들로 운반될 수도 있다는 것을 도시한다. 또한, 주어진 로컬 동작 기반구조는 이용가능한 다수의 무선 주파수 신호들을 가질 수도 있다.
도 77 은 다수의 파일 전달 유형들이 멀티플렉스에 따라서 정의될 수도 있다는 것을 도시한다. 위에서 설명한 바와 같이, 여러 실시형태들은 멀티플렉스에 따른, 초 당 심볼들 (예컨대, OFDM 심볼들) 의 양과 같은, 단일 공동 리소스 풀 (pool) 을 공유하는 파일 송신들로 구현될 수도 있다. 위에서 설명한 바와 같이, 이런 리소스 풀들은 파일 전달 프레임워크 내에 하나 이상의 파일 전달 파이프들 (FDPs) 로서 추상화되고 정의될 수도 있다. 도 77 은 이들 파일 전달 파이프들의 많은 것들이 단일 멀티플렉스로 정의될 수도 있다는 것을 도시한다. 구체적으로 설명하면, 도 77 은, 와이드 멀티플렉스 (WM1) 가 2 개의 파일 전달 파이프들 (FD 파이프 1, FD 파이프 2) 을 포함하고 있어, 멀티플렉스 대역폭의 나머지가 실시간 및 IP 데이터 서비스들 (RT+IPDS) 을 송신하는 것에 전용되게 할 수도 있다는 것을 도시한다. 이와 유사하게, 제 2 와이드 멀티플렉스 (WM2) 는 3 개의 파일 전달 파이프들 (FD 파이프들 3 내지 5) 을 포함하고 있어, 멀티플렉스 대역폭의 나머지는 실시간 및 IP 데이터 서비스들을 송신하는 것에 전용될 수도 있다.
여러 실시형태들에서, 파일 전달 파이프들은 브로드캐스트 네트워크 내에, 멀티플렉스에 의해 정의되는 논리적 엔터티 (예컨대, 파일 전달 파이프의 지리적인 도달거리), 송신 데이터 레이트, 및 파이프 흐름 ID 들의 세트로서 편성될 수도 있다. 한 파이프에 대해 정의되는 송신 데이터 레이트는 그 파이프에 할당되는 멀티플렉스 대역폭의 부분에 의존할 수도 있다. 여러 실시형태들에서, 파일 전달 파이프에 할당되는 리소스들의 양은 구성가능할 수도 있으며, 그 구성은 그 전개된 수신기 디바이스들에 의해 지원되는 데이터 레이트에 의존할 수도 있다.
도 77 은 또한 여러 실시형태들에서, 파일 전달 파이프들이 그들의 데이터 레이트들에 의해 정의되고 편성될 수도 있다는 것을 도시한다. 파일 전달 파이프들의 데이터 레이트들에서의 변동은 각각의 파이프의 직경으로 도시된다 (예컨대, WM1 에서의 파일 전달 파이프들이 더 높은 데이터 레이트들을 가지며, 따라서 WM2 에서의 파일 전달 파이프들보다 더 굵다). 파일 전달 파이프들을 더 높은 및/또는 더 낮은 데이터 레이트들의 그룹들로 정의하고 편성하는 것은 전개된 수신기 디바이스들의 다양한 세트로부터 발생하는 제한들을 해소하는 것을 돕는다. 예를 들어, 조기 (early) 발생 수신기 디바이스들은 일반적으로 제한된 최대 데이터 레이트를 지원하는 반면, 나중 (later) 발생 수신기 디바이스들은 더 높은 데이터 레이트들을 지원할 수도 있다. 그들의 데이터 레이트들에 의해 파일 전달 파이프들을 정의하고 편성하는 것은, 파일 전달 서비스가 조기 및 나중 발생 수신기 디바이스들 양자를 지원할 수 있도록 한다.
도 78a 및 도 78b 는 파일 전달 파이프들이 또한 시간 다이버시티 고려사항들을 해소하기 위해 사이즈 조정되고 편성될 수도 있다는 것을 도시한다. 예를 들어, 멀티플렉스에서 파일 전달 파이프들은, 큰 파일들을 운반하기 위해 높은-대역폭/높은-용량 파일 전달 파이프를 제공하고, 더 작은 파일들을 위해 더 낮은 대역폭/더 낮은 용량 파일 전달 파이프를 제공하도록, 편성될 수도 있다. 이런 편성은 브로드캐스트 시스템이 작은 긴급한 파일들을 주기적으로 전송하도록 요청받는 경우에 유용할 수도 있다. 여러 실시형태들에서, 파일 전달 파이프들은 도 78a 에 도시된 "굵은" 파일 전달 파이프, 또는 도 78b 에 도시된 "얇은 (thin)" 파일 전달 파이프인 것으로 정의될 수도 있다. 멀티플렉스 내에서 "얇은" 파일 전달 파이프를 정의함으로써, 브로드캐스트 네트워크는, 긴급한 파일들이 지연 또는 "굵은" 파일 전달 파이프를 통하여 운반되는 큰 파일 송신들을 중단시키는 것 없이 수신될 때, 이런 긴급한 파일들을 수용할 수 있다.
파일 전달 파이프들은 또한 예컨대, 도 79a 내지 도 79g 에 도시된 바와 같이, 하나의 파이프 상에서는 낮은 레이턴시 작은 파일들을 지원하면서 별개의 파이프 상에서는 높은-레이턴시 큰 파일들을 운반하기 위해서, 상이한 유형들의 파일 트래픽을 분리하도록 편성될 수도 있다. 여러 실시형태들에서, 파일 전달 파이프들은 정보를 전송하기 위해 "레이턴시 민감" 데이터캐스팅을 지원하도록 구성될 수도 있다. 여러 실시형태들에서, 시스템은 모든 데이터캐스트 전송들의 균일한 처리를 제공하도록 구성될 수도 있다. 여러 실시형태들에서, 낮은 레이턴시 트래픽은 하나 이상의 전달 파이프들로 집합될 수도 있다. 여러 실시형태들에서, 다수의 BSM 들은 여러 미리 설정된 및 동적 레이턴시 목표들을 지원하기 위해서 사용될 수도 있다. 여러 실시형태들에서, 애플리케이션들은 레이턴시 민감 데이터의 전송 전에 순방향 에러 정정 (FEC) 보호를 적용할 수도 있다.
도 79a 는 파일 전달 파이프들이 15 분, 1 분 및 30 초 레이턴시 제한들을 가진 파일들에 대해 별개의 파일 전달 파이프들을 정의하는 것처럼, 상이한 특정의 레이턴시 요구사항들을 지원하도록 정의될 수도 있다는 것을 도시한다. 특정의 파일 전달 파이프들로의 파일들의 프로비져닝은 또한 우선순위에 기초할 수도 있다. 예를 들어, 도 78a, 도 78b 및 도 79a 는 일부 파일 전달 파이프들이 낮은 레이턴시 (즉, 긴급한) 애플리케이션 파일들에 전용될 수도 있는 반면, 다른 파일 전달 파이프들이 중간-레이턴시 내지 하이-레이턴시 (즉, 비-긴급한) 애플리케이션 파일들을 운반하는데 전용될 수도 있다는 것을 도시한다.
도 79b 는 실시간 (RT) 콘텐츠에 스트림 당 멀티플렉스로부터, 또는 집합으로 (in aggregate) 대역폭이 할당될 수도 있다는 것을 도시한다. 상이한 레이턴시 허용 데이터캐스팅 스트림들에 걸쳐서 공유되는 FD 파이프들 (FD 파이프들 1 및 2) 의 세트에 걸쳐서 집합한 대역폭 (aggregate bandwidth) 이 레이턴시 허용 콘텐츠에 할당될 수도 있다. 레이턴시 민감 콘텐츠는 개개의 레이턴시 민감 데이터캐스팅 스트림들에 전용된 IPDS 흐름들 (IPDS 흐름들 1 내지 4) 상에서 송신될 수도 있다. 파이프 대역폭이 디바이스 제한들에 의해 억제될 수도 있으므로, 피크 및 평균 데이터 레이트, 및 버스트 (burst) 사이즈 요구사항들에 기초하여 레이턴시 민감 콘텐츠에 대역폭이 할당될 수도 있다. 이것이 도 79c 에 도시되어 있으며, 이 도 79c 는 집합한 대역폭이 피크 (BwPeak) 및 평균 (BwAvg) 데이터 레이트들, 및 버스트 사이즈 요구사항들에 기초할 수도 있다는 것을 나타낸다. 그러나, 어떤 상황들에서, 피크 (BwPeak) 및 평균 (BwAvg) 데이터 레이트들에 기초하여 최적의 집합한 대역폭을 추정하기 어려울 수도 있다. 예를 들어, 그 추정이 너무 보수적이면, 손실되는 여분의 (excess) 대역폭은 복구하기 어렵다. 대역폭 할당 전략이 너무 공격적이면, 상이한 스트림들 상의 동기화된 버스트들은 패킷 손실들을 초래하거나 또는 실시간 송신에 영향을 미칠 수도 있다. 따라서, 여러 실시형태들에서, 집합한 레이턴시 민감 흐름들은 데이터 브로드캐스트를 BSM 을 통해서 광고할 수도 있는 데이터캐스팅 전달 프레임워크 (DDF) 를 이용하여, 파이프들에서 "패킷화되고" 스트리밍될 수도 있다. 예를 들어, 도 79d 는 레이턴시 허용 및 민감 콘텐츠에 대한 전송을 위한 통합 시스템을 도시하며, 여기서, 레이턴시 민감 데이터, 레이턴시 허용 데이터, 및 실시간 데이터는 개개의 스트림들 상에서 분리되어 송신된다. 도 79d 는 레이턴시 민감 데이터가 하나의 세트의 파이프들 (레이턴시 민감 데이터 파이프들 1 및 2) 상에서 송신될 수도 있는 반면, 레이턴시 허용 데이터가 또 다른 세트의 파이프들 (레이턴시 허용 데이터 파이프들 1 및 2) 상에서 송신될 수도 있다는 것을 도시한다.
위에서 설명한 바와 같이, 여러 실시형태들에서, 데이터 브로드캐스트는 BSM 을 통해서 광고될 수도 있다. 여러 실시형태들에서, BSM 은 그 스케쥴 정보를 단지 더 적은 브로드캐스트 스케쥴 기간들 (bsp: 30 초 내지 5 분) (BSP 일반적으로 15 분) 에 걸쳐서 광고할 수도 있다. 여러 실시형태들에서, 다수의 스케쥴 기간들이 상이한 레이턴시 요구사항들을 해소하는 것을 지원하는데 이용될 수도 있다. 이것은 낮은 레이턴시 데이터에 대한 배터리 효율을 향상시키고 좀더 큰 데이터 변경의 기간을 제공한다 (예컨대, 시스템이 매 초마다 모니터링되지 않아도 된다). 또, 낮은 레이턴시 (30 + 초) 를 갖는 CBR 스트림 데이터의 경우, 데이터의 패킷화는 시스템이 데이터 스트림을 매 초마다 모니터링하는 것을 피할 수 있도록 한다.
도 79e 는 레이턴시 허용 및 민감 콘텐츠에 대한 전송을 위한 또 다른 통합된 시스템을 도시한다. 도 79e 는 스케쥴 브로드캐스트 그래뉼래러티 (granularity) 의 여러 레벨들이 레이턴시 허용 및 민감 콘텐츠의 통합 전송을 위해 추가되고 계층화될 수도 있다는 것을 도시한다. 예를 들어, 제 1 레벨에서, 브로드캐스트 스케쥴 기간은 장기 스케쥴 기간을 지정할 수도 있다. 이들 장기 스케쥴 기간들은 5 분의 배수들일 수도 있다. 일 실시형태에서, 장기 스케쥴 기간들은 15 분의 길이일 수도 있다. 여러 실시형태들에서, 장기 스케쥴 기간들은 레이턴시들을 15 분을 초과하여 견딜 수 있는 애플리케이션들용으로 지정될 수도 있다. 제 2 레벨에서, 중간 스케쥴 기간이 사용될 수도 있다. 이 중간 스케쥴 기간은 IAF 모니터 기간과 동일할 수도 있다. 여러 실시형태들에서, 중간 스케쥴 기간은 장기 스케쥴 기간보다 짧은 임의의 지속기간일 수도 있다. 예를 들어, 일 실시형태에서, 중간 스케쥴 기간은 5 분의 길이일 수도 있으며 5 분-BSP 레이턴시 제약들을 갖는 애플리케이션들을 도모하는데 이용될 수도 있다. 도 79e 는 또한 제 1 및 제 2 레벨들에 더해, 여러 실시형태들에서, 다수의 단기 스케쥴 기간들이 장기 및 중간 스케쥴링 기간들에 더해서 사용될 수도 있다는 것을 도시한다. 이들 단기 스케쥴 기간들은 IAF 모니터링 기간 (30 초 내지 5 분) 보다 더 작을 수도 있으며 낮은 레이턴시 (30 초 내지 5 분) 데이터를 지원하도록 정의될 수도 있다.
도 79f 는 레이턴시 허용 및 민감 콘텐츠에 대한 전송을 위한 또 다른 통합된 시스템을 도시한다. 도 79f 는 다수의 단기 스케쥴 기간들을 지원할 때에, BSF 가 다수의 논리적 BSM 들을 운반할 수도 있다는 것을 도시한다. 각각의 BSM 는 특정의 목표 레이턴시를 포괄하는 스케쥴을 기술할 수도 있으며, 각각의 BSM 는 BSM 이 다음에 업데이트될 시기를 식별하는 다음 모니터 시간을 운반할 수도 있다. 일 실시형태에서, BSM 들에 대한 수 및 기간은 애플리케이션에 의해 구성가능하며 만들어질 수도 있다. 여러 실시형태들에서, BSM 은 기간 변경들에 의거하여 좀더 빈번하게 전송되고, 그 후 덜 빈번하게 전송될 수도 있다. 여러 실시형태들에서, 디바이스 애플리케이션은 원하는 레이턴시에서 모니터링하도록 요청할 수도 있다. 예를 들어, 도 79g 는 디바이스/서버 데이터캐스팅 애플리케이션들이 레이턴시 요구사항들을 인식할 수도 있고, 데이터캐스팅 전달 프레임워크가 전송/캡쳐 요청을 레이턴시 요구사항들을 만족하는 BSM 기간에 맵핑할 수도 있다는 것을 도시한다. 여러 실시형태들에서, 디바이스 데이터캐스팅 전달 프레임워크 (DDF) 는 BSM 을 애플리케이션의 레이턴시 요청들을 만족하는 최저 업데이트 기간에서 모니터링할 수도 있다.
도 80 은 이들 편성들이 브로드캐스트 네트워크의 전송 서비스들을 레버리지할 수 있게 하기 위해서, 송신 리소스들 (즉, 파이프들) 이 특정의 콘텐츠 제공자 및/또는 무선 네트워크 운용자에 전용되도록 파일 전달 파이프들이 또한 편성될 수도 있다는 것을 도시한다. 예를 들어, 도 80 은 주어진 콘텐츠 제공자/무선 운용자로부터의 파일들 (예컨대, eID_1 내지 eID_4) 에 대한 콘텐츠가 다른 파이프를 이용하기 위한 회선경쟁 없이, 하나의 파이프로 항상 운반된다는 것을 도시한다.
파일 전달 파이프들은 논리적 파일 전달 파이프를 통해서 파일들을 전송하는데 사용되는 실제 송신 흐름을 식별하는 파이프 흐름 ID 들의 세트로 정의될 수도 있다. 도 81a 내지 도 81c 는 파일 전달 파이프들에 대한 3 개의 대안적인 편성들을 도시한다. 예를 들어, 도 81a 에 도시된 바와 같이, 파일 전달 파이프 흐름 ID 는 특정의 애플리케이션 또는 서비스에 전용될 수도 있다 (예컨대, 각각의 애플리케이션이 별개의 파이프 흐름 ID 를 가질 수도 있다). 이런 서비스들에의 액세스는 이런 애플리케이션들 또는 서비스들에의 가입을 제약받을 수도 있으며, 파일 전달 파이프 흐름에의 액세스가 조건부 액세스 솔루션들을 통해서 보호될 수도 있다. 여러 실시형태들에서, 조건부 액세스 솔루션들의 전용 리소스들의 애플리케이션 또는 서비스 발견이 시스템 정보 송신과 같은 별개의 메커니즘을 통해서 이루어질 수도 있다. 예를 들어, 일 실시형태에서, 브로드캐스트 스케쥴 메시지는 각각의 송신에 대한 흐름 ID 를 기술할 수도 있다.
또 다른 예로서, 도 81b 는 조건부 액세스 솔루션 보호가 필요하지 않고 어떤 시스템 정보-기반의 서비스 발견도 요구되지 않도록, 일부 흐름들이 가입 대상이 아닌 상이한 애플리케이션들 또는 서비스들에 걸쳐서 공유될 수도 있는 (예컨대, 상이한 애플리케이션들에 대한 단일/공유 파이프 흐름 ID 이 있는) 구현예를 도시한다. 이런 애플리케이션들은 어떤 전용 흐름 ID 할당도 필요로 하지 않으며, 따라서 파일 전달 파이프로의 시분할 멀티플렉스 상에서 동일한 흐름 ID 를 공유할 수도 있다.
제 3 예로서, 도 81c 는 상이한 파일들을 동시에 스케쥴링함과 동시에, 더 작은 파일들이 집합한 유형 리소스들이 초과하지 않는 한, 도 82a 및 도 82b 에 도시된 바와 같이 더 큰 파일들의 송신을 차단함이 없이, 더 낮은 데이터 레이트들에서 송신될 수도 있는 추가적인 유연성으로, 파일 수취 시스템 상의 파일 전달 파이프 스케쥴링 알고리즘이 구성될 수도 있는 편성을 도시한다. 즉, 상이한 및 별개의 파이프 흐름 ID 들은 작은 파일들이 더 큰 파일 송신들의 차단을 방지하는 방법으로서 동일한 파이프에서 스케쥴링될 수 있게 사용될 수도 있다. 이런 구현예에서, 파일 전달 파이프는 다수의 동시적인 송신들을 도모하기 위해서 다수의 흐름 ID 들로 구성될 수도 있다.
다수의 파일 전달 파이프들의 도입으로, 수신기 디바이스들 상의 파일들의 동시발생 인지의 이슈들이 발생할 수도 있다. 이것이 도 78a, 도78b, 도 79a, 및 도 80 에 도시되어 있으며, 이 도면들은 다수의 파이프들이 이용가능하고 따라서 다수의 파일들이 (디바이스들이 상이한 파이프들을 이용하는 상이한 제공자들로부터 콘텐츠에 액세스할 수 있다고 가정하면) 동시에, 즉 각각의 파이프를 통해 하나 송신될 수도 있는 시스템을 도시한다.
도 82a 및 도 82b 는 큰 파일들과 함께, 작은 파일들의 송신들을 처리하는 것에 대안을 도시한다. 이전에 언급한 바와 같이, 파일 전달 파이프들을 가진 브로드캐스트 네트워크는 파일들을 파이프들에 연관시켜 그 파일 브로드캐스트들을 스케쥴링하는 방법을 필요로 할 것이다. 프로비져닝 및 입력 파라미터들의 조합이 파일들을 파이프들에 연관시켜 그들의 송신을 스케쥴링하기 위해서 파일 수취 시스템 스케쥴러에 의해 사용될 수도 있다. 여러 실시형태들에서, 파이프들이 파이프들에의 로케이션 도달거리 (즉, 파이프 파일들이 브로드캐스트되는 장소) 에 따라서 프로비져닝될 수도 있다. 여러 실시형태들에서, 애플리케이션들/서비스들은 지리적인 양태를 가질 수도 있다. 예를 들어, 파일 시스템 추상화를 이용하는 날씨 애플리케이션은 디렉토리들에서 파일 이름들을 /weaApp/East/NYC/ 또는 /weaApp/West/LA/ 로서 정의할 수도 있다. 이런 경우, 날씨 애플리케이션에 대한 파일들의 프로비져닝은, 미국의 동부에서 브로드캐스트될 와이드 멀티플렉스 상의 파이프 X 상에서는 /weaApp/East/ 이고, 미국의 서부에서 브로드캐스트될 와이드 멀티플렉스 상의 파이프 Y 상에서는 /weaApp/West/ 일 것이다. 여러 실시형태들에서, (예컨대, 낮은 레이턴시 애플리케이션 파일들의 경우) 우선순위 파이프들일 수도 있다. 여러 실시형태들에서, 다수의 파이프들은 상이한 파일 사이즈들 및 레이턴시 요구사항들 (예컨대, 15 분, 1 분, 및 30 초) 을 목표로 할 수도 있다. 여러 실시형태들에서, 파일 수취 시스템은 파이프 프로비져닝 정보에 액세스할 수도 있다. 여러 실시형태들에서, 브로드캐스트할 파일들을 수신하자 마자, 파일 수취 시스템은, 프로비져닝되는 지리적 도달거리 및 정책에 기초하는 적합한 파이프 상에서; 또는 레이턴시 요구사항을 보장하기에 가장 적합한 파이프 상에서, 파일들을 스케쥴링할 수도 있다. 여러 실시형태들에서, 파일 수취 시스템은 파일들을 그 파일의 사이즈에 기초하여 스케쥴링할 수도 있다. 예를 들어, 파일 수취 시스템은 낮은 대역폭 파이프를 고르거나 또는 송신을 낮은 데이터 레이트에서 스케쥴링하는 굵은 파이프 상에서의 흐름 ID 를 선택할 수도 있다. 일 실시형태에서, 파일 수취 시스템은 도 82a 및 도 82b 에 도시된 바와 같이 굵은 파이프 상에서 더 큰 파일의 송신을 분할할 수도 있다. 이런 따로 떨어진 송신은 도 82b 에 도시된 바와 같이 파일에 대한 송신 윈도우를 다른 파일들의 송신에 의해 분리되는 다수의 따로 떨어진 윈도우들에 끼어 들어가게 할 수도 있다. 여러 실시형태들에서, BSM 은 이런 따로 떨어진 송신들을 기술하기 위해서 피쳐들 및 정보를 포함할 수도 있다. 여러 실시형태들에서, 수신기 디바이스는 상이한 따로 떨어진 윈도우들 사이로부터 파일들을 수집하도록 구성될 수도 있다.
따라서, 여러 실시형태들에서, 파일 수취 시스템은 프로비져닝과 입력 파라미터들의 조합에 기초하여, 파일들을 동시에 (상이한 파이프들에서) 스케쥴링하려고 시도하는 (예컨대, 상이한 무선 캐리어들의 디바이스들에 이용가능한 파일들이 동시에 브로드캐스트될 수 있는) 스케쥴러를 포함할 수도 있다. 이의 대안으로, 스케쥴러는 동시에 송신될 수도 있는 파일들의 다수의 송신들을, 제 1 송신에서 동시발생 파일들의 하나를 수신하는 것을 선택하는 디바이스들로 하여금 여전히 제 2 송신 상에서 다른 파일을 수신가능하게 하는 방법으로서, 계획할 수도 있다.
여러 실시형태들에서, 파일 수취 시스템은 파일들을 각 파일의 데이터 파이프의 브로드캐스트 도달거리 (즉, 파일 전달 파이프들이 수신될 수 있는 지리적인 영역) 에 기초하여 프로비져닝할 수도 있다. 즉, 이들 파일 전달 능력들을 이용하는 애플리케이션들 및 서비스들은 여러 지리적인 고려사항들을 가질 수도 있다. 예를 들어, 파일 시스템 추상화를 이용하는 날씨 애플리케이션은 예보 파일이 적합한 영역들을 식별하는 파일 이름들 및 디렉토리들을 정의할 수도 있다. 따라서, 파일 수취 시스템은 파일 전달 파이프가 파일들을 표시될 영역으로 전달할 것인지 여부에 기초하여 각각의 날씨 애플리케이션 파일을 특정의 파일 전달 파이프들에 프로비져닝하기 위해 날씨 애플리케이션 파일 이름들을 이용할 수도 있다. 예를 들어, 파일 디렉토리 스트링 "/weaApp/East/NYC/" 을 갖는 파일은 미국의 동부에서 브로드캐스트될 와이드 멀티플렉스 내 파일 전달 파이프로 안내될 수도 있는 반면, 파일 디렉토리 스트링 "/weaApp/West/LA/" 을 갖는 파일은 미국의 동부에서 브로드캐스트될 와이드 멀티플렉스 내 파일 전달 파이프로 안내될 수도 있다.
정책 고려사항들은 또한 어떻게 파일들이 특정 세트의 파일 전달 파이프들로 프로비져닝되는지를 정의하는데 이용될 수도 있다. 예를 들어, 비디오 클립 전달 애플리케이션은 ABC 채널들 ABC 및 Disney 상의 비디오 클립들의 파일들에 대해 "/clipApp/ABC/abc/" 및 "/clipApp/ ABC/Disney/", 한편, ESPN 채널들 상의 비디오 클립들의 파일들에 대해 "/clipApp/ESPN/espn/" 및 "/clipApp/ESPN/espn2/"와 같은, 비디오 클립들의 소스에 따라서, 파일 디렉토리들에서의 그의 파일들을 편성할 수도 있다. 그렇게 편성되면, 정책 고려사항들은, ABC 로부터의 파일들이 파일 전달 파이프 1 상으로 프로비져닝되어야 하는 반면, ESPN 비디오 클립 파일들은 파일 전달 파이프 2 상으로 프로비져닝되어야 한다고 안내할 수도 있다.
특정의 파일 전달 파이프들로의 파일들의 프로비져닝은 또한 시간 다이버시티 요구사항들에 기초할 수도 있다. 예를 들어, 작은 파일들은 더 높은 수신 신뢰성이 가능하도록, 재송신들 사이의 일부 시간 분리를 갖는 다수의 시간들에서 송신되거나, 또는 더 낮은 데이터 레이트들에서 더 긴 시간 기간들에 걸쳐서 송신될 수도 있다.
여러 실시형태들, 파일 수취 시스템은 파일 전달 파이프 프로비져닝 정보에 액세스할 수도 있다. 전송을 위한 파일들을 브로드캐스트 네트워크를 통해서 수신하자 마자, 파일 수취 시스템은 지리적인 도달거리 및 정책 고려사항들에 기초하여 수신된 파일들을 적합한 파일 전달 파이프로 프로비져닝할 수도 있다. 추가적으로 또는 이의 대안으로, 파일 수취 시스템은 그 수신 파일들에 특정된 레이턴시 요구사항이 만족되는 것을 보장하기 위해서, 수신된 파일을 파일 전달 파이프들로 프로비져닝할 수도 있다. 추가적으로 또는 이의 대안으로, 파일 수취 시스템은 파일의 사이즈에 기초하여 수신된 파일들을 파일 전달 파이프들로 프로비져닝할 수도 있으며, 낮은 대역폭 파이프를 고르거나 또는 높은-대역폭 ("굵은") 파일 전달 파이프 상에서 흐름 ID 를 선택하고, 낮은 데이터 레이트 송신을 특정하는 것이 도 81c 에 도시된다.
게다가, 파일 수취 시스템은 도 82b 에 도시된 바와 같이, 큰 파일이 다수의 따로 떨어진 송신 윈도우들에 끼어 들어가서 사이에서 다른 더 작은 파일들이 송신될 수 있도록, 따로 떨어진 방법으로, 송신을 위한 큰 파일들을 스케쥴링할 수도 있다. 따로 떨어진 송신 윈도우들의 편성에 관한 정보는, 수신기 디바이스들로 하여금 상이한 따로 떨어진 브로드캐스트 윈도우들로부터 파일 부분들을 수신하고 수신 시 그 파일 부분들을 원래 파일로 재조합할 수 있도록 하기 위해서, 브로드캐스트 스케쥴 메시지에 포함될 수도 있다. 파일 전달 파이프 데이터 레이트 및 각각의 파일의 사이즈는 특정의 파일 전달 파이프 내에서 스케쥴링되는 모든 파일들에 대해 브로드캐스트 윈도우를 정의하는데 이용될 수도 있다.
도 83a 는 일 실시형태에 따른, 수신된 파일들을 파일 전달 파이프들에 할당하기 위해, 파일 수취 시스템 내에서 구현될 수도 있는 예시적인 방법 (8300) 을 도시한다. 방법 (8300) 의 단계 (8302) 에서, 파일 수취 시스템은 대역폭 특성들 (예컨대, 데이터 레이트) 및 정책 제한들과 같은 파일 전달 파이프 식별자들을 결정할 수도 있다. 단계 (8304) 에서, 파일 수취 시스템은 이용가능한 파일 전달 파이프들에 관한 이 지식을 이용하여, 수신된 파일들을 특정의 파일 전달 파이프들에 할당할 수도 있다. 위에서 설명한 바와 같이, 전달 파이프들에의 파일들의 이 할당은 다수의 커버리지 영역들 (예컨대, 파일들이 목표된 수신기 디바이스들을 포괄하는 지리적인 영역으로 전달되는 것을 보장하기 위해서), 파일 레이턴시 제한들 (즉, 파일 긴급성), 파일 사이즈, 파이프 데이터 레이트, 및 다른 정책 고려사항들에 기초할 수도 있다. 일단 파일들이 특정의 전달 파이프들에 할당되면, 단계 (8306) 에서, 파일 수취 시스템은 전송의 요청된 품질에 따라서, 각각의 파일 전달 파이프에 의해 운반될 파일들에 대한 브로드캐스트 스케쥴들 (즉, 브로드캐스트 윈도우들) 을 결정할 수도 있다. 위에서 설명한 바와 같이, 브로드캐스트 스케쥴들은 각각의 파일에 대한 브로드캐스트 지속기간에 기초할 수도 있으며, 이 지속기간은 파일 사이즈를 파일 전달 파이프 데이터 레이트로 나누어서 결정될 수도 있다. 파일들은 브로드캐스트 스케쥴링 기간 내에서 그들의 상대적 긴급성에 기초하여, 예컨대, 더 긴급한 파일들을 그 기간보다 더 빨리 브로드캐스트함으로써, 브로드캐스트를 위해 스케쥴링될 수도 있다. 단계 (8308) 에서, 파일 수취 서비스는 브로드캐스트 스케쥴 메시지에 파일 전달 파이프 ID 를, 파일 식별자들, 파일 브로드캐스트 윈도우들, 파일 파라미터들 등과 함께, 포함시킬 수도 있다. 단계 (8310) 에서, 파일 수취 시스템은 브로드캐스트 시스템으로 하여금 브로드캐스트 스케쥴 메시지를 브로드캐스트 스케쥴 흐름에서 브로드캐스트하도록 지시할 수도 있으며, 단계 (8312) 에서, 브로드캐스트 시스템으로 하여금, 파일들을 식별된 파일 전달 파이프들을 통해서 그 브로드캐스트 스케쥴 메시지에 특정된 브로드캐스트 윈도우들에 따라서 송신하는 것을 개시하도록 할 수도 있다.
도 83b 는 송신을 위한 파일들을 다수의 파이프들에 걸쳐서 스케쥴링하는 것을 지원하는 스케쥴러에 대한 예시적인 방법 (8350) 을 도시한다. 이런 스케쥴러는 선택적으로 파일들이 다수의 파이프들에 걸쳐서, 파일 수취 시에 파일 수취 프로세스의 부분으로서 제공되는 스케쥴 제약들에 따라서, 동시에 송신될 수 있도록 한다. 멀티-파이프 스케쥴러는, 파일의 단일 인스턴스가 멀티-파이프들에 걸쳐서 스케쥴링되는 비-중첩하는 상황들, 상이한 파일들의 2 개의 인스턴스들이 중첩하는 중첩 멀티-파일들, 및 엄격한 송신 데드라인들을 가진 파일들을 푸시하거나 또는 상이한 레인들에서 동일한 파일의 상이한 인스턴스들을 전송하는데 사용될 수도 있는, 동일한 파일의 2 개의 인스턴스들이 중첩하는, 중첩 단일-파일 경우들을 포함한, 다수의 중첩하는 경우들을 해결할 수도 있다. 도 83b 을 참조하면, 단계 (8352) 에서, 멀티-파이프 스케쥴러는 잔여 파일들 (R) 의 세트를 시작 시간에 계산하고, 그 잔여 파일들로부터 삭제된 파일들을 제거하고, 추가적인 파일들을 잔여 파일들에 포함시키고, 디렉토리 파일들을 계산하고, 그들을 그 잔여 파일들 내에 포함시킬 수도 있다.
단계 (8354) 에서, 스케쥴러는 스케쥴링될 각각의 디렉토리 및 파일의 제 1 인스턴스에 대해 스케쥴 윈도우 (SW) 를 계산할 수도 있다. 그 후, 단계 (8356) 에서, 스케쥴러는 시간적으로 가장 이른 스케쥴 윈도우를 가진 이용가능한 파일 인스턴스 K 를 선택하여, 디렉토리 정보 파일들을 위해서 속박들 (ties) 을 끊을 수도 있다. 그 후, 단계 (8358) 에서, 스케쥴러는 현재 스케쥴링 제약들에 대한 고스트 (ghost) 브로드캐스트 윈도우들 및 디코딩 지속기간 윈도우들을 생성할 수도 있다. 단계 (8360) 에서, 스케쥴러는 개개의 파일들을 도 83b 에 나타낸 계산들에 기초하여 선택할 수도 있다. 그 후, (8362) 단계에서, 스케쥴러는 가장 일찍 스케쥴링가능한 시간을 가진 레인 (lane) 또는 파이프를 선택할 수도 있다. 그렇게 함으로써, 스케쥴 윈도우 시작 시간과 이전에 스케쥴링된 파일 사이에 최소 갭을 갖는 레인을 선택함으로써, 동등한 것들 중에서 (among equals) 선택할 수도 있다. 이것이 속박을 초래하면, 스케쥴러는 하나를 무작위로 고를 수도 있다.
결정 단계 (8364) 에서, 스케쥴러는 브로드캐스트 윈도우가 기존 브로드캐스트 윈도우들 및 디코드 지속기간들 (있다면) 과 중첩하는지 여부를 결정할 수도 있다. 중첩하면 (즉, 결정 단계 8364 = "예"), 단계 (8366) 에서 스케쥴러는 파일 j 의 K 번째 인스턴스의 디코드 윈도우 및 시간을 중첩 전달 윈도우의 시간까지 진행시키고, 되돌아가서 단계 (8360) 에서 파일 j 의 다음 인스턴스 k 를 고를 수도 있다. 중첩하는 어떤 브로드캐스트 윈도우도 없으면 (즉, 결정 단계 8364 = "아니오"), 단계 (8368) 에서 스케쥴러는 이용가능한 파일 인스턴스들을 업데이트하고, 결정 단계 (8370) 에서 파일 j 의 K 번째 인스턴스의 디코드 윈도우 및 시간이 임의의 이용가능한 파일 인스턴스들의 스케쥴 윈도우로부터 벗어 나는지 여부를 결정할 수도 있다. 벗어 나면 (즉, 결정 단계 8370 = "예"), 단계 (8372) 에서 스케쥴러는 변경들을 제외시키고, 스케쥴링이 실패하였다고 표시할 수도 있다. 벗어 나지 않았으면 (즉, 결정 단계 8370 = "아니오"), 결정 단계 (8374) 에서, 스케쥴러는 파일 j 의 현재 인스턴스가 그 파일 디렉토리에서 직접 인스턴스들의 수보다 작은지 여부를 결정할 수도 있다. 작지 않으면 (즉, 결정 단계 8374 = "아니오"), 단계 (8380) 에서 스케쥴러는 그 파일을 잔여 파일들로부터 제거할 수도 있다. 결정 단계 (8382) 에서, 스케쥴러는 잔여 파일들이 비어 있는지 여부를 결정할 수도 있다. 잔여 파일들이 현재 비어 있으면 (즉, 결정 단계 8382 = "예"), 단계 (8384) 에서 스케쥴러는 그 변경들을 남겨 두고, 스케쥴링이 성공하였다고 표시할 수도 있다. 잔여 파일들이 비어 있지 않으면 (즉, 결정 단계 8382 = "아니오"), 스케쥴러는 단계 (8356) 로 되돌아가서, 가장 이른 스케쥴 윈도우 종료 시간을 가진 이용가능한 파일 인스턴스를 선택할 수도 있다.
인스턴스 K 가 인스턴스들의 파일 디렉토리 수보다 작다고 스케쥴러가 결정하면 (즉, 결정 단계 8374 = "예"), 단계 (8376) 에서 스케쥴러는 현재 인스턴스를 1 로 설정하고, 그 파일을 단편화하고, 다른 단편화 데드라인들을 조정할 수도 있다. 그 후, 단계 (8378) 에서 스케쥴은 단계 (8356) 으로 되돌아가서 가장 이른 스케쥴 윈도우 및 시간을 가진 이용가능한 파일 인스턴스를 선택하기 전에, 스케쥴링된 시간을 계산하고 파일 j 의 K 번째 인스턴스에 대해 스케쥴 윈도우를 계산할 수도 있다.
파일 콘텐츠 제공자는 파일들을 파일 수취 시스템에 제공하기 위해 sendFileRequest 동작을 이용할 수도 있다. sendFileRequest 동작은 송신을 위해 실행의뢰되는 파일을 (예컨대, fileFetchlnfo 을 통해서) 식별하는 메커니즘, 및 각각의 파일 또는 파일들의 그룹에 대해 상이한 전달 기준들 또는 송신 요구사항들을 정의하는 메커니즘을 포함할 수도 있다. 파일들은 파일이 브로드캐스트를 위해 취출될 수 있는 로케이션을 제공하는 콘텐츠 URL 에 기초하여 식별될 수도 있다. 파일 식별은 또한 애플리케이션 디렉토리 구조에서 그 파일에 대한 디렉토리를 나타내는데 사용될 수 있는 파일 이름 (예컨대, /itv/res/svc_5/f1.jpg), 및 그 파일을 특징화하는 파라미터들을 제공할 수도 있는 속성 리스트 (예컨대, 장르=드라마, 성별=남성; 나이=20 내지 30 등) 과 같은, 컨텍스트 (context) 를 수취될 파일에/과 추가로 할당 또는 연관시키는 추가적인 파라미터들을 식별할 수도 있다. 이들 추가적인 파라미터들은, 수신기 디바이스들 상에 실행되는 수신기 애플리케이션들로 하여금 캡쳐되어야 하는 브로드캐스트될 파일들을 식별할 수 있도록 하기 위해, 브로드캐스트 스케쥴 메시지로 전송될 수 있다.
속성 리스트가 cat.xml 로 또는 브로드캐스트 스케쥴 메시지로 직접 운반되는지 여부는 그 파일을 실행의뢰하는 애플리케이션에 의해 어떤 서비스가 요망되는지에 대한 함수이다. 실행의뢰하는 애플리케이션이, 수신기 디바이스들로 하여금 다운로드할 파일들을 더 잘 선택하도록 하기 위해서 카탈로그 파일을 사용자에게 제공하는 것과 같이, 카탈로그 파일을 관리하는 것을 선호하면, 애플리케이션은 카탈로그 파일을 관리하고, 그 카탈로그를 이용하는 방법에 관한 로직을 수신기 디바이스들에 (예컨대, 그 파일을 수신하려고 의도되는 디바이스 애플리케이션에) 제공할 수 있다. 그 애플리케이션이 덜 유능한 (capable) 수신기 디바이스들 또는 대응하는 디바이스 애플리케이션으로 구성되지 않은 수신기 디바이스들에 대해 간단한 구현을 행하는 것을 필요로 하면, 속성 리스트를 위에서 설명한 방법들을 이용하여 전달하는데 브로드캐스트 스케쥴 메시지에 의존할 수 있다.
도 84 는 여러 실시형태들을 구현하는데 적합한 수신기 디바이스 (10) 내에 구현될 수도 있는 기능적 모듈들을 도시한다. 수신기 디바이스 (10) 의 소프트웨어 모듈들은 도 84 에 도시된 소프트웨어 아키텍처와 유사한 소프트웨어 아키텍처 (8400) 로 편성될 수도 있다. 브로드캐스트 송신들은 수신기 디바이스 물리적인 계층에 의해 수신되어, FLO 전송 네트워크 모듈 (8401) 과 같은 브로드캐스트 수신기 모듈에 의해 프로세싱될 수도 있다. 파일 전송 네트워크 (8401) 에 의해 수신된 비디오 및 오디오 스트림들은 미디어 수신기 모듈 (미도시) 에 의해 프로세싱될 수도 있다. 파일 전송 네트워크 (8401) 상에서 수신되는 파일 전송 스트림들은 파일 관리기 모듈 (44) 에 제공되어 프로세싱될 수도 있으며, 이 파일 관리기 모듈은 파일 패킷들을 수신하고, 그들을 디바이스 소프트웨어 아키텍처 (8400) 내 적합한 모듈들 및 애플리케이션들로 안내하도록 기능한다. 오버헤드 데이터 스트림들은 오버헤드 데이터 획득 모듈 (8408) 에 전달될 수도 있으며, 이 오버헤드 데이터 획득 모듈은 오버헤드 데이터 패킷들을 프로세싱하고, 수신된 메타데이터 및 오버헤드 데이터를 디바이스 시스템 아키텍처 (8400) 내 적합한 모듈들로 안내하도록 기능한다. 서비스 SI 획득 모듈 (8407) 은 서비스 SI 데이터를 오버헤드 데이터 스트림들로부터 획득하고, 이 정보를 파일 전달 시스템 모듈 (44) 및 오버헤드 데이터 획득 모듈 (8408) 로 포워딩할 수도 있다. 수신된 서비스 SI 데이터로부터, 파일 전달 시스템 모듈 (44) 은 상호작용성 리소스들 데이터를 운반하는 파일 데이터 흐름들에 대해 흐름 ID 들을 결정할 수도 있다. 수신된 서비스 SI 데이터로부터, 오버헤드 데이터 획득 모듈 (8408) 은 상호작용성 시그널링 데이터를 운반하는 시그널링 흐름들을 결정할 수도 있다. 상호작용성 이벤트들을 지원하기 위해, 디바이스 소프트웨어 아키텍처 (8400) 는 사용자 인터페이스 (UI) 애플리케이션들 (8404) 과, 상호작용성 이벤트들을 수신, 관리 및 저장하는 파일 전송 네트워크 (8401) 사이의 인터페이스로서 기능하는 파일 수신 서비스 (8402) 를 포함할 수도 있다. 동시에, 상호작용성 서비스 (8402) 및 UI 애플리케이션들 (8404) 은 상호작용성 애플리케이션 (8502) 으로서 편성될 수도 있다. 사용자 인터페이스 애플리케이션 모듈 (8404) 은 다수의 상호작용성 애플리케이션들, 및 사용자 에이전트를 포함할 수도 있다.
여러 실시형태들에서, 파일 전달 서비스 모듈 (44) 은 다수의 서비스들을 디바이스 애플리케이션들에 제공할 수도 있다. 단일 파일 캡쳐 서비스는 디바이스 애플리케이션으로 하여금 단일 파일의 캡쳐를 요청하는 것을 가능하게 할 수도 있다. 이를 위해서, 디바이스 애플리케이션은 파일 전달 서비스 모듈 (44) 에 애플리케이션-특정의 파일 이름을, 예컨대 singeCapture(/itv/res/svc_5/f2.jpg) 과 같은 요청으로, 제공한다.
위에서 설명한 바와 같이, 파일 전달 서비스 모듈 (44) 에 의해 제공될 수도 있는 또 다른 서비스는 디바이스 애플리케이션으로 하여금 주어진 디렉토리 아래의 단일 파일 이름, 또는 모든 파일들의 업데이트들의 연속적인 캡쳐를 요청하는 것을 가능하게 하는 연속적인 파일 캡쳐 서비스이다. 디바이스 애플리케이션은 특정된 파일의 모든 업데이트들이 수신되어야 한다는 것을 표시하기 위해서, 캡쳐 올 요청들 (capture all requests) 에 애플리케이션-특정의 파일 이름을 특정할 수도 있다. 이 서비스에 대한 일반적인 사용은 카탈로그 파일과 같은 애플리케이션 오버헤드 파일에서의 변경들을 추적하는 것일 것이다. 예를 들어, 상호작용성 애플리케이션 카탈로그 파일의 모든 업데이트들을 수신하기 위해서, 애플리케이션은 captureAll (/itv/sig/cat.xml) 요청을 발할 수 있다. 디바이스 애플리케이션은, 디렉토리가 수신기 디바이스 상에 현재 저장되어 있지 않아 그 애플리케이션이 모든 파일들을 수신하는데 관심을 갖고 있을 때, 애플리케이션-특정의 디렉토리를 특정할 수도 있다. 대부분의 경우, 이것은 원하는 디렉토리 아래의 모든 새로운 파일들일 것이다. 예를 들어, 날씨 애플리케이션에서, 이런 요청은 NYC 서브-디렉토리 파일 이름을 가진 모든 파일들의 다운로드를 요청하는 captureAll (/weaApp/NYC/) 일 것이다. 단일 파일 캡쳐 서비스와는 달리, 캡쳐 올 서비스는 특정된 디렉토리 아래에서 그 요청된 파일 또는 새로운 파일들의 새로운 송신들을 계속 모니터링한다. 이 서비스는 새로운 파일들이 수신에 이용가능할 때, 또는 파일의 새로운 버전이 이용가능할 때 시그널링할 수 없는 파일 전송 네트워크에 의존한다. 이런 정보는 브로드캐스트 스케쥴 메시지에, 새로운 파일 이름, 또는 파일 메타데이터에 포함되는 업데이트된 버전 번호를 가진 동일한 파일 이름의 형태로, 제공될 수도 있다. 수신기 디바이스 상의 파일 전달 서비스 모듈 (44) 은 동일한 파일 모바일 시간들을 수신하는 것을, 그렇게 하는 것이 디바이스 배터리를 불필요하게 소모시킬 것이기 때문에, 회피하기 위해서, 메모리에 저장된 파일들의 버전을 계속 추적하고, 브로드캐스트 스케쥴 메시지에 제공되는 버전 정보를 추적하도록 구성될 수도 있다.
도 85 에 도시된 바와 같이, 서비스 아이콘 애플리케이션 (8501), 및 상호작용성 애플리케이션 (8502), 및 멀티-프리젠테이션 리스트 뷰 (MPV; Multi-Presentation list View) 애플리케이션 (8503) 과 같은, 디바이스 애플리케이션들은 수행될 파일 획득의 유형 (즉, captureOnce 또는 autoCapture) 과 함께 획득될 파일들을 특정할 수도 있다. 파일 이름 또는 파일 확장자를 식별하기 위해서, 디바이스 애플리케이션들은 이런 정보를 오버헤드 브로드캐스트 송신의 부분으로서 제공되는 채널 시스템 정보 (SI) (8504) 및/또는 서비스 SI (8505), (8506) 로부터 수신할 수도 있다. 일부 디바이스 애플리케이션들은 또한 가입 관리기 (8507) 에 의해 지원받을 수도 있으며, 여러 디바이스 애플리케이션들에 의해 가입되는 브로드캐스트 서비스들에의 등록 및 가입들을 관리하는 애플리케이션일 수도 있다.
파일 전달 서비스 모듈 (44) 에서 제공될 수도 있는 제 3 서비스는 디바이스 애플리케이션으로 하여금 파일의 단일 캡쳐 (singleCapture) 를 취소시키거나 또는 파일 또는 디렉토리의 연속적인 캡쳐 (captureAll) 를 취소시키도록 하는 취소 서비스이다. 활성화될 때, 취소 서비스는 파일 전달 서비스 모듈 (44) 이 원래 요청이 취소되는 것과 연관되는 파일들을 획득하려고 시도하는 것을 중지시킨다.
도 86 은 일 실시형태에 따른, 브로드캐스트를 위해 스케쥴링되는 파일들의 카탈로그에서 파일들에 대해 사용될 수도 있는 예시적인 데이터 스키마 (8600) 를 도시한다. 도 86 에 나타낸 바와 같이, 카탈로그 파일 (8601) 은 파일 이름 데이터 필드 (8603), 및 옵션적인 필터링 속성 데이터 필드 (8604), 및 옵션적인 애플리케이션 파라미터 데이터 필드 (8605) 를 자체로 포함할 수도 있는 파일 정보 (8602) 를 포함할 수도 있다. 파일 이름 데이터 필드 (8604) 는 루트 디렉토리 및 서브디렉토리들을 포함하는 파일 이름 스트링과 같은, 충분히 자격있는 추상화적인 파일 이름을 포함할 수도 있다. 옵션적인 필터링 속성 데이터 필드 (8604) 는 서브디렉토리, 파일 유형 또는 파일 확장자와 같은, 필터링에 유용한 추가 정보, 또는 다른 적합한 파일 기술 파라미터를 포함할 수도 있다. 옵션적인 애플리케이션 파라미터들 데이터 필드 (8605) 는 개개의 파일이 수신되어야 하는지 여부를 결정하는데 유용할 수도 있는, 그 데이터 파일이 의도되는 애플리케이션에 관한 정보를 포함할 수도 있다.
파일 캡쳐 서비스들을 제공하기 위해, 파일 전달 서비스 모듈 (44) 은 어느 파일들을 수신할지 및 언제 그들을 수신할지를 결정하기 위해서, 브로드캐스트 스케쥴 메시지에 제공되는 정보를 이용할 수도 있다. 도 87a 는 수신기 디바이스의 프로세서 또는 통합된 수신기/프로세서 칩이 singleCapture 서비스 파일 다운로드 요청을 디바이스 애플리케이션으로부터 수신하는 것에 응답하여 구현할 수도 있는 일 실시형태 방법 (8700a) 을 도시한다. 방법 (8700a) 의 단계 (8702) 에서, 수신기 디바이스의 프로세서는 파일 다운로드 요청을 디바이스 애플리케이션 (즉, 수신기 디바이스의 프로세서 내에서 동작하는 애플리케이션) 으로부터 수신할 수도 있다.
위에서 설명한 바와 같이, 브로드캐스트 스케쥴 메시지는 브로드캐스트될 파일의 이름을, 파일 전달 서비스 모듈 (44) 이 수신을 위한 파일들을 선택하기 위해서 필요로 하는 정보와 함께, 포함한다. 따라서, 단계 (8704) 에서, 프로세서 내에서 구현되는 파일 전달 디바이스 모듈 (44) 은 수신된 브로드캐스트 스케쥴 메시지들을 모니터링한다. 단계 (8704) 는 브로드캐스트 스케쥴 메시지를 오버헤드 흐름으로부터 수신하기에 충분히 길게 수신기 디바이스의 수신기 회로를 잠깐 동안 활성화할 뿐만 아니라, 그의 포함된 정보를 획득하기 위해서 그 수신된 브로드캐스트 스케쥴 메시지를 프로세싱하는 것을 포함할 수도 있다. 단계 (8706) 에서, 프로세서는 (그들의 파일 확장자들을 포함한) 브로드캐스트될 파일 또는 파일들의 이름을 획득할 수도 있다. 위에서 언급한 바와 같이, 파일 확장자들이었던 이런 파일 이름들이 브로드캐스트 스케쥴 메시지의 브로드캐스트 스케쥴 레코드들 (BSRs) 내에 포함될 수도 있다. 단계 (8708) 에서, 프로세서는 브로드캐스트 스케쥴 메시지로부터 획득된 파일 이름 또는 파일 확장자들 스트링을 단계 (8702) 에서 제공되는 요청 디바이스 애플리케이션에 의해 특정되는 파일 이름 또는 파일 확장자와 비교할 수도 있다. 결정 단계 (8710) 에서, 프로세서는 브로드캐스트 스케쥴 메시지에 특정된 파일 이름 또는 파일 확장자와, 디바이스 애플리케이션에 의해 요청되는 파일 이름 또는 파일 확장자 사이에 매칭이 있는지 여부를 결정할 수도 있다. 매칭이 없으면 (즉, 결정 단계 8710 = "아니오"), 단계 (8711) 에서 프로세서는 브로드캐스트 스케쥴 메시지가 업데이트될 브로드캐스트 스케쥴 메시지에서 표시되는 시간까지 대기할 수도 있다. 위에서 설명한 바와 같이, 동일한 브로드캐스트 스케쥴 메시지는 업데이트 시간까지 반복적으로 브로드캐스트될 수도 있다. 브로드캐스트 스케쥴 메시지에, 업데이트된 메시지가 브로드캐스트될 시기를 특정함으로써, 수신기 디바이스들은 새로운 브로드캐스트 스케쥴 메시지가 송신될 때까지 그들의 수신기 회로를 비활성화된 채로 그대로 둠으로써, 배터리 전력을 절약할 수 있다. 현재 시간이 식별 브로드캐스트 스케쥴 메시지 업데이트 시간과 같을 때, 프로세서는 단계 (8704) 로 되돌아가서, 그 업데이트된 브로드캐스트 스케쥴 메시지를 수신하여 프로세싱할 수도 있다.
브로드캐스트 스케쥴 메시지에 특정된 파일 이름 또는 파일 확장자가 단계 (8702) 에서 디바이스 애플리케이션에 의해 특정되는 파일 이름 또는 확장자와 매칭한다고 프로세서가 결정하면 (즉, 결정 단계 8710 = "예"), 프로세서는 매칭 파일의 수신을 스케쥴링할 수도 있다. 이것은, 단계 (8712) 에서 브로드캐스트 스케쥴 메시지로부터 그 매칭된 파일에 대한 브로드캐스트 시간 및 수신 정보 (예컨대, 흐름 ID, IP 어드레스에 의한 IP 흐름 식별자, 및/또는 UDP 포트 번호) 를 획득하고, 단계 (8714) 에서 브로드캐스트 시간에 기초하여 그 매칭된 파일의 수신을 스케쥴링함으로써, 달성될 수도 있다. 매칭된 파일의 수신을 스케쥴링하는 것은, 결정 단계 (8716) 에서, 예를 들어, 현재 시간이 메모리에 저장된 시간과 매칭할 때 파일 수신 루틴을 개시하기 위한 인터럽트를 발생하기 위해서 현재 시간과 빈번히 비교되는 메모리 레지스터에 그 획득된 브로드캐스트 시간을 저장함으로써, 달성될 수도 있다. 한편, 현재 시간이 스케쥴링된 브로드캐스트 시간에 매칭하지 않으면 (즉, 결정 단계 8716 = "아니오"), (단계 (8704) 내지 단계 (8711) 에 대해 위에서 설명한 바와 같이) 브로드캐스트 스케쥴 메시지들의 수신 프로세싱이 병렬로 지속할 수도 있기 때문에, 프로세서는 단계 (8711) 를 실행하여 브로드캐스트 스케쥴 메시지가 업데이트되는 시간을 대기할 수도 있다. 스케쥴링된 브로드캐스트 시간 직전에 (즉, 결정 단계 8716 = "예" 일 때), 프로세서는 단계 (8718) 에서 수신기 디바이스 수신기 회로를 웨이크업하고, 단계 (8720) 에서 그 선택된 파일을 광고된 전송 스트림으로부터 수신할 수도 있다. 단계 (8720) 의 부분으로서, 프로세서 내에서 동작하는 파일 전달 서비스 모듈 (44) 은 위에서 설명한 바와 같이 그 수신된 파일을 메모리에 저장하고, 일부 실시형태들에서는, 그의 버전 번호를 표시할 수도 있다. 단계 (8722) 에서, 프로세서 내에서 동작하는 파일 전달 서비스 모듈 (44) 은 그 수신된 파일을 그 요청 애플리케이션으로 원래 애플리케이션 요청을 수행하는 위에서 설명한 프로세스들을 이용하여, 전달할 수도 있다. 파일을 수신한 후, 프로세서는 수신기 회로를 비활성화하고, 단계 (8711) 로 되돌아가서, 브로드캐스트 스케쥴 메시지가 업데이트될 시간을 대기할 수도 있다.
디바이스 애플리케이션이 singleCapture 서비스를 이용한 파일 다운로드를 요청할 때, 단계 (8702) 에서 하나 이상의 특정의 파일 이름들은 디바이스 애플리케이션에 의해 특정될 수도 있다. 일단 그 특정된 파일이 수신되어 메모리에 저장되거나, 및/또는 요청 디바이스 애플리케이션으로 전달되면, 파일 다운로드 요청은 동일한 파일의 후속 브로드캐스트들이 수신되지 않게, 프로세서에 의해 취소될 수도 있다.
브로드캐스트 네트워크를 통해서 전송되는 파일들에 관한 정보가 전송을 위한 파일들을 실행의뢰하는 헤드엔드 측 애플리케이션에 의해 제공되는 카탈로그 파일에서 식별될 때, 카탈로그 파일은 도 86 에 나타낸 데이터 스키마에서 식별되는 정보를 포함할 수도 있다. 이런 카탈로그 파일에 제공되는 정보를 이용하여, 디바이스 애플리케이션은 파일 시스템 추상화가 이용될 때의 그들의 파일 이름들, 및/또는 각각의 파일과 연관될 수도 있는 필터링 속성들에 기초하여, 캡쳐를 위한 파일들을 특정할 수도 있다. 그 후, 수신기 디바이스 상의 애플리케이션은 속성들이 수신기 디바이스 또는 사용자의 속성들에 매칭하는 다운로드 파일들에 대해서 선택하기 위해서, 그 수신된 카탈로그 파일을 (수신기 디바이스 사용자의 성별 및 나이와 같은) 애플리케이션에 알려져 있는 정보와 함께, 이용할 수도 있다. 파일 이름이 그 카탈로그 파일에 포함될 수도 있기 때문에, 디바이스 애플리케이션은 파일의 캡쳐를 singleCapture 동작에서의 그의 파일 이름을 이용하여 요청할 수도 있다.
도 87b 는 캡쳐 올 서비스를 달성하기 위해 수신기 디바이스의 프로세서 내에서 구현될 수도 있는, 일 실시형태 방법 (8700b) 을 도시한다. 디바이스 애플리케이션이 파일 다운로드를, 특정의 파일에 대한 모든 업데이트들을 계속 수신하는 것과 같은, 연속적인 캡쳐 요청 서비스 (예컨대, autoCapture(itv/sig/cat.xml) 또는 autoCapture(itv: 1)) 를 이용하여 요청할 때, 일단 매칭 파일이 수신되어 메모리에 저장되면 파일 다운로드 요청이 자동적으로 취소되지 않는다는 점을 제외하고는, 도 87a 를 참조하여 위에서 설명한 동작들이 실행될 수도 있다. 파일 다운로드 요청이 활성화된 채로 유지하므로, 프로세서는 파일 확장자 기준들에 매칭하는 파일들을 계속 수신할 수도 있다. (파일들이 신뢰성 있는 수신을 보장하기 위해서 다수의 시간들에 브로드캐스트될 수도 있기 때문에) 여분의 파일들의 수신을 피함으로써 배터리 전력을 절약하기 위해서, 프로세서는 브로드캐스트 스케쥴 메시지에 특정된 매칭된 파일에 대한 파일 이름 또는 버전 번호를 메모리에 저장된 파일 이름 및/또는 버전 번호와 비교하는 추가적인 결정 단계 (8713) 를 수행할 수도 있다. 그 매칭된 파일이 메모리에 저장된 파일과 동일한 파일 이름, 파일 ID/엘리먼트 ID)또는 버전 번호를 가지면 (즉, 결정 단계 8713 = "예"), 그 파일을 다시 수신할 필요가 없으며, 따라서 프로세서는 단계 (8711) 로 진행하여, 브로드캐스트 스케쥴 메시지가 업데이트될 때까지 대기할 수도 있다. 그러나, 브로드캐스트 스케쥴 메시지에서 식별되는 매칭된 파일의 파일 이름, 파일 ID/엘리먼트 ID 또는 버전 번호가 메모리에 저장된 것과는 다른 상이한 파일 이름 또는 버전 번호를 가지면 (즉, 결정 단계 8713 = "아니오"), 프로세서는 도 87a 를 참조하여 위에서 설명한 바와 같이 단계 (8712) 내지 단계 (8722) 로 진행함으로써, 식별된 파일의 수신을 스케쥴링하는 것을 진행할 수도 있다. 파일 전달 요청이 그 매칭하는 파일의 수신 시에 자동적으로 취소되지 않기 때문에, 프로세서 내에서 동작하는 파일 전달 서비스 모듈 (44) 은 그 요청이 활성인 채로 유지하는 한, 계속해서 브로드캐스트 스케쥴 메시지를 모니터링하고 모든 매칭하는 파일 업데이트들을 캡쳐할 수도 있다.
브로드캐스트 시스템, 유니캐스트 네트워크, 또는 브로드캐스트와 유니캐스트 네트워크들의 조합을 통한 파일 전달을 위한 파일 이름 추상화들의 사용은 전개하기에 간단한 파일 전달 서비스를 가능하게 한다. 이런 통신 네트워크들을 이용하는 애플리케이션들은 친숙한 파일 확장자 컨셉들이 이용될 수도 있기 때문에 개발하는데 더 용이할 수 있다. 여러 실시형태들은 파일들을 수취하기 위한 헤드엔드 시스템 (예컨대, 파일 수취 시스템) 을 제공하고 브로드캐스트를 위한 파일들을 파일 시스템에서의 경로들의 부분으로서 명명함으로써, 기존 브로드캐스트 시스템들 내에 구현될 수도 있다. 파일 수취 시스템은 파일들을 수취하기 위한 인터페이스들을 제공하고, (브로드캐스트 네트워크를 통해서 송신되면) 파일 전송 적정 시기들을 스케쥴링하고, 브로드캐스트 네트워크에서의 브로드캐스트 스케쥴 메시지 오버헤드 흐름과 같은 일부 솔루션 특정의 시그널링 메커니즘을 통해서, 이용가능한 파일들을 디바이스들로 광고한다. 수신기 디바이스들 내에서, 파일 전달 서비스 모듈은, 소프트웨어 업데이트에서와 같이, 중복 파일 수신들을 피하고 파일 업데이트들을 검출하기 위해서, 헤드엔드 시그널링을 이해하고, 브로드캐스트 파일들을 캡쳐하라는 디바이스 애플리케이션 요청들을 수신할 뿐만 아니라, 적합한 상태 정보를 유지하도록 구현될 수도 있다. 이런 시스템에서, 브로드캐스트 서비스로부터의 수신을 위한 파일들을 특정하기 위해서 애플리케이션들이 오직 그들의 루트 디렉토리 및 애플리케이션-특정의 서브디렉토리 편성만을 인식하는 것을 필요로 하기 때문에, 디바이스 애플리케이션 개발이 단순화된다. 따라서, 애플리케이션들은 파일들이 추가적인 발견 메커니즘들 또는 브로드캐스트 시스템의 지식, 예컨대 시스템 정보를 요함이 없이 캡쳐되는 것을 요청할 수 있다. 파일 캡쳐 요청은 등록 프로세스를 통해서 또는 애플리케이션-대-파일 전달 프레임워크 인터페이스 또는 API 를 통해서 이루어질 수도 있다. 애플리케이션 개발자들에 있어, 이 파일 확장 패러다임은 파일 시스템 상의 파일들에의 액세스를 요청하거나, 또는 파일들을 파일 전송 프로토콜을 통해서 FTP 로서 페치하는 것과 유사하다.
오버헤드 정보를 브로드캐스트 스케쥴 메시지의 형태로 송신하는 브로드캐스트 파일 전송 네트워크는 브로드캐스트될 파일들에 관한 정보 뿐만 아니라, 컨텍스트를 각각의 파일에 연관시키는 추가 정보 (예컨대, 애플리케이션 디렉토리 공간 상의 디렉토리 이름, 또는 속성 특성들의 리스트 등) 를 수신 디바이스들에 제공한다. 이런 컨텍스트 정보는 광고되는 상이한 파일 브로드캐스트들로부터의 수신을 위해 수신기 디바이스 상에 상주하는 서비스 또는 애플리케이션에 관련되는 그들 파일들을 선택하기 위해서 수신 디바이스들에 의해 사용될 수도 있다. 브로드캐스트 스케쥴 메시지에 제공되는 파일 ID 및/또는 엘리먼트 ID 정보는 또한 수신기 디바이스들로 하여금, 파일이 새로운 파일인지 또는 이전에 수신된 파일에 대한 업데이트인지를 결정할 수 있게 할 수도 있다. 브로드캐스트 스케쥴 메시지 구성체 (construct) 는 애플리케이션 파일 이름들 또는 속성 스트링들의 별칭을 기술하는 것을 지원한다. 브로드캐스트 스케쥴 메시지 구성체 (construct) 는 또한 전송되는 파일의 유형을, 예컨대, 단일 파일이냐 파일들의 번들들이냐를 식별하는 것을 가능하게 한다. 브로드캐스트 스케쥴 메시지, 또는 옵션으로는, 파일 전달 카탈로그 시스템에 이용가능한 정보를 이용하여, 수신기 디바이스들은, 수신을 위한 관심 파일들을 수신을 위해 식별할 수 있으며 (즉, 필터링하고 선택할 수 있으며), 그 결과, 수신기 회로가 오직 수신기 디바이스들 상에 상주하는 애플리케이션들에 유용한 그들 파일들만을 수신하도록 활성화된다.
파일 수취 시스템은 파일 콘텐츠 제공자들로 하여금, 파일들을 식별하여 특징화하고, 어떻게 시기 적절하게 그리고 어떻게 신뢰성있게 파일들이 공유된 그리고 종종 희귀한 브로드캐스트 리소스들을 통해서 운반될 필요가 있는지에 영향을 미치는 송신 요구사항들을 정의할 수 있게 함으로써, 브로드캐스트 네트워크를 통한 전송을 위한 파일들의 수취를 가능하게 한다. 시의성 및 수신기 배터리 제약들은 브로드캐스트 시스템이 오직 적은 양의 스케쥴 정보를 한번에 광고하는 것을 필요로 할 수도 있다. 파일 수취 시스템의 스케쥴링 기능은 그들 요구사항들을 이전에 수취된 파일들의 파일 송신 요구사항들에 대해서 균형을 유지함으로써 새로운 파일 송신 요구사항들을 수용할 수도 있다. 또, 파일 수취 시스템은 새로운 스케쥴 정보의 흐름이, 예컨대, 규칙적으로 업데이트되는 브로드캐스트 스케쥴 메시지들의 형태로, 수신기 디바이스들에 시기적절하게 이용하게 되는 것, 및 파일들이 그 광고된 스케쥴에 따라서 송신되는 것을 보장하도록 구성될 수도 있다.
제한된 브로드캐스트 리소스들 내에서 파일들의 효율적인 송신을 가능하도록 하기 위해서, 파일 전달은 파일 전달 파이프들에, 브로드캐스트 네트워크 상에서의 파일들의 전송을 위해 리소스 할당을 개념적으로 캡쳐하는 메커니즘으로서 편성될 수도 있다. 애플리케이션들이 위에서 설명한 파일 시스템 추상화를 이용할 때 애플리케이션 파일들을 파이프들에 바인딩하기 위해 다수의 파이프 구성들 및 프로비져닝을 조정하도록 상이한 전략들이 구현될 수도 있다. 스케쥴링 알고리즘들은 애플리케이션 전달 요구사항들을 브로드캐스트 네트워크의 대역폭 및 동작 조건들 내에서 만족시키기 위해서 상이한 파이프 구성들을 이용할 수도 있다.
여러 실시형태들은 파일들을 브로드캐스팅하고 수신하고 처리하는데 있어 다수의 이점들 및 유용한 특징들을 제공한다. 이들은 파일들을 브로드캐스트 배포 시스템을 통해서 전달할 때 파일 시스템 추상화를 이용하여 파일들을 명명하는 메커니즘, 브로드캐스트 전달 시스템을 통해서 수취 및 전송을 위해 파일들을 실행의뢰할 때 파일들을 식별하는 수단으로서 파일 이름들을 시그널링하는 메커니즘, 이용가능한 파일들을 파일 시스템 추상화를 통해서 기술하는 브로드캐스트 전달 시스템으로부터 파일들의 다운로드를 요청하는 메커니즘들, 및 그 애플리케이션과 연관되는 디렉토리 및 서브디렉토리들에 기초하여 파일들을 파일 전달 애플리케이션에 바인딩하는 메커니즘을 포함한다.
파일 전달 프레임워크 (FDF) 는 파일들을 디바이스들에 백그라운드에서 전달하는 유연한 메커니즘을 제공한다. 다음의 주요 설계 목표들을 갖는다: 유연한 파일 브로드캐스트 스케쥴 -- 파일 브로드캐스트 윈도우들이 동적으로 스케쥴링되어 디바이스들에 시그널링될 수 있다; 스케일링가능한, 많은 수의 애플리케이션들 -- 시스템에서 데이터 흐름들의 수를 상당히 감소시키기 위해서 다수의 애플리케이션들로부터의 데이터를 동일한 흐름으로 멀티플렉싱할 수 있다; 및 전력 효율 -- 사용자가 관심을 가진 데이터를 선택적으로 수신할 때에만 디바이스가 오직 에너지를 소모한다.
브로드캐스트 스케쥴 메시지는 파일들을 서비스들 또는 애플리케이션들에 파일 이름들, 속성들, 및 애플리케이션/서비스 식별자들을 통해서 연관시키는 브로드캐스트 네트워크를 통해 파일들의 송신을 위한 스케쥴을 광고하는 메커니즘을 제공한다. 브로드캐스트 스케쥴 메시지는 또한 브로드캐스트되는 파일이 새로운 파일, 업데이트된 파일 또는 반복된 파일인지 여부를 식별할 수도 있으며, 그 결과, 수신기 디바이스들은 파일의 단일 또는 모든 업데이트된 버전들을 캡쳐하도록 구성될 수 있다. 브로드캐스트 스케쥴 메시지는 파일이 브로드캐스트될 수도 있는 시기의, 브로드캐스트 윈도우들 및 가능한 다수의 인스턴스들의 식별에 더해서, 파일이 수신될 수 있는 전송 스트림을 시그널링할 수도 있다. 브로드캐스트 스케쥴 메시지는 또한 브로드캐스트 스케쥴 메시지가 새로운 스케쥴 정보로 업데이트될 시기를 식별할 수도 있다. 브로드캐스트 스케쥴 메시지는 또한 애플리케이션/서비스 ID 들 및 전송되는 파일들에 대한 별칭 정보를 기술할 수도 있다. 브로드캐스트 스케쥴 메시지는 콘텐츠 신선도를 수신기 디바이스들에 대한 배터리 영향에 대해 균형을 유지하기 위해서 오직 파일 브로드캐스트 스케쥴 정보의 변경불가능한 부분만을 한번에 광고할 수도 있다.
여러 실시형태들은 또한 수신기 디바이스들로 하여금 브로드캐스트 네트워크 전송 기술, 사용되는 주파수, 주어진 주파수에서의 전송의 부분, 및 브로드캐스트 기술을 통해서 송신되는 파일들에 대해 전달 스케쥴 정보를 제공하는 그 기술 및 주파수에서의 전송 스트림을 발견할 수 있게 하는 메커니즘을 제공한다. 수신기 디바이스들은 브로드캐스트 스케쥴 메시지에 제공되는 광고된 스케쥴을 이용하여, 수신을 위한 파일들을 그 파일이 연관되는 서비스 또는 애플리케이션, 및 그 파일 새로운지 또는 이전에 수신된 파일에 대한 업데이트인지 여부에 따라서 선택할 수도 있다.
여러 실시형태들은 상이한 수신기 제약들을 해결하거나, 또는 트래픽 분리를 제공하기 위해서, 상이한 전달 및 상이한 지리적 커버리지 요구사항들의 파일들의 멀티플렉스된 전송을 위한 전용 브로드캐스트 송신 리소스들, 및 상이한 전달 요구사항들, 상이한 파일 전달 파이프들을 통한 파일 전송에 이용가능한 리소스들의 파티셔닝을 포함할 수도 있다. 상이한 종류들의 파일들이 상이한 전달 요구사항들, 상이한 수신기 제약들을 만족시키거나, 또는 트래픽 분리를 제공하기 위해서, 파일 전달 파이프들의 세트에 바인딩될 수도 있다. 상이한 파일들을 운반하는 전송 스트림들은 파일 전송을 위한 전용 리소스들이 그 한계에 이용되도록 멀티플렉스될 수도 있다. 전송 스트림들은 상이한 불연속 송신들을 통한 파일의 전송이 더 작은 파일들의 인터리빙 (interleaving) 을 고려할 수 있도록 추가로 구성될 수도 있다. 파일들의 종류들은 상이한 전달 요구사항들, 상이한 수신기 제약들을 만족시키거나, 또는 트래픽 분리를 제공하기 위해서, 리소스들의 세트에 바인딩될 수도 있다. 파일들은 파일 전달 파이프들에 파일 전달 요구사항들, 이용가능한 파일 전달 파이프들, 리소스들의 세트에의 파일들의 바인딩 종류들에 기초하여 할당될 수도 있다. 전송자 측 상의 애플리케이션들 및 서비스들은 브로드캐스트 시스템의 파일 전달 서비스를 이용하여, 오버헤드 파일, 그 애플리케이션이 브로드캐스트 또는 다른 (예컨대, 유니캐스트) 전송에 이용가능하게 하는 모든 파일들을, 애플리케이션-특정의 속성들과 함께 리스트하는 카탈로그 파일을 구성할 수도 있다.
파일 수취 시스템은 파일 콘텐츠 제공자들로부터의 카탈로그 파일들을 다른 애플리케이션 특정의 파일들과 함께 수신하여 전송할 수도 있으며, 수신기 디바이스들은 수신을 위한 파일들을 이런 카탈로그 파일들에서의 정보에 기초하여 선택하도록 구성될 수도 있다. 수신기 디바이스들 상에 상주하는 애플리케이션들은 업데이트된 카탈로그 파일을 이용하여, 관심 파일들을 카탈로그에 리스트된 각각의 파일을 특징화하는 이용가능한 속성들을 통하여 적용되는 애플리케이션-특정의 로직에 기초하여 결정할 수도 있다.
도 88 은 실시형태들의 임의의 실시형태와 함께 사용하기에 적합한 수신기 디바이스의 시스템 블록도이다. 일반적인 수신기 디바이스 (8800) 는 내부 메모리 (8802), 디스플레이 (8803), 및 스피커 (8854) 에 커플링된 프로세서 (8801) 를 포함할 수도 있다. 게다가, 수신기 디바이스 (8800) 는 무선 데이터 링크 및/또는 프로세서 (8801) 에 커플링된 셀룰러 전화기 송수신기 (8805) 에 접속될 수도 있는, 전자기 방사선을 전송하고 수신하기 위한 안테나 (8804), 및 프로세서 (8801) 에 커플링된 모바일 멀티미디어 브로드캐스트 수신기 (8806) 를 포함할 수도 있다. 수신기 디바이스들 (8800) 은 일반적으로 사용자 입력들을 수신하기 위한 메뉴 선택 버튼들 또는 로커 스위치들 (8808) 을 포함한다.
상호작용성 이벤트 시그널링 메시지들을 수신하여 프로세싱하는 여러 실시형태 방법들은 멀티미디어 브로드캐스트 수신기 (8824), 및 프로세서 (8801) 및 메모리 (8802) 의 부분들에 의해 실행될 수도 있다. 이의 대안으로, 멀티미디어 브로드캐스트 수신기 (8824) 내에 또는 멀티미디어 브로드캐스트 수신기 (8824) 에 커플링된 전용 모듈들이 실시형태 방법들을 수행할 수도 있다.
위에서 설명한 브로드캐스트 측 상의 여러 실시형태들은 도 89 에 도시된 서버 (8900) 와 같은 다양한 시중에서 입수가능한 서버 디바이스들 중 임의의 디바이스 상에서 구현될 수도 있다. 이런 서버 (8900) 는 일반적으로 휘발성 메모리 (8902) 및 대용량 비휘발성 메모리, 예컨대, 디스크 드라이브 (8903) 에 커플링된 프로세서 (8901) 를 포함한다. 서버 (8900) 는 또한 프로세서 (8901) 에 커플링된, 플로피 디스크 드라이브, 컴팩트 디스크 (CD) 또는 DVD 디스크 드라이브 (8906) 를 포함할 수도 있다. 서버 (8900) 는 또한 다른 브로드캐스트 시스템 컴퓨터들 및 서버들에 커플링된 근거리 네트워크와 같은 네트워크 (8905) 와 데이터 접속들을 확립하기 위해, 프로세서 (8901) 에 커플링된 네트워크 액세스 포트들 (8904) 를 포함할 수도 있다.
프로세서들 (8801, 8901) 은 아래에서 설명되는 여러 실시형태들의 기능들을 포함한, 다양한 기능들을 수행하도록 소프트웨어 명령들 (애플리케이션들) 에 의해 구성될 수 있는, 임의의 프로그래밍가능 마이크로프로세서, 마이크로컴퓨터 또는 다수의 프로세서 칩 또는 칩들일 수도 있다. 일부 모바일 수신기 디바이스들에서, 다수의 프로세서들 (8901) 은 무선 통신 기능들에 전용된 하나의 프로세서 및 다른 애플리케이션들을 실행하는 것에 전용된 하나의 프로세서와 같이, 제공될 수도 있다. 일반적으로, 소프트웨어 애플리케이션들은 액세스되어 프로세서 (8801, 8901) 에 로드되기 전에, 내부 메모리 (8802, 8902, 8903) 에 저장될 수도 있다. 프로세서 (8801, 8901) 는 애플리케이션 소프트웨어 명령들을 저장하기에 충분한 내부 메모리를 포함할 수도 있다.
상기 방법 설명들 및 프로세스 흐름도들은 단지 예시적인 예들로서 제공되며 여러 실시형태들의 단계들이 제시된 순서로 수행되어야 한다는 것을 요하거나 또는 암시하려고 의도되지 않는다. 당업자가 알 수 있는 바와 같이, 전술한 실시형태들에서 단계들의 순서는 임의의 순서로 수행될 수도 있다. "그 후", "따라서", "다음" 등과 같은 단어들은 단계들의 순서를 한정하려고 의도되지 않으며; 이들 단어들은 방법들의 설명을 통해서 독자를 안내하기 위해서 단지 사용된다. 또, 단수형으로, 예를 들어, 한정사 "한", "하나" 또는 "그" 을 이용한, 청구항 엘리먼트들에 대한 임의의 참조는, 그 엘리먼트를 단수에 한정하는 것으로 해석되어서는 안된다.
본원에서 개시된 실시형태들과 관련하여 설명한 여러가지 예시적인 로직 블록들, 모듈들, 회로들, 및 알고리즘 단계들은 전자적 하드웨어, 컴퓨터 소프트웨어, 또는 양자의 조합들로서 구현될 수도 있다. 이러한 하드웨어와 소프트웨어의 상호 교환가능성을 명확히 나타내기 위하여, 이상에서는, 여러 예시적인 구성요소들, 블록들, 모듈들, 회로들 및 단계들을 그들의 기능의 관점에서 일반적으로 설명되었다. 이런 기능이 하드웨어 또는 소프트웨어로 구현되는지 여부는 특정의 애플리케이션 및 전체 시스템에 부과되는 설계 제한 사항들에 의존한다. 숙련자들은 각각의 특정의 애플리케이션 마다 설명한 기능을 여러가지 방법으로 구현할 수도 있으며, 그러나 이런 구현 결정들이 본 발명의 범위로부터 일탈을 초래하는 것으로 해석되어서는 안된다.
본원에서 개시한 양태들과 관련하여 설명한 여러 예시적인 로직들, 로직 블록들, 모듈들, 및 회로들을 구현하기 위해 사용되는 하드웨어는 범용 프로세서, 디지털 신호 프로세서 (DSP), 애플리케이션-특정의 집적회로 (ASIC), 필드 프로그래밍가능 게이트 어레이 (FPGA) 또는 다른 프로그래밍가능 로직 디바이스, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 구성요소들, 또는 본원에서 설명한 기능들을 수행하도록 설계된 이들의 임의의 조합으로 구현되거나 또는 수행될 수도 있다. 범용 프로세서는 마이크로프로세서일 수도 있으며, 그러나, 대안적인 예에서, 프로세서 임의의 종래의 프로세서, 제어기, 마이크로제어기, 또는 상태 기계일 수도 있다. 프로세서는 또한 컴퓨팅 디바이스들의 조합, 예컨대, DSP와 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 이상의 마이크로프로세서들, 또는 임의의 다른 이런 구성으로서 구현될 수도 있다. 이의 대안으로, 일부 단계들 또는 방법들은 주어진 기능에 고유한 회로에 의해 실행될 수도 있다.
하나 이상의 예시적인 양태들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수도 있다. 소프트웨어로 구현되는 경우, 기능들은 컴퓨터-판독가능 매체 상에 하나 이상의 명령들 또는 코드들로서 저장되거나 또는 거쳐서 전달될 수도 있다. 본원에서 개시한 방법 또는 알고리즘의 단계들은 유형의, 비일시성 컴퓨터-판독가능 저장 매체 상에 상주할 수도 있는 프로세서-실행가능한 소프트웨어 모듈로 구현될 수도 있다. 유형의, 비일시성 컴퓨터-판독가능 저장 매체들은 컴퓨터에 의해 액세스될 수도 있는 임의의 가용 매체들일 수도 있다. 일 예로서, 이에 한정하지 않고, 이런, 비일시성 컴퓨터-판독가능 매체들은 RAM, ROM, EEPROM, CD-ROM 또는 다른 광디스크 스토리지, 자기디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 원하는 프로그램 코드를 명령들 또는 데이터 구조들의 형태로 저장될 수도 있으며 컴퓨터에 의해 액세스될 수도 있는 임의의 다른 매체를 포함할 수도 있다. 디스크 (disk) 및 디스크 (disc) 는, 본원에서 사용할 때, 컴팩트 디스크 (CD), 레이저 디스크, 광 디스크, 디지털 다기능 디스크 (DVD), 플로피 디스크, 및 블루-레이 디스크를 포함하며, 본원에서, 디스크 (disk) 는 데이터를 자기적으로 보통 재생하지만, 디스크 (disc) 는 레이저로 데이터를 광학적으로 재생한다. 또한, 앞에서 언급한 것들의 조합들이 비일시성 컴퓨터-판독가능 매체들의 범위 내에 포함되어야 한다. 게다가, 방법 또는 알고리즘의 동작들이 컴퓨터 프로그램 제품에 포함될 수도 있는 유형의, 비일시성 기계 판독가능 매체 및/또는 컴퓨터-판독가능 매체 상에, 코드들 및/또는 명령들의 하나 또는 임의의 조합 또는 세트로서 상주할 수도 있다.
개시된 실시형태들의 상기 설명은 임의의 당업자가 본 발명을 실시하고 이용할 수 있도록 하기 위해서 제공된다. 이들 실시형태들에 대한 여러 변경들은 당업자들에게 명백할 것이며, 본원에서 정의한 일반적인 원리들은 본 발명의 정신 또는 범위로부터 일탈함이 없이 다른 실시형태들에도 적용될 수도 있다. 따라서, 본 발명은 본원에서 나타낸 실시형태들에 한정시키려는 것이 아니라, 다음 청구범위에 부합하는 최광의의 범위 및 본원에서 개시된 원리들 및 신규한 특징들을 부여받게 하려는 것이다.
Claims (56)
- 브로드캐스트 통신 네트워크를 통해서 수신기 디바이스로 파일들을 전달하는 방법으로서,
콘텐츠 제공자로부터 전송을 위한 파일들을 수신하는 단계로서, 상기 수신된 파일들은 파일 이름을 갖고 파일 콘텐츠들 및 통신 요구사항들에 관한 정보를 포함하는, 상기 전송을 위한 파일들을 수신하는 단계;
브로드캐스트 송신들 내의 파일 데이터 흐름을 통한 송신을 위해 상기 수신된 파일들을 스케쥴링하는 단계;
파일들이 브로드캐스트 스케쥴링 기간 내에 브로드캐스트될 시기, 그들 파일들에 관한 정보, 및 각각의 파일에 대한 스케쥴링된 브로드캐스트 시간 윈도우를 나타내는 브로드캐스트 스케쥴링 메시지를 발생시키는 단계;
상기 브로드캐스트 네트워크를 통해서 상기 발생된 브로드캐스트 스케쥴링 메시지를 브로드캐스트하는 단계; 및
상기 브로드캐스트 스케쥴링 메시지 내에 포함된 상기 스케쥴링된 브로드캐스트 시간 윈도우들에 따라서, 상기 브로드캐스트 네트워크의 상기 파일 데이터 흐름을 통해서 상기 수신된 파일들을 브로드캐스트하는 단계를 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 수신된 파일들은 상대적 긴급성에 기초하여 브로드캐스트를 위해 스케쥴링되는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 수신된 파일들은 하나 이상의 파일 전달 파이프들로 편성되는 송신 리소스들 상에서 브로드캐스트되는, 파일들의 전달 방법. - 제 1 항에 있어서,
수신기 디바이스 내에서 동작하는 애플리케이션으로부터 파일들을 캡쳐하라는 요청을 수신하는 단계로서, 상기 요청은 하나 이상의 수신 기준들을 특정하는, 상기 요청을 수신하는 단계;
상기 수신기 디바이스에서 상기 브로드캐스트 스케쥴링 메시지를 수신하는 단계;
상기 수신기 디바이스에서 상기 브로드캐스트 스케쥴링 메시지를 상기 수신 기준들에 매칭하는 파일에 대해 모니터링하는 단계;
상기 브로드캐스트 스케쥴링 메시지로부터, 상기 수신 기준들에 매칭하는 파일이 브로드캐스트될 상기 스케쥴링된 브로드캐스트 시간 윈도우를 식별하는 단계;
상기 매칭 파일에 대한 상기 식별된 스케쥴링된 브로드캐스트 시간 윈도우에서 상기 수신기 디바이스의 수신기 회로를 활성화하는 단계;
상기 수신된 브로드캐스트 스케쥴링 메시지 내의 파일 정보에 기초하여, 수신을 위한 파일을 선택하는 단계;
상기 수신기 디바이스에서 상기 브로드캐스트 송신들로부터의 상기 선택된 파일을 수신하는 단계; 및
상기 선택된 파일을 상기 수신기 디바이스 내에서 동작하는 요청 애플리케이션으로 전달하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 4 항에 있어서,
상기 수신기 디바이스에서 상기 브로드캐스트 송신들로부터의 상기 선택된 파일을 수신하는 단계는, 상기 수신기 디바이스 내의 메모리에 버전 식별 정보를 저장하는 단계로서, 상기 버전 식별 정보는 상기 수신된 파일의 버전을 식별하는, 상기 버전 식별 정보를 저장하는 단계를 더 포함하고,
상기 방법은,
상기 수신기 디바이스에서 상기 브로드캐스트 스케쥴링 메시지를, 상기 수신된 파일의 더 새로운 또는 업데이트된 버전이 브로드캐스트되는 중임을 나타내는 버전 식별 정보를 갖는 파일에 대해 모니터링하는 단계; 및
상기 브로드캐스트 스케쥴링 메시지가 상기 파일의 새로운 또는 업데이트된 버전이 브로드캐스트되는 중임을 나타낼 때, 상기 수신기 디바이스에서 상기 브로드캐스트 네트워크로부터의 요청된 파일의 업데이트된 버전을 수신하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 4 항에 있어서,
상기 수신기 디바이스 내에서 동작하는 애플리케이션으로부터 파일들을 캡쳐하라는 요청을 수신하는 단계는, 상기 수신기 디바이스에 의해, 한번 요청된 파일을 포함하는 파일을 캡쳐하라는 지령들의 형태로 또는 상기 파일의 모든 인스턴스들을 캡쳐하라는 지령으로서 상기 캡쳐 요청을 수신하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 4 항에 있어서,
상기 발생된 브로드캐스트 스케쥴링 메시지는 또한, 상기 브로드캐스트 스케쥴링 메시지가 업데이트될 시간을 식별하며,
상기 방법은,
상기 브로드캐스트 스케쥴링 기간 내에서 다수 회 (multiple times) 상기 브로드캐스트 스케쥴링 메시지를 브로드캐스트하는 단계;
상기 브로드캐스트 스케쥴링 메시지가 수신된 후 상기 수신기 디바이스 내의 수신기 회로를 비활성화하는 단계;
현재 시간이 상기 브로드캐스트 스케쥴링 메시지가 업데이트될 시간과 같을 때를 결정하는 단계;
상기 현재 시간이 상기 브로드캐스트 스케쥴링 메시지가 업데이트될 시간과 같을 때, 상기 수신기 디바이스 내의 상기 수신기 회로를 재활성화하는 단계; 및
업데이트된 브로드캐스트 스케쥴링 메시지를 수신하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 4 항에 있어서,
상기 선택된 파일을 상기 수신기 디바이스 내에서 동작하는 요청 애플리케이션으로 전달하는 단계는, 상기 수신기 디바이스 내에서 동작하는 상기 애플리케이션을, 상기 파일들을 상기 수신기 디바이스로 전달하는데 이용되는 상기 파일들의 전달 방법에 노출시키지 않는 방식으로, 상기 파일들을 상기 수신기 디바이스 내에서 동작하는 상기 애플리케이션으로 전달하는 단계를 포함하는, 파일들의 전달 방법. - 제 4 항에 있어서,
상기 수신기 디바이스 내에서 동작하는 애플리케이션으로부터 파일들을 캡쳐하라는 요청을 수신하는 단계는, 파일 디렉토리를 특정하는 파일을 캡쳐하라는 요청을 수신하는 단계를 포함하고,
상기 수신된 브로드캐스트 스케쥴링 메시지 내의 파일 정보에 기초하여, 수신을 위한 파일을 선택하는 단계는, 상기 식별된 파일 디렉토리에 매칭하는 파일 식별자에 기초하여 수신을 위한 파일을 선택하는 단계를 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 발생된 브로드캐스트 스케쥴링 메시지를 브로드캐스트하는 단계는, 주어진 주파수 상에서 브로드캐스트되는 파일들에 대해 전달 스케쥴 정보를 제공하는 오버헤드 전송 스트림의 부분으로서 상기 브로드캐스트 스케쥴링 메시지를 브로드캐스트하는 단계를 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 발생된 브로드캐스트 스케쥴링 메시지를 브로드캐스트하는 단계는, 주어진 주파수 상에서 브로드캐스트되는 파일들에 대해 전달 스케쥴 정보를 제공하는 오버헤드 전송 스트림의 부분으로서 상기 브로드캐스트 스케쥴링 메시지를 브로드캐스트하는 단계를 포함하고, 상기 전달 스케쥴 정보는 상기 브로드캐스트 스케쥴링 메시지에 의해 광고되는 전달 스케쥴들을 설정하는, 파일들의 전달 방법. - 제 11 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지는 모든 성공적으로 스케쥴링된 파일들을 브로드캐스트 스케쥴 기간에 걸쳐서 광고하는, 파일들의 전달 방법. - 제 11 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지는 단지 성공적으로 스케쥴링된 파일들의 일부만을 브로드캐스트 스케쥴 기간에 걸쳐서 광고하는, 파일들의 전달 방법. - 제 13 항에 있어서,
송신용으로 이미 수락되었지만 전달 스케쥴들이 상기 브로드캐스트 스케쥴링 메시지에 의해 아직 광고되지 않은 상기 파일들을 결정하는 단계; 및
송신용으로 이미 수락되었지만 전달 스케쥴들이 상기 브로드캐스트 스케쥴링 메시지에 의해 아직 광고되지 않은 상기 파일들의 상기 전달 스케쥴 정보를 변경하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 3 항에 있어서,
상기 콘텐츠 제공자는 상기 수신된 파일들 각각에 대한 브로드캐스트 전송 요구사항들을 특정하는, 파일들의 전달 방법. - 제 15 항에 있어서,
상기 수신된 파일들을 파일 수취 시스템 (file ingestion system) 을 통해서 수취하는 단계;
상기 브로드캐스트 네트워크에 상기 수취된 파일들 및 상기 수취된 파일들의 상기 브로드캐스트 전송 요구사항들을 통지하는, 상기 파일 수취 시스템로부터의 통지 (notice) 를 전송하는 단계; 및
상기 파일 수취 시스템에서 하나 이상의 브로드캐스트 송신 스트림들 상에서의 상기 수취된 파일들의 송신 시간들을 스케쥴링하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 16 항에 있어서,
2 개 이상 수취된 파일들을 브로드캐스트 송신 스트림들을 통한 전송에 적합한 하나 이상의 전송 파일들로 조합하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 16 항에 있어서,
상기 콘텐츠 제공자에 의해 특정되는 상기 브로드캐스트 전송 요구사항들 각각은 시의성 (timeliness) 요구사항 및 강건성 (robustness) 요구사항을 포함하는, 파일들의 전달 방법. - 제 18 항에 있어서,
상기 시의성 요구사항은 상기 수취된 파일에 대한 레이턴시 허용오차를 포함하는, 파일들의 전달 방법. - 제 18 항에 있어서,
상기 강건성 요구사항은 상기 수취된 파일에 대해 요구되는 순방향 에러 정정의 레벨을 포함하는, 파일들의 전달 방법. - 제 16 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지는 상기 수신된 파일들의 전달 스케쥴들을 광고하며,
상기 방법은,
상기 브로드캐스트 송신 스트림들 상에서 송신용으로 이미 스케쥴링되었지만 상기 브로드캐스트 스케쥴링 메시지에 의해 아직 광고되지 않은 파일들을 식별하는 단계; 및
상기 콘텐츠 제공자에 의해 특정되는 상기 브로드캐스트 전송 요구사항들을 이용하여 상기 식별된 파일들과 함께 새로 수취된 파일들을 상기 브로드캐스트 송신 스트림들로 팩킹하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 16 항에 있어서,
상기 파일 전달 파이프들을 이용하여 다수의 상이한 파일들을 상기 브로드캐스트 송신 스트림들 각각 상으로 멀티플렉싱하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 22 항에 있어서,
상기 콘텐츠 제공자에 의해 특정되는 애플리케이션-특정 전달 요구사항들을 해결하는 방식으로 상기 파일 전달 파이프들을 통해 상기 수취된 파일들을 스케쥴링하는 단계를 더 포함하며,
상기 애플리케이션-특정 전달 요구사항들은 상기 수신기 디바이스 상에서 실행하는 애플리케이션에 의해 상기 콘텐츠 제공자에게 발행되는, 파일들의 전달 방법. - 제 22 항에 있어서,
전송자측 애플리케이션들을 클래스들로 편성하는 단계; 및
상기 애플리케이션들의 클래스들을 특정 파일 전달 파이프들에 맵핑하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 3 항에 있어서,
각각의 수신된 파일을, 상기 파일을 고유하게 식별하고 버전화 지원 (versioning support) 을 제공하는 전송 파일 ID 와 연관시키는 단계; 및
상기 수신된 파일들의 시퀀스를 운반하기 위해서 상기 전송 파일 ID 에 기초하여 각각의 파일 전달 파이프를 스케쥴링하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 3 항에 있어서,
각각의 파일은 브로드캐스트 윈도우 내에서 전용 파일 전달 파이프를 통해 브로드캐스트되도록 스케쥴링되며, 각각의 브로드캐스트 윈도우는 사이즈를 갖는, 파일들의 전달 방법. - 제 26 항에 있어서,
각각의 파일 전달 파이프의 상기 브로드캐스트 윈도우의 사이즈는 상기 파일 전달 파이프의 데이터 레이트 및 상기 파일 전달 파이프를 통해 송신되는 상기 파일의 사이즈의 함수로서 계산되는, 파일들의 전달 방법. - 제 26 항에 있어서,
각각의 파일 전달 파이프의 상기 브로드캐스트 윈도우의 사이즈는 상기 파일 전달 파이프의 데이터 레이트로 나눠진 상기 파일 전달 파이프를 통해 송신되는 상기 파일의 사이즈에 비례하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지를 발생시키는 단계는, 상기 브로드캐스트 스케쥴 기간 내에 브로드캐스트될 일련의 파일들을 기술하는 상기 브로드캐스트 스케쥴 메시지를 발생시키는 단계를 포함하며,
각각의 브로드캐스트 스케쥴 기간은 상기 브로드캐스트 스케쥴 메시지 내에 포함되는 광고된 파일 브로드캐스트 스케쥴들의 수를 나타내는 양을 정의하는, 파일들의 전달 방법. - 제 1 항에 있어서,
적어도 하나의 수신된 파일은 단일 브로드캐스트 스케쥴 기간 내의 하나 보다 많은 브로드캐스트 시간 윈도우 내에서 브로드캐스트되도록 스케쥴링되는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지를 발생시키는 단계는, 단일 브로드캐스트 스케쥴 기간 내에 브로드캐스트될 복수의 파일들에 대한 수신 정보를 포함하는 상기 브로드캐스트 스케쥴 메시지를 발생시키는 단계를 포함하며,
상기 브로드캐스트 네트워크를 통해서 상기 발생된 브로드캐스트 스케쥴링 메시지를 브로드캐스트하는 단계는, 상기 브로드캐스트 스케쥴 메시지를 동일한 브로드캐스트 시간 윈도우에서 반복적으로 송신하는 단계를 포함하는, 파일들의 전달 방법. - 제 12 항에 있어서,
상기 브로드캐스트 스케쥴 메시지는 각각의 브로드캐스트 슈퍼프레임으로 재브로드캐스트되는, 파일들의 전달 방법. - 제 32 항에 있어서,
다수의 브로드캐스트 윈도우들은 상기 파일 데이터 흐름 상에서 송신되는 단일 파일과 연관된 브로드캐스트 스케쥴 기간 동안 존재하는, 파일들의 전달 방법. - 제 33 항에 있어서,
상기 단일 파일은 따로 떨어진 피스들로 분할되고, 다른 파일들과 인터리브되며, 다른 파일들과 함께 상기 파일 데이터 흐름을 통해서 송신되는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지를 발생시키는 단계는, 상기 수신기 디바이스가 브로드캐스트 스케쥴 흐름을 업데이트된 브로드캐스트 스케쥴 메시지에 대해 모니터링해야 하는 다음 시간을 특정하는 다음 모니터 시간 데이터 필드를 갖는 브로드캐스트 스케쥴 모니터링 레코드를 포함하는 상기 브로드캐스트 스케쥴링 메시지를 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지를 발생시키는 단계는, 상기 파일 데이터 흐름 상에서 브로드캐스트된 파일들에 대한 브로드캐스트 스케쥴들을 기술하는 흐름 브로드캐스트 스케쥴 레코드를 포함하는 상기 브로드캐스트 스케쥴 메시지를 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지를 발생하는 단계는, 상기 파일 데이터 흐름 상에서 브로드캐스트된 파일들과 연관되는 파일 콘텐츠를 식별하는 다수의 파일들을 식별하는 프리픽스 매칭 스트링들을 포함하는 상기 브로드캐스트 스케쥴 메시지를 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지를 발생시키는 단계는, 상기 파일 데이터 흐름 상에서 브로드캐스트된 파일들과 연관되는 파일 콘텐츠를 식별하는 다수의 디렉토리 이름들을 식별하는 프리픽스 매칭 스트링들을 포함하는 상기 브로드캐스트 스케쥴 메시지를 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 37 항에 있어서,
상기 흐름 브로드캐스트 스케쥴 레코드는 파일 이름과 연관되는 파일 콘텐츠를 식별하는 정확히 하나의 프리픽스 매칭 스트링을 포함하는, 파일들의 전달 방법. - 제 37 항에 있어서,
상기 수신기 디바이스는 상기 프리픽스 매칭 스트링들에서의 값들과 양방향 프리픽스 매칭을 수행하도록 구성되는, 파일들의 전달 방법. - 제 38 항에 있어서,
상기 흐름 브로드캐스트 스케쥴 레코드는 파일 이름과 연관되는 파일 콘텐츠를 식별하는 정확히 하나의 프리픽스 매칭 스트링을 포함하는, 파일들의 전달 방법. - 제 38 항에 있어서,
상기 수신기 디바이스는 상기 프리픽스 매칭 스트링들에서의 값들과 양방향 프리픽스 매칭을 수행하도록 구성되는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지를 발생시키는 단계는, 상기 파일 콘텐츠를 특징화하는 다수의 속성들을 제공하는 속성 스트링들을 포함하는 상기 브로드캐스트 스케쥴 메시지를 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴링 메시지를 발생시키는 단계는, 브로드캐스트 스케쥴 정보 레코드를 포함하는 상기 브로드캐스트 스케쥴 메시지를 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 44 항에 있어서,
상기 브로드캐스트 스케쥴 정보 레코드를 포함하는 상기 브로드캐스트 스케쥴 메시지를 발생시키는 단계는, 헤더 부분 및 바디 부분을 포함하는 상기 브로드캐스트 스케쥴 메시지의 상기 브로드캐스트 스케쥴 정보 레코드를 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 45 항에 있어서,
상기 브로드캐스트 스케쥴 정보 레코드를 발생시키는 단계는, 다음 모니터 시간 데이터 필드 및 모니터링 기간 데이터 필드를 포함하는 상기 브로드캐스트 스케쥴 정보 레코드의 상기 헤더 부분을 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 46 항에 있어서,
상기 브로드캐스트 스케쥴 정보 레코드의 상기 헤더 부분으로부터 상기 다음 모니터 시간 데이터 필드 및 상기 모니터링 기간 데이터 필드를 추출하는 단계; 및
상기 추출된 다음 모니터 시간 데이터 필드 및 상기 추출된 모니터링 기간 데이터 필드를 이용하여 상이한 레이턴시들에서 데이터를 전달하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 45 항에 있어서,
상기 브로드캐스트 스케쥴 정보 레코드를 발생시키는 단계는,
시스템이 초기 획득 흐름 (IAF) 시스템들을 지원하는지를 결정하는 단계; 및
모니터링 기간 데이터 필드를 포함하고, 상기 시스템이 초기 획득 흐름 (IAF) 시스템들을 지원하지 않는 것으로 결정된다면, 다음 모니터 시간 필드를 포함하는 상기 브로드캐스트 스케쥴 정보 레코드의 상기 헤더 부분을 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 46 항에 있어서,
상기 브로드캐스트 스케쥴 정보의 상기 헤더 부분을 발생시키는 단계는, 상기 파일 데이터 흐름에 관한 정보를 포함하는 정보 필드를 포함하는 상기 헤더 부분을 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 49 항에 있어서,
상기 정보 필드를 포함하는 상기 헤더 부분을 발생시키는 단계는, 흐름 ID 데이터 필드 및 데이터 레이트 데이터 필드를 포함하는 상기 정보 필드를 발생시키는 단계를 포함하는, 파일들의 전달 방법. - 제 46 항에 있어서,
상기 다음 모니터 시간 데이터 필드는, 상기 수신기 디바이스가 브로드캐스트 스케쥴 흐름을 업데이트된 브로드캐스트 스케쥴 메시지에 대해 모니터링해야 하는 다음 시간을 특정하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 브로드캐스트 스케쥴 메시지들에 대한 새로운 버전을 시그널링하기 위해서 초기 획득 흐름 (IAF) 시스템을 이용하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 수신기 디바이스에서 초기 획득 흐름 (IAF) 으로부터 최신 디렉토리 정보 메시지를 수신하고, 상기 최신 디렉토리 정보 메시지로부터 추출되는 수신된 브로드캐스트 스케쥴 메시지의 버전 정보를 미만료된 프로세싱된 브로드캐스트 스케쥴 메시지의 버전 정보와 비교하는 비교 동작을 실행하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 53 항에 있어서,
상기 비교 동작의 결과들이 상기 버전들이 상이하다는 것을 나타낸다면, 업데이트된 브로드캐스트 스케쥴 메시지를 수신하기 위해서 상기 수신기 디바이스 내의 수신기 회로를 활성화하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 1 항에 있어서,
상기 수신기 디바이스에서 상기 브로드캐스트 스케쥴 메시지를 수신하고, 상기 수신된 브로드캐스트 스케쥴 메시지 내의 버전 파라미터를 디렉토리 정보 메시지 유닛 내의 버전 파라미터와 비교하는 단계, 및 상기 비교된 버전들이 상이하다면, 상기 수신된 브로드캐스트 스케쥴 메시지를 무시하는 단계를 더 포함하는, 파일들의 전달 방법. - 제 12 항에 있어서,
상기 브로드캐스트 네트워크는 다음 모니터링 필드 디바이스 프로비젼 파라미터를 상기 브로드캐스트 스케쥴 기간의 시작 시간 전의 가변 수의 초 (variable number of seconds) 이도록 설정하고,
상기 방법은 상기 브로드캐스트 스케쥴 기간의 시작 전에, 상기 수신기 디바이스에서 브로드캐스트 스케쥴 메시지 업데이트들을 검출하고, 업데이트된 브로드캐스트 스케쥴 메시지를 수신하는 단계를 더 포함하는, 파일들의 전달 방법.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US34959810P | 2010-05-28 | 2010-05-28 | |
| US61/349,598 | 2010-05-28 | ||
| US13/004,702 | 2011-01-11 | ||
| US13/004,702 US8914471B2 (en) | 2010-05-28 | 2011-01-11 | File delivery over a broadcast network using file system abstraction, broadcast schedule messages and selective reception |
| PCT/US2011/038434 WO2011150389A1 (en) | 2010-05-28 | 2011-05-27 | File delivery over a broadcast network using file system abstraction, broadcast schedule messages and selective reception |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20130039741A true KR20130039741A (ko) | 2013-04-22 |
| KR101577108B1 KR101577108B1 (ko) | 2015-12-11 |
Family
ID=44317673
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020127033547A Expired - Fee Related KR101577108B1 (ko) | 2010-05-28 | 2011-05-27 | 파일 시스템 추상화, 브로드캐스트 스케쥴 메시지들 및 선택적 수신을 이용하는 브로드캐스트 네트워크를 통한 파일 전달 |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US8914471B2 (ko) |
| EP (1) | EP2577967A1 (ko) |
| JP (1) | JP5813756B2 (ko) |
| KR (1) | KR101577108B1 (ko) |
| CN (1) | CN102948159B (ko) |
| WO (1) | WO2011150389A1 (ko) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20210073579A (ko) * | 2018-11-23 | 2021-06-18 | 소니그룹주식회사 | 수신된 패킷 스트림의 파일들을 저장하기 위한 버퍼 관리 |
Families Citing this family (48)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7921139B2 (en) * | 2006-12-01 | 2011-04-05 | Whitserve Llc | System for sequentially opening and displaying files in a directory |
| CN102014530A (zh) * | 2009-09-04 | 2011-04-13 | 中兴通讯股份有限公司 | 一种配置更新失败后的处理方法和网元设备 |
| US8958306B2 (en) | 2009-10-16 | 2015-02-17 | Tekelec, Inc. | Methods, systems, and computer readable media for providing diameter signaling router with integrated monitoring functionality |
| US20110177774A1 (en) * | 2010-01-13 | 2011-07-21 | Qualcomm Incorporated | Dynamic generation, delivery, and execution of interactive applications over a mobile broadcast network |
| US8676991B2 (en) * | 2010-01-13 | 2014-03-18 | Qualcomm Incorporated | Signaling mechanisms and systems for enabling, transmitting and maintaining interactivity features on mobile devices in a mobile broadcast communication system |
| US20110177775A1 (en) * | 2010-01-13 | 2011-07-21 | Qualcomm Incorporated | Signaling mechanisms, templates and systems for creation and delivery of interactivity events on mobile devices in a mobile broadcast communication system |
| US9485535B2 (en) * | 2010-01-13 | 2016-11-01 | Qualcomm Incorporated | Notification of interactivity event asset delivery sources in a mobile broadcast communication system |
| US9032466B2 (en) * | 2010-01-13 | 2015-05-12 | Qualcomm Incorporated | Optimized delivery of interactivity event assets in a mobile broadcast communication system |
| EP2378473A3 (en) * | 2010-04-15 | 2011-12-07 | HTC Corporation | File download method for mobile device, server and mobile device thereof, and computer-readable medium |
| US8914471B2 (en) | 2010-05-28 | 2014-12-16 | Qualcomm Incorporated | File delivery over a broadcast network using file system abstraction, broadcast schedule messages and selective reception |
| JP5885757B2 (ja) * | 2011-01-21 | 2016-03-15 | テケレック・インコーポレイテッドＴｅｋｅｌｅｃ， Ｉｎｃ． | 分散型メッセージプロセッサアーキテクチャを有するＤｉａｍｅｔｅｒ信号伝達ルータ（ＤＳＲ）内のＤｉａｍｅｔｅｒメッセージをスクリーニングするための方法、システム、およびコンピュータ読取り可能媒体 |
| US20120207075A1 (en) * | 2011-02-16 | 2012-08-16 | Nagaraj Thadi M | Multicast data delivery mechanism using packet bundling or file delivery framework |
| US9182757B2 (en) * | 2011-03-30 | 2015-11-10 | Fisher-Rosemount Systems, Inc. | Methods and apparatus to transmit device description files to a host |
| JP5632802B2 (ja) * | 2011-07-12 | 2014-11-26 | 株式会社沖データ | 通信端末装置 |
| US9015021B2 (en) * | 2011-10-25 | 2015-04-21 | Cellco Partnership | Multiple client simulator for push engine |
| US10165026B2 (en) * | 2012-12-26 | 2018-12-25 | Disney Enterprises, Inc. | Intelligent generation and distribution of an encoded content transport stream according to metadata |
| US9288102B2 (en) * | 2013-02-18 | 2016-03-15 | Microsoft Technology Licensing, Llc | Controlling devices using cloud services and device-agnostic pipe mechanisms |
| US9900166B2 (en) * | 2013-04-12 | 2018-02-20 | Qualcomm Incorporated | Methods for delivery of flows of objects over broadcast/multicast enabled networks |
| US9596497B2 (en) * | 2013-04-18 | 2017-03-14 | Disney Enterprises, Inc. | Recipient specific lists for distribution of media content |
| US9781181B2 (en) | 2013-06-17 | 2017-10-03 | Qualcomm Incorporated | Multiple file delivery over unidirectional transport protocol sessions for a service |
| CN104462113B (zh) | 2013-09-17 | 2018-10-23 | 腾讯科技（深圳）有限公司 | 搜索方法、装置及电子设备 |
| US9800636B2 (en) | 2013-09-25 | 2017-10-24 | Iheartmedia Management Services, Inc. | Media asset distribution with prioritization |
| US10116728B2 (en) | 2014-02-12 | 2018-10-30 | Dell Products, Lp | System and method for transferring data using a directional touch gesture |
| US10218639B2 (en) | 2014-03-14 | 2019-02-26 | Microsoft Technology Licensing, Llc | Computing long-term schedules for data transfers over a wide area network |
| US20150288645A1 (en) * | 2014-04-03 | 2015-10-08 | Avid Technology, Inc. | Synchronized story-centric media distribution |
| CN105100129B (zh) * | 2014-04-25 | 2019-10-25 | 阿里巴巴集团控股有限公司 | 一种数据传输的方法、装置和系统 |
| US9600333B1 (en) | 2014-10-29 | 2017-03-21 | Vantiv, Llc | System and methods for transaction-based process management |
| JP2016186695A (ja) * | 2015-03-27 | 2016-10-27 | 株式会社日立ソリューションズ | ファイル管理装置 |
| US20160292154A1 (en) * | 2015-03-31 | 2016-10-06 | Mckesson Corporation | Methods and Apparatuses for Providing Document Workflow Management |
| US20160323063A1 (en) * | 2015-05-01 | 2016-11-03 | Qualcomm Incorporated | Bundled Forward Error Correction (FEC) for Multiple Sequenced Flows |
| US10117127B2 (en) | 2015-07-08 | 2018-10-30 | Oracle International Corporation | Methods, systems, and computer readable media for communicating radio access network congestion status information for large numbers of users |
| US10084844B2 (en) * | 2015-11-16 | 2018-09-25 | International Business Machines Corporation | System and method for improved user-controlled electronic file and trash management |
| US10149002B1 (en) * | 2016-03-21 | 2018-12-04 | Tribune Broadcasting Company, Llc | Systems and methods for retrieving content files |
| US10601648B2 (en) * | 2016-07-19 | 2020-03-24 | T-Mobile Usa, Inc. | Network nodes with intelligent integration |
| EP3282650B1 (en) * | 2016-08-09 | 2021-07-28 | Alcatel Lucent | Method and device for scheduling of dataflow components |
| US10931763B2 (en) | 2017-01-11 | 2021-02-23 | Qualcomm Incorporated | Systems and methods for opaque object delivery in a communication network |
| US11650576B2 (en) * | 2017-01-18 | 2023-05-16 | Asml Netherlands B.V. | Knowledge recommendation for defect review |
| US10581945B2 (en) * | 2017-08-28 | 2020-03-03 | Banjo, Inc. | Detecting an event from signal data |
| US10313413B2 (en) | 2017-08-28 | 2019-06-04 | Banjo, Inc. | Detecting events from ingested communication signals |
| US11025693B2 (en) | 2017-08-28 | 2021-06-01 | Banjo, Inc. | Event detection from signal data removing private information |
| US10585724B2 (en) | 2018-04-13 | 2020-03-10 | Banjo, Inc. | Notifying entities of relevant events |
| US20220131921A1 (en) * | 2018-11-30 | 2022-04-28 | British Telecommunications Public Limited Company | Multicast to unicast conversion |
| US11075800B2 (en) * | 2018-12-31 | 2021-07-27 | Morgan Stanley Services Group Inc. | Characterizing client-server connection configurations according to communication layer attributes |
| US12167306B2 (en) * | 2022-02-25 | 2024-12-10 | Ford Global Technologies, Llc | Vehicular ad-hoc network manager |
| US12185204B2 (en) | 2022-07-15 | 2024-12-31 | Ford Global Technologies, Llc | Methods and apparatuses for OTA broadcast efficiency |
| CN114944890B (zh) * | 2022-07-21 | 2022-10-25 | 北京全路通信信号研究设计院集团有限公司 | 一种应答器报文传送处理方法及系统 |
| US12308959B2 (en) | 2023-08-31 | 2025-05-20 | Ottopia Technologies Ltd. | Application-level forward error correction techniques |
| US20250094406A1 (en) * | 2023-09-19 | 2025-03-20 | The Toronto-Dominion Bank | System and Method for Ingesting Data onto Cloud Computing Environments |
Family Cites Families (103)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5589892A (en) | 1993-09-09 | 1996-12-31 | Knee; Robert A. | Electronic television program guide schedule system and method with data feed access |
| US5600378A (en) | 1995-05-22 | 1997-02-04 | Scientific-Atlanta, Inc. | Logical and composite channel mapping in an MPEG network |
| EP1309190B1 (en) | 1996-09-11 | 2004-11-24 | Matsushita Electric Industrial Co., Ltd. | Apparatus for controlling the display of data |
| US6311329B1 (en) | 1996-10-14 | 2001-10-30 | Sony Corporation | Information providing apparatus and method, display controlling apparatus and method, information providing system, as well as transmission medium |
| US6608832B2 (en) * | 1997-09-25 | 2003-08-19 | Telefonaktiebolaget Lm Ericsson | Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services |
| JP3466071B2 (ja) | 1997-12-05 | 2003-11-10 | 松下電器産業株式会社 | 放送受信装置 |
| US6459427B1 (en) | 1998-04-01 | 2002-10-01 | Liberate Technologies | Apparatus and method for web-casting over digital broadcast TV network |
| JP3361997B2 (ja) | 1998-05-07 | 2003-01-07 | 松下電器産業株式会社 | 放送送信装置及び放送送信方法 |
| US6807667B1 (en) | 1998-09-21 | 2004-10-19 | Microsoft Corporation | Method and system of an application program interface for abstracting network traffic control components to application programs |
| NZ500956A (en) | 1998-12-04 | 2000-08-25 | Two Way Tv Ltd | Interactive TV game system, start signal transmitted to all users simultaneously |
| US7222155B1 (en) | 1999-06-15 | 2007-05-22 | Wink Communications, Inc. | Synchronous updating of dynamic interactive applications |
| US7634787B1 (en) | 1999-06-15 | 2009-12-15 | Wink Communications, Inc. | Automatic control of broadcast and execution of interactive applications to maintain synchronous operation with broadcast programs |
| JP2001127719A (ja) | 1999-10-28 | 2001-05-11 | Matsushita Electric Ind Co Ltd | 放送装置および受信装置 |
| US6629284B1 (en) | 1999-10-28 | 2003-09-30 | Koninklijke Philips Electronics N.V. | System and method for supervised downloading of broadcast data |
| BR0015152A (pt) | 1999-10-29 | 2002-07-16 | Opentv Corp | Sistema e método para gravar dados empurrados |
| US6530084B1 (en) | 1999-11-01 | 2003-03-04 | Wink Communications, Inc. | Automated control of interactive application execution using defined time periods |
| US6976268B2 (en) * | 1999-12-10 | 2005-12-13 | Sun Microsystems, Inc. | Methods and apparatus for efficiently accessing periodically broadcast data |
| US6643707B1 (en) * | 2000-02-14 | 2003-11-04 | General Instrument Corporation | Method and apparatus for defining, managing and distributing broadcast names |
| US7013479B2 (en) | 2000-04-14 | 2006-03-14 | Matsushita Electric Industrial Co., Ltd. | Broadcasting apparatus and method for pre-transmitting data carousel and receiving apparatus for receiving data carousel |
| US20020059624A1 (en) | 2000-08-03 | 2002-05-16 | Kazuhiro Machida | Server based broadcast system, apparatus and method and recording medium and software program relating to this system |
| JP2002051020A (ja) | 2000-08-03 | 2002-02-15 | Matsushita Electric Ind Co Ltd | 蓄積放送システム |
| US6714264B1 (en) | 2000-08-31 | 2004-03-30 | Matsushita Electric Industrial Co., Ltd. | Digital television channel surfing system |
| EP1209822B1 (en) | 2000-11-27 | 2007-01-10 | NTT DoCoMo, Inc. | Method for provision of program and broadcasting system and server |
| WO2002069121A1 (en) | 2001-02-26 | 2002-09-06 | Ip Planet Networks Ltd. | Modular interactive application generation system |
| US7584491B2 (en) | 2001-04-25 | 2009-09-01 | Sony Corporation | System and method for managing interactive programming and advertisements in interactive broadcast systems |
| US20020162117A1 (en) | 2001-04-26 | 2002-10-31 | Martin Pearson | System and method for broadcast-synchronized interactive content interrelated to broadcast content |
| WO2002093808A2 (en) | 2001-05-15 | 2002-11-21 | Netadtack Aps | Method and system for transmitting multicast data signals |
| US7596797B1 (en) | 2001-07-31 | 2009-09-29 | Keen Personal Media, Inc. | Client terminal for providing a subscription to a bundle of channels from a program guide |
| US7636931B2 (en) | 2001-08-17 | 2009-12-22 | Igt | Interactive television devices and systems |
| JP2003111054A (ja) | 2001-09-28 | 2003-04-11 | Access:Kk | 動画配信システム |
| US20030093530A1 (en) | 2001-10-26 | 2003-05-15 | Majid Syed | Arbitrator system and method for national and local content distribution |
| GB2382966A (en) | 2001-12-10 | 2003-06-11 | Sony Uk Ltd | Providing information and presentation template data for a carousel |
| JP2003223387A (ja) | 2002-01-29 | 2003-08-08 | Nec Corp | プログラムダウンロードシステム、放送通信融合端末およびプログラムダウンロード方法 |
| US7111314B2 (en) | 2002-05-03 | 2006-09-19 | Time Warner Entertainment Company, L.P. | Technique for delivering entertainment programming content including interactive features in a communications network |
| GB0213432D0 (en) | 2002-06-12 | 2002-07-24 | Pace Micro Tech Plc | Broadcast data receiver and method of storing data therefor |
| US7360160B2 (en) | 2002-06-20 | 2008-04-15 | At&T Intellectual Property, Inc. | System and method for providing substitute content in place of blocked content |
| US20050015816A1 (en) | 2002-10-29 | 2005-01-20 | Actv, Inc | System and method of providing triggered event commands via digital program insertion splicing |
| US8328710B2 (en) | 2002-11-06 | 2012-12-11 | Senorx, Inc. | Temporary catheter for biopsy site tissue fixation |
| JP2004235928A (ja) | 2003-01-30 | 2004-08-19 | Nippon Hoso Kyokai <Nhk> | データ放送蓄積装置、データ放送蓄積方法及びデータ放送蓄積プログラム、並びに、データ放送監視装置 |
| JP2004241941A (ja) | 2003-02-04 | 2004-08-26 | Nippon Telegraph & Telephone East Corp | デジタル放送番組提供システム、デジタル放送番組再生テストシステム、デジタル放送番組提供方法、及び、デジタル放送番組再生テスト方法 |
| GB0313720D0 (en) | 2003-06-13 | 2003-07-16 | Electra Guide Ltd England | An improved television system |
| JP2005130085A (ja) | 2003-10-22 | 2005-05-19 | Canon Inc | 放送受信装置 |
| JP2005176107A (ja) | 2003-12-12 | 2005-06-30 | Canon Inc | デジタル放送受信装置およびその制御方法、デジタル放送送信装置、ならびにデジタル放送受信システム |
| US7257583B2 (en) | 2004-01-09 | 2007-08-14 | Microsoft Corporation | System and method for updating an on-device application catalog in a mobile device receiving a push message from a catalog server indicating availability of an application for download |
| DE602005012581D1 (de) | 2004-04-21 | 2009-03-19 | Panasonic Corp | Wiedergabeeinrichtung und -verfahren für digitale ausstrahlungen, computerprogramm und speichermedium |
| GB0410014D0 (en) | 2004-05-05 | 2004-06-09 | Nokia Corp | Multimedia message delivery optimisation |
| US8141118B2 (en) | 2004-07-26 | 2012-03-20 | Microsoft Corporation | Data broadcasting receiver power management |
| US7996462B2 (en) | 2004-07-30 | 2011-08-09 | Sap Ag | Collaborative agent for a work environment |
| US9197857B2 (en) | 2004-09-24 | 2015-11-24 | Cisco Technology, Inc. | IP-based stream splicing with content-specific splice points |
| JP2006115213A (ja) | 2004-10-14 | 2006-04-27 | Sony Ericsson Mobilecommunications Japan Inc | 携帯端末装置及び携帯端末の表示方法 |
| US20060168624A1 (en) | 2004-11-22 | 2006-07-27 | John Carney | Method and system for delivering enhanced TV content |
| KR20070092735A (ko) * | 2004-12-13 | 2007-09-13 | 코닌클리케 필립스 일렉트로닉스 엔.브이. | 시청각 정보 기록을 스케줄링하기 위한 시스템 및 방법 |
| GB0500579D0 (en) | 2005-01-12 | 2005-02-16 | Electra Entertainment Ltd | Memory card handling |
| US20060184989A1 (en) | 2005-02-11 | 2006-08-17 | Biap Systems, Inc. | Interacting with Internet applications via a broadband network on electronic input/output devices |
| GB2423659A (en) | 2005-02-24 | 2006-08-30 | I-Zone Tv Limited | Creating interactive television programmes using frameworks |
| US7852372B2 (en) | 2005-04-04 | 2010-12-14 | Gary Sohmers | Interactive television system and method |
| JP2006303938A (ja) | 2005-04-21 | 2006-11-02 | Nippon Hoso Kyokai <Nhk> | 放送番組受信装置および放送番組送信装置、並びに、放送番組受信プログラムおよび放送番組送信プログラム |
| WO2007018377A1 (en) | 2005-08-05 | 2007-02-15 | Samsung Electronics Co., Ltd. | Apparatus for providing multiple screens and method of dynamically configuring multiple screens |
| KR100677511B1 (ko) * | 2005-08-12 | 2007-02-02 | 엘지전자 주식회사 | Ｂｃａｓｔ서비스 시스템 및 이를 이용한 콘텐츠 전송방법 |
| US8607271B2 (en) | 2005-08-26 | 2013-12-10 | Nokia Corporation | Method to deliver messaging templates in digital broadcast service guide |
| FR2892253B1 (fr) * | 2005-10-14 | 2007-12-28 | Thales Sa | Procede de generation et de demultiplexage d'un signal de contribution optimise, et systeme de diffusion regionalisee de donnees. |
| US20070124789A1 (en) | 2005-10-26 | 2007-05-31 | Sachson Thomas I | Wireless interactive communication system |
| US7950043B2 (en) | 2005-11-02 | 2011-05-24 | Panasonic Corporation | Digital broadcast system, receiving apparatus and transmitting apparatus |
| KR100749803B1 (ko) | 2005-11-03 | 2007-08-17 | 한국전자통신연구원 | 자격폐기목록을 이용한 디지털 방송 제한수신 시스템 및 그방법 |
| KR20070082992A (ko) | 2006-02-20 | 2007-08-23 | 엘지이노텍 주식회사 | 쌍방향 통신용 셋톱 박스 |
| US11477617B2 (en) | 2006-03-20 | 2022-10-18 | Ericsson Evdo Inc. | Unicasting and multicasting multimedia services |
| CN100531038C (zh) | 2006-04-04 | 2009-08-19 | 中兴通讯股份有限公司 | 实现分布式系统板间通信的系统和方法 |
| EP1881667A1 (en) | 2006-07-17 | 2008-01-23 | Motorola, Inc., A Corporation of the State of Delaware; | Apparatus and method for presenting an event during a broadcast |
| US8266663B2 (en) | 2006-08-01 | 2012-09-11 | At&T Intellectual Property I, L.P. | Interactive content system and method |
| US8850464B2 (en) | 2006-10-09 | 2014-09-30 | Verizon Patent And Licensing Inc. | Systems and methods for real-time interactive television polling |
| WO2008053568A1 (en) | 2006-10-31 | 2008-05-08 | Panasonic Corporation | Apparatus and method for preloading data in mobile communication devices |
| US7925255B2 (en) * | 2006-12-14 | 2011-04-12 | General Motors Llc | Satellite radio file broadcast method |
| KR20080060818A (ko) | 2006-12-27 | 2008-07-02 | 엘지전자 주식회사 | 데이터 방송 신호 수신 장치 및 데이터 방송 신호를처리하는 방법 |
| KR101259118B1 (ko) | 2007-02-23 | 2013-04-26 | 엘지전자 주식회사 | 방송 신호 송신 장치 및 방법 |
| BRPI0721638A2 (pt) | 2007-06-01 | 2013-02-13 | Thomson Licensing | aparelho e mÉtodo para realizar gerenciamento de energia em um receptor |
| US8594558B2 (en) | 2007-06-07 | 2013-11-26 | Qualcomm Incorporated | Methods and apparatuses of providing multimedia content to a mobile device |
| CN101325684B (zh) | 2007-06-14 | 2010-10-06 | 中兴通讯股份有限公司 | 基于移动多媒体广播的加密控制信息传输方法及系统 |
| ATE512515T1 (de) | 2007-06-22 | 2011-06-15 | Bayerische Medien Technik Gmbh | System und verfahren zum markieren von rundfunkmedien |
| CN101836179A (zh) | 2007-10-26 | 2010-09-15 | 日本电气株式会社 | 电子设备、电子设备控制方法和包含电子设备控制程序的存储介质 |
| US8225354B2 (en) | 2008-04-11 | 2012-07-17 | Microsoft Corporation | Merging electronic program guide information |
| CN101309120B (zh) | 2008-04-17 | 2010-12-08 | 中兴通讯股份有限公司 | 一种终端获取解密解扰信息的方法及装置 |
| CA2721397C (en) | 2008-05-02 | 2014-09-30 | Lg Electronics Inc. | Method of receiving broadcasting signal and apparatus for receiving broadcasting signal |
| JP2009278332A (ja) | 2008-05-14 | 2009-11-26 | Panasonic Corp | 携帯端末装置および携帯端末装置の制御方法 |
| US8359614B2 (en) * | 2008-05-16 | 2013-01-22 | Sony Computer Entertainment America Llc | Channel hopping scheme for update of data for multiple services across multiple digital broadcast channels |
| CN102843383B (zh) | 2008-05-16 | 2015-07-22 | 华为技术有限公司 | 广播协议客户端的管理方法和数据传输方法及客户端 |
| US8526350B2 (en) | 2008-05-23 | 2013-09-03 | Qualcomm Incorporated | Systems and methods for carrying broadcast services over a mobile broadcast network |
| US20090300143A1 (en) | 2008-05-28 | 2009-12-03 | Musa Segal B H | Method and apparatus for interacting with media programming in real-time using a mobile telephone device |
| US8813152B2 (en) | 2008-08-26 | 2014-08-19 | At&T Intellectual Property I, L.P. | Methods, apparatus, and computer program products for providing interactive services |
| US8332885B2 (en) | 2008-10-14 | 2012-12-11 | Time Warner Cable Inc. | System and method for content delivery with multiple embedded messages |
| KR20100054048A (ko) * | 2008-11-13 | 2010-05-24 | 삼성전자주식회사 | 디지털 방송 수신기에서 채널스캔 방법 및 장치 |
| US8997155B2 (en) | 2008-11-21 | 2015-03-31 | Echostar Technologies L.L.C. | Locally stored advertisements |
| US8463108B2 (en) | 2009-01-06 | 2013-06-11 | Microsoft Corporation | Client-side ad insertion during trick mode playback |
| US8555315B2 (en) | 2009-04-10 | 2013-10-08 | United Video Properties, Inc. | Systems and methods for navigating a media guidance application with multiple perspective views |
| US8725745B2 (en) | 2009-04-13 | 2014-05-13 | Microsoft Corporation | Provision of applications to mobile devices |
| US8301971B2 (en) * | 2009-05-02 | 2012-10-30 | Yang Liu | Digital broadcasting system and error correction method thereof |
| US8732746B2 (en) | 2009-06-01 | 2014-05-20 | Fourthwall Media, Inc. | System for and method of targeting broadcast messages |
| US20110138417A1 (en) | 2009-12-04 | 2011-06-09 | Rovi Technologies Corporation | Systems and methods for providing interactive content with a media asset on a media equipment device |
| US9032466B2 (en) | 2010-01-13 | 2015-05-12 | Qualcomm Incorporated | Optimized delivery of interactivity event assets in a mobile broadcast communication system |
| US20110177775A1 (en) | 2010-01-13 | 2011-07-21 | Qualcomm Incorporated | Signaling mechanisms, templates and systems for creation and delivery of interactivity events on mobile devices in a mobile broadcast communication system |
| US20110177774A1 (en) | 2010-01-13 | 2011-07-21 | Qualcomm Incorporated | Dynamic generation, delivery, and execution of interactive applications over a mobile broadcast network |
| US8676991B2 (en) | 2010-01-13 | 2014-03-18 | Qualcomm Incorporated | Signaling mechanisms and systems for enabling, transmitting and maintaining interactivity features on mobile devices in a mobile broadcast communication system |
| US9485535B2 (en) | 2010-01-13 | 2016-11-01 | Qualcomm Incorporated | Notification of interactivity event asset delivery sources in a mobile broadcast communication system |
| US8914471B2 (en) | 2010-05-28 | 2014-12-16 | Qualcomm Incorporated | File delivery over a broadcast network using file system abstraction, broadcast schedule messages and selective reception |
-
2011
- 2011-01-11 US US13/004,702 patent/US8914471B2/en active Active
- 2011-05-27 WO PCT/US2011/038434 patent/WO2011150389A1/en active Application Filing
- 2011-05-27 KR KR1020127033547A patent/KR101577108B1/ko not_active Expired - Fee Related
- 2011-05-27 JP JP2013512057A patent/JP5813756B2/ja not_active Expired - Fee Related
- 2011-05-27 CN CN201180026570.2A patent/CN102948159B/zh not_active Expired - Fee Related
- 2011-05-27 EP EP11727571.9A patent/EP2577967A1/en not_active Withdrawn
-
2014
- 2014-12-12 US US14/569,318 patent/US9819726B2/en active Active
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20210073579A (ko) * | 2018-11-23 | 2021-06-18 | 소니그룹주식회사 | 수신된 패킷 스트림의 파일들을 저장하기 위한 버퍼 관리 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102948159B (zh) | 2016-05-04 |
| JP5813756B2 (ja) | 2015-11-17 |
| WO2011150389A1 (en) | 2011-12-01 |
| JP2013534739A (ja) | 2013-09-05 |
| CN102948159A (zh) | 2013-02-27 |
| EP2577967A1 (en) | 2013-04-10 |
| US20110295978A1 (en) | 2011-12-01 |
| KR101577108B1 (ko) | 2015-12-11 |
| US9819726B2 (en) | 2017-11-14 |
| US20150113102A1 (en) | 2015-04-23 |
| US8914471B2 (en) | 2014-12-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101577108B1 (ko) | 파일 시스템 추상화, 브로드캐스트 스케쥴 메시지들 및 선택적 수신을 이용하는 브로드캐스트 네트워크를 통한 파일 전달 | |
| US7729385B2 (en) | Techniques for utilization of spare bandwidth | |
| JP2008533896A (ja) | 放送網においてｅｓｇデータに優先順位を付ける方法 | |
| CN101444086A (zh) | 用于提供快速服务访问的方法和系统 | |
| CN103650390A (zh) | 在电子服务指南中提供信令信息 | |
| CN101490988A (zh) | 移动通信装置用的电子节目指南 | |
| US20120207075A1 (en) | Multicast data delivery mechanism using packet bundling or file delivery framework | |
| RU2370913C2 (ru) | Способ и система достижения ускоренной работы устройств посредством логического разделения управляющей информации | |
| AU2009229621B2 (en) | Method and apparatus for software update of terminals in a mobile communication system | |
| US20110216666A1 (en) | Method of multiplexing over an error-prone wireless broadcast channel | |
| EP1861968B1 (en) | Improving control information acquisition latency by transmitting control information in individually decode-able packets | |
| US20100185717A9 (en) | Method of improving control information acquisition latency by transmitting control information in individually decode-able packets | |
| Lee et al. | Design of middleware for interactive data services in the terrestrial DMB | |
| US20170302971A1 (en) | Delivery of media content and associated metadata using a bonded cellular system | |
| CN101156440A (zh) | 广播网络中的esg数据的优先排序 | |
| HK1113050A (en) | Method and system for achieving faster device operation by logical separation of control information |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| PA0105 | International application |
Patent event date: 20121221 Patent event code: PA01051R01D Comment text: International Patent Application |
|
| PA0201 | Request for examination | ||
| PG1501 | Laying open of application | ||
| E902 | Notification of reason for refusal | ||
| PE0902 | Notice of grounds for rejection |
Comment text: Notification of reason for refusal Patent event date: 20140528 Patent event code: PE09021S01D |
|
| E90F | Notification of reason for final refusal | ||
| PE0902 | Notice of grounds for rejection |
Comment text: Final Notice of Reason for Refusal Patent event date: 20150225 Patent event code: PE09021S02D |
|
| E701 | Decision to grant or registration of patent right | ||
| PE0701 | Decision of registration |
Patent event code: PE07011S01D Comment text: Decision to Grant Registration Patent event date: 20150907 |
|
| GRNT | Written decision to grant | ||
| PR0701 | Registration of establishment |
Comment text: Registration of Establishment Patent event date: 20151207 Patent event code: PR07011E01D |
|
| PR1002 | Payment of registration fee |
Payment date: 20151207 End annual number: 3 Start annual number: 1 |
|
| PG1601 | Publication of registration | ||
| LAPS | Lapse due to unpaid annual fee | ||
| PC1903 | Unpaid annual fee |
Termination category: Default of registration fee Termination date: 20190918 |