WO2004061638A2 - Sharing a radio frequency interface resource - Google Patents

Sharing a radio frequency interface resource Download PDF

Info

Publication number
WO2004061638A2
WO2004061638A2 PCT/US2003/039828 US0339828W WO2004061638A2 WO 2004061638 A2 WO2004061638 A2 WO 2004061638A2 US 0339828 W US0339828 W US 0339828W WO 2004061638 A2 WO2004061638 A2 WO 2004061638A2
Authority
WO
WIPO (PCT)
Prior art keywords
resource
request
requests
application
applications
Prior art date
Application number
PCT/US2003/039828
Other languages
French (fr)
Other versions
WO2004061638A3 (en
Inventor
Linda Welsh
Original Assignee
Intel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corporation filed Critical Intel Corporation
Priority to CN200380107702XA priority Critical patent/CN1839373B/en
Priority to DE60320850T priority patent/DE60320850D1/en
Priority to JP2004565481A priority patent/JP2006512854A/en
Priority to AU2003297093A priority patent/AU2003297093A1/en
Priority to EP03814794A priority patent/EP1579324B1/en
Publication of WO2004061638A2 publication Critical patent/WO2004061638A2/en
Publication of WO2004061638A3 publication Critical patent/WO2004061638A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/42Arrangements for resource management
    • H04H20/426Receiver side
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B1/00Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/38Transceivers, i.e. devices in which transmitter and receiver form a structural unit and in which at least one part is used for functions of transmitting and receiving
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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
    • H04N21/443OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/458Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • H04N21/4583Automatically resolving scheduling conflicts, e.g. when a recording by reservation has been programmed for two programs in the same time slot
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309Transmission or handling of upstream communications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/50Allocation or scheduling criteria for wireless resources
    • H04W72/56Allocation or scheduling criteria for wireless resources based on priority criteria
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N2007/17381Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal the upstream transmission being initiated by the user terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/426Internal components of the client ; Characteristics thereof
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/26Resource reservation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/27Control channels or signalling for resource management between access points
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access, e.g. scheduled or random access
    • H04W74/02Hybrid access techniques
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access, e.g. scheduled or random access
    • H04W74/08Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]

Definitions

  • RF interface resource refers to the hardware and software components of transmitters, receivers, and transceivers used by applications to send or receive signals communicated over the radio frequency range of the electromagnetic spectrum, or to process data carried in those signals, or communicated through other means such as over a traditional data network or through a software interface.
  • This data can be in the form of audio, video, voice, data, or any combination thereof. Examples of applications that use media carried over RF signals include TV viewing, music radio listening, and voice/data communication and exchange.
  • RF signals may be carried over a variety of communications links including over-the-air terrestrial sources, satellite sources, and wireless communications networks.
  • data processed by RF interface resources may be communicated in the form of packet- based data carried over traditional copper wire or optical fiber based data communications networks.
  • the data processed by an RF interface resource may be communicated as signals over a television antenna, a DSL modem, a cable modem, a coaxial cable TV connection.
  • data processed by an RF interface resource such as an MPEG-2 transport stream processed by a demultiplexer, may be carried as data communicated over a USB connection, by a network interface card (NIC) or even through a software programming interface.
  • NIC network interface card
  • a personal computer may have a television (TV) add-in card installed, which provides TV program viewing on the PC.
  • TV television
  • many of today's newer cards provide video cassette recorder-like functions such as recording TN programs when aired for later viewing, using the hard disk for storage of the program.
  • Some TN cards provide support for both analog and digital television viewing.
  • TN signals can also carry data services, in addition to normal TN programs.
  • Some examples of data service applications include the delivery and download of movies, music, software, games, news, and Internet content. The applications receiving this content can be customizable according to user preferences to only receive the content the user is interested in. Just like TN programs, these data services may be scattered across many different RF frequencies or "TN channels.”
  • a TN program recording application may want to tune to channel 3 to record a preselected program, at the same time the user is watching TN with the TN viewer application on channel 5.
  • a PC games download service application might need to turn to channel 10 to get the game the user asked for.
  • the first conflict in this example is over which application gets to tune the tuner to its channel.
  • Figure 1 is an operational depiction of one embodiment of the present invention
  • Figure 2 is a block depiction of one embodiment of the present invention
  • Figure 3 is a flow chart for software in accordance with one embodiment of the present invention
  • Figure 4 is a flow chart for software in accordance with another embodiment of the present invention.
  • Figure 5 is a schematic illustration of a potential contention situation resolvable with one embodiment of the present invention.
  • a platform may include one or more radio frequency (RF) interface resources, such as resources 100 A and 100B, each coupled to a unidirectional or bi-directional communication link interface 102.
  • Signals and data may be carried over a variety of communications links including over-the-air terrestrial sources, satellite sources, wireless communications networks, and copper wire or optical fiber based data communications networks.
  • Examples of the communication link interface 102 used by the RF interface resource to communicate the signals and data it processes include: a television antenna, a DSL modem, a cable modem, a coaxial cable TN connection, a USB connection, a network interface card (NIC) or an application programming interface API or other software interface mechanism to communicate data between the RF interface resource 100 and a software program or the operating system.
  • NIC network interface card
  • the resources 100 A and 100B may be transmitters, receivers, or transceivers, or the individual components thereof such as one or more of the following: a tuner 104, an encoder 105, a decoder 105, a multiplexer 106, a demultiplexer 107, an encryptor 108, a decryptor 109, a modulator 110, and a demodulator 111.
  • the RF interface resources 100 may be coupled to an arbitration module 32.
  • the arbitration module 32 receives all requests for the resources 100 from applications, such as the applications 30a, 30b, and 30c, that are active on the platform.
  • the arbitration module 32 controls access to and from the radio frequency interface resource 100.
  • the arbitration module 32 may be a software component and, in some cases, it may be a portion of an operating system.
  • the arbitration module 32 may allow access to the resources 100 on a selective basis.
  • the arbitration module 32 enforces a priority scheme to decide which application 30 is granted access to one or more RF interface resources 100. It should be understood that in some cases N resources may be accessible to M applications where M is greater than N. Thus, contention may result and the arbitration module 32 may be responsible for serving up access to the N resources by the M applications according to a priority scheme.
  • Some embodiments of the present invention may support a multitude of media services transmitted or received at different times and over different radio frequencies, in an environment constrained by a limited number of RF interface resources.
  • Media in the form of audio, video, voice or data, or any combination thereof, can be communicated over signals carrying data. Examples of how signals and data may be carried include over-the-air terrestrial or satellite transmission, and copper wire or optical fiber networks.
  • An example of a media service is the delivery of Nideo-On-Demand application where movie content is delivered in an MPEG-2 transport stream to a PC or Set top box for viewing
  • Another example of a media service is a rich multi-media Internet application where content is delivered to a cell phone or personal digital assistant (PDA).
  • PDA personal digital assistant
  • Another example of a media service is a gaming or software application where games or other software is delivered to a handheld or portable computer, a desktop PC, or a wireless appliance.
  • Still another example is an MP3 music or MPEG-4 video content is received on your mobile phone or PDA, or the reverse, where pictures captured and uploaded by your mobile phone or PDA are transmitted to someone else..
  • a variety of media services may be provided as a variety of RF frequencies or "channels," just as there are many television channels for TN programs.
  • television programming is just another example of a media service, where the media is television programs, which are delivered on a plurality of RF frequencies reserved for television.
  • those same television RF frequencies can also be used to carry other media services like the Nideo-On-Demand or other data services mentioned above.
  • media services need not be delivered on continuous, 24x7 basis. Rather, some media services may only be available at particular time periods. This is frequently the case for data services now being delivered over analog and digital television.
  • Data content which could include things like video, games, software, Internet, news, stock listings, etc, is often broadcast during discrete, noncontiguous blocks of time throughout the day. Even where data services are broadcast on a continuous basis, data is usually rebroadcast repeatedly over a time period to ensure that the data gets received. Many media service applications tailor what content is actually received to match user preferences, meaning, some content is deliberately skipped or ignored.
  • platforms such as televisions, PCs, PDAs, or mobile phones phones, having only a single radio frequency tuner, can only be tuned to a single radio frequency carrier at a time.
  • more than one of a given type of RF interface resource is provided, but even so, any given platform can only receive or transmit on a finite number of radio frequencies at any given time, and be similarly restricted on the number of data signals it can process simultaneously, as many as the number of give resources allow.
  • the number of concurrent uses for RF interface resources will always exceed the number of RF interface resources available in any practical system.
  • conflicts may arise over the RF interface resource used to receive or transmit content. Similar conflicts between applications may arise over a particular resource, like an encoder or decoder used to process content for viewing, rendering, or play back, after it has been received or before it will be transmitted. These conflicts may. arise because more than one application may require the use of the same RF interface resource at any given time. For example, three different data service applications may compete for the TN tuner, each wanting to tune to its channel to receive its content. When the number of simultaneous requests for resources exceeds the number of available RF interface resources, a problem arises.
  • the contention resolution may involve determining the priority of each application seeking RF interface resource access and granting access based on that priority.
  • Priority is the recognized right to precedence of one application over another, for example by order of urgency or importance.
  • Priority may be assigned in any viable way. In some embodiments, priority can be based on any number or combination of factors, including but not limited to: user preferences; whether an application is paid for or free; the order in which an application appeared, was selected or installed; when or where an application is available; whether an application is essential to the operation of the device; or whether an application requires other hardware or software resources that may or may not be present on the system.
  • Priority may be assigned by the user, the application, or the system, or any combination thereof, to mention a few examples.
  • a processor-based RF reception platform 10 may include a processor-based system 12.
  • the system 12 may include the RF interface resources 100 and the arbitration module 32 in one embodiment.
  • the system 12 may be a personal computer, a set top box, a PDA, or a mobile phone, to mention a few examples.
  • the system 12 may be coupled to an output device 16, such as a display system, such as a television or a computer monitor, a built-in display such as an LCD panel, or may simply use a speaker for output.
  • the system 12 may be coupled to or include an input device 37, such as a keyboard, keypad, mouse, touchpad, pointing device, remote control unit, or microphone for receiving commands and inputs from the user.
  • the input device 37 may be used to change channels on a system with a broadcast TN receiver.
  • a signal may be received by an interface 100 from an antenna, a satellite receiver, a cable receiver or a computer network including the Internet, to mention common examples.
  • the data processed by the RF interface resource 100 may even be communicated by another application via a software programming interface.
  • An RF interface resource 100 in one embodiment, may be a television add-in card on a PC comprising a tuner, demodulator, demultiplexer or decoder. Some embodiments may arbitrate the use of these components individually, or in groups of one or more components.
  • An RF interface resource 100 may be implemented in hardware, or software or in any combination of hardware and software.
  • the system 12 may include an interface 24 that interfaces the system 12 with the resources 100.
  • the interface 24, in one embodiment of the present invention may be coupled to a bus 26, in turn, coupled to an interface 36, that may be a bridge in one embodiment.
  • the interface 36 in one architecture, may be coupled to a storage 28, a processor 40, and the input device 37.
  • the output device 16 may act as the display for the processor-based system 12 and the display for media, in other embodiments, separate displays may be available.
  • one architecture for a processor-based system 12 is shown in Figure 2, the present invention is applicable to any available architecture.
  • the storage 28, in one embodiment of the present invention, may be a hard disk drive (HDD) or a non- volatile storage device such as flash memory.
  • the storage 28 may store a plurality of applications 30 requiring access to RF interface resources 100.
  • a resource arbitration module 32 may also be stored on the storage 28.
  • contention between applications 30 seeking access to the interfaces 100 may be resolved in an advantageous fashion. This contention may arise because multiple applications 30 may wish to access the same RF interface resource at the same time so that the number of requests exceeds the capacity of the system's available resources.
  • the arbitration module 32 controls the ability of applications
  • a schedule is provided that reserves given time slots for given resources as requested by various applications 30 in accordance with one embodiment of the present invention.
  • applications 30 may be assigned time slots to access resources needed to receive data that they expect to be broadcast, for example, based on an available schedule of data service broadcasts.
  • a check at diamond 56 determines whether a conflict exists.
  • a conflict or contention arises when two different applications 30 request access to a limited number of resources 100 at the same time and the requested number of resultant resource usage requests to receive the data services exceeds the capacity of the system 10, such as requests to tune to three different television channels by three applications, when only two television tuners are present to mention one common example.
  • Some other common example would be conflicting requests over: an HDTV demodulator, an MPEG-2 transport stream demultiplexer, or an MPEG-4 decoder. If no conflict arises, the flow simply grants use of the resource 100 according to the prearranged schedule as indicated in block 74.
  • the arbitration module 32 may issue a request to the various applications 30 to indicate their priorities.
  • that priority information may already reside in the arbitration module 32 or may be separately accessible by the application 30 from a database, or may require prompting of the user to supply information, as additional examples.
  • the priority information may be received from the applications 30, in accordance with one embodiment of the present invention, as indicated in block 58.
  • a conflict resolution may be devised based on the relative priorities of different applications 30 as indicated in block 60. For example, in the situation where two applications 30 are requesting resources in the same time period and sufficient resources are not available to provide all requests, the system 10 may allocate the resource based on the priority of different applications 30. Namely, the application 30 with a higher priority gets the requested resource, if available.
  • the applications 30 that receive the requested resource are so advised, as indicated in block 62, and those applications which did not receive the requested time slots are also apprised.
  • responses to the allocation may be received from applications 30 in block 64. In such cases, these responses may advise the application 30 that while the request was made for a given time slot, the application 30 still wants that time slot or some part thereof if it subsequently becomes available.
  • a given application 30 may advise the arbitration module 32 that the application 30 may be able to use less than all of the available time that it requested.
  • some applications 30 that receive priority may advise that they may be able to yield that priority over a portion of the allocated time period.
  • an application may receive sufficient information in less than the entire allocated time period to enable it to achieve the function that it needs to achieve. In such case, the application may then yield its allocation after receiving all the data it needs.
  • check times are set.
  • the check times are times developed based on the application responses to re-check if an application that received the allocation may be able to yield all or part of the allocated resource. Even though the contention may be resolved by assigning the resource based on priority, a recheck may have been requested by an application to determine whether another application subsequently can yield its allocated resource. As one example, in some cases, the same content may be repeatedly broadcast. An application 30 may therefore receive the information it intended to access in a given time slot, at an earlier time and therefore may be willing thereafter to yield its resource allocation.
  • a check at diamond 68 determines whether a check time has arisen.
  • the check time may correspond to the time of the resource contention or may be slightly before or even after that time.
  • a request for yield may be provided to the higher priority application, as indicated in block 70. If the yield request is granted, the schedule may then be revised as indicated in block 72. Thereafter the interface 14 is operated according to the schedule as indicated in block 74.
  • the arbitration module 32 may be part of an operating system, layered on top of an operating system, an application program, or part of an application program interface (API).
  • RF interface resources that are arbitrated include a tuner, a demodulator, a modulator, a demultiplexer, a multiplexer, an encoder, a decoder. Encoding and decoding can mean converting data from one format to another, or converting data from an encrypted format to an unencrypted format.
  • the arbitrated or exclusive use of these resources by applications may be controlled individually, as individual resources, or as a combination several components combined into one logical resource.
  • the granularity or scope of resource arbitration that would be appropriate depends on the needs and purposes of the particular system and its applications.
  • Each of the applications 30 may include a module that interconnects with the arbitration module 32, in accordance with one embodiment of the present invention, as shown in Figure 4. Initially, each application 30 forwards a resource request to the arbitration module 32 as indicated in block 80. Thus, based on available scheduling information, a given application 30 knows that it needs to a resource for a particular time period.. Therefore, the application 30 makes the request for this resource to the arbitration module 32.
  • the application 30 eventually receives a request for priority information from the arbitration module 32, if a conflict arises. If no priority request is received then it may be determined, after the passage of time, the request was granted. If a priority request is received, as indicated in diamond 82, the requested priority information may be provided from the application 30 in one embodiment, as indicated in block 84. Thereafter, the resource requesting application 30 receives a conflict resolution as determined in diamond 86. If the request is unsatisfied, as indicated in diamond 88, a yield may be requested in some cases as indicated in block 90. For example, if the application 30 determines that it must have the resource if at all possible, it can formulate an appropriate yield request to the arbitration agent 32. The application 30 then awaits a decision on the yield request.
  • a higher priority resource allocated application may receive yield requests from the arbitration agent 32, as indicated in block 92. If a yield request is received, an application 30 makes a yield decision as indicated in block 94. It then communicates that yield decision to the arbitration agent 32 as indicated in block 96.
  • an application may yield when it either has processed all the data it needs or the data it still does not have may be communicated in a future time slot where there are no conflicts. Either condition may be known by the potentially yielding application, the system 12 or both. For the application to know that it has processed all the data it needs to, additional metadata, like a data manifest that lists all the necessary data resources, may be provided. The application 30 may have received all of the data it needs as determined from the manifest, and the data may be communicated repeatedly.
  • Metadata may also indicate what data is essential, " which data is optional and which is available by other means.
  • a video on demand application may not yield if it was receiving a movie it knows the user wants, but it may yield if it knows its cache is already full of next week's movie trailers and that is what is being rebroadcast now.
  • An application 30 (or the system 12 itself) may know that a resource may not be needed until a future time due to the availability of scheduling information which indicates when data may be communicated. This scheduling information may be made available in a variety of fashions, including system information carried in the signal itself, or the use of electronic programming guides. Information about what data will be communicated repeatedly and when may be simply additional metadata that may be exposed to the application or system in order to determine whether a yield can happen.
  • FIG. 5 depicting one embodiment, there are three data services X, Y and Z being offered on three different physical channels A, B and C which represent three different RF television frequencies. It may be assumed that the time scale covers twenty- four hours and each service time period is repeated at the same time every day. It can also be assumed that the system 12 has only one television tuner that can be controlled exclusively by one application at a time. If all service applications X, Y and Z start running at system start time, each service requests the system to tune to its respective channel during its requested time slot. The service X request would be granted unconditionally because there are no competing application resource requests. The service Y and Z's request would be handled based on the respective priorities in one embodiment.
  • service Y has a higher priority, then its request would be granted unconditionally and the television tuner 14 would be tuned to channel B starting at time T3 for as long as service Y wants the bandwidth up until time T4. Service Z would not have a chance at the television tuner until time T4 (or sooner if the service Y yields the tuner before then). If the service Z has a higher priority than the service Y, the platform 10 may respond in one of two ways in one embodiment. The platform 10 may tell the service Y that it may tune to channel B until time T5, leaving the choice of whether to tune there at all to the service Y. The service Z would definitely get its data on channel C starting at T5 until T6.
  • the system may check with service Z to determine if the service Z is willing to yield until time T4. If the service Z is willing to yield, the system may stay tuned to channel B until time T4. If the service Z is not willing to yield, the platform 10 may tune to channel C at time T5. If the service Z yields the tuner anytime before time T4, the system may see if service Y still wants the bandwidth, and if so, turn back to channel B.

Abstract

Applications may seek access to a radio frequency interface resource on a processor-based system that exceeds the available capacity of that resource. When more than one application needs access to an RF interface resource at the same time and the available capacity of the RF interface resource does not permit all these requests to be granted, contention resolution may be provided. In one embodiment, the contention resolution may involve determining the priority of each application seeking RF interface resource access and granting access based on that priority.

Description

Sharing A Radio Frequency Interface Resource
Background
This invention relates generally to radio frequency (RF) interface resources that provide access to media. The phrase "RF interface resource" refers to the hardware and software components of transmitters, receivers, and transceivers used by applications to send or receive signals communicated over the radio frequency range of the electromagnetic spectrum, or to process data carried in those signals, or communicated through other means such as over a traditional data network or through a software interface. This data can be in the form of audio, video, voice, data, or any combination thereof. Examples of applications that use media carried over RF signals include TV viewing, music radio listening, and voice/data communication and exchange. RF signals may be carried over a variety of communications links including over-the-air terrestrial sources, satellite sources, and wireless communications networks. In addition to being carried over RF frequencies, data processed by RF interface resources may be communicated in the form of packet- based data carried over traditional copper wire or optical fiber based data communications networks. For example, the data processed by an RF interface resource may be communicated as signals over a television antenna, a DSL modem, a cable modem, a coaxial cable TV connection. Alternatively, data processed by an RF interface resource, such as an MPEG-2 transport stream processed by a demultiplexer, may be carried as data communicated over a USB connection, by a network interface card (NIC) or even through a software programming interface.
A personal computer (PC) may have a television (TV) add-in card installed, which provides TV program viewing on the PC. In addition to viewing of TN as it is broadcast, many of today's newer cards provide video cassette recorder-like functions such as recording TN programs when aired for later viewing, using the hard disk for storage of the program. Some TN cards provide support for both analog and digital television viewing. Particularly with the advent of digital television, TN signals can also carry data services, in addition to normal TN programs. Some examples of data service applications include the delivery and download of movies, music, software, games, news, and Internet content. The applications receiving this content can be customizable according to user preferences to only receive the content the user is interested in. Just like TN programs, these data services may be scattered across many different RF frequencies or "TN channels."
Conflicts arise between multiple applications wanting to tune to different TN channels at the same time. A TN program recording application may want to tune to channel 3 to record a preselected program, at the same time the user is watching TN with the TN viewer application on channel 5. At the same time, a PC games download service application might need to turn to channel 10 to get the game the user asked for. The first conflict in this example is over which application gets to tune the tuner to its channel.
Even if the system had three independent tuners, each with its own demodulator and demultiplexer, a second conflict could occur over the use of a common decoder needed to convert protected or encrypted content into a form useable by each application.
Because current systems allow each application to get direct access to these resources, one application can interfere with the correct operation of other applications, leaving the user clueless as to why a problem occurred. For instance, the TN viewer application, because it lets the user change the TN channel whenever she wants to, may make it impossible for the TN recording application to record desired programs, and the PC games service to successfully download a game (even though the user has paid money for the service). Because of conflicts over the use of these shared resources, the user is usually left completely in the dark as to why the other applications fail (especially if they were the reason why the user invested in a TN card to begin with). The result is equally unsatisfying for data service providers and operators who depend on content being successfully downloaded in order to collect revenue.
Thus, there is a need for ways to resolve contention when the number of active applications requiring the use of an RF interface resource exceeds the number of available RF interface resources.
Brief Description of the Drawings
Figure 1 is an operational depiction of one embodiment of the present invention; Figure 2 is a block depiction of one embodiment of the present invention; Figure 3 is a flow chart for software in accordance with one embodiment of the present invention; Figure 4 is a flow chart for software in accordance with another embodiment of the present invention; and
Figure 5 is a schematic illustration of a potential contention situation resolvable with one embodiment of the present invention.
Detailed Description
Referring to Figure 1, a platform may include one or more radio frequency (RF) interface resources, such as resources 100 A and 100B, each coupled to a unidirectional or bi-directional communication link interface 102. Signals and data may be carried over a variety of communications links including over-the-air terrestrial sources, satellite sources, wireless communications networks, and copper wire or optical fiber based data communications networks. Examples of the communication link interface 102 used by the RF interface resource to communicate the signals and data it processes include: a television antenna, a DSL modem, a cable modem, a coaxial cable TN connection, a USB connection, a network interface card (NIC) or an application programming interface API or other software interface mechanism to communicate data between the RF interface resource 100 and a software program or the operating system. The resources 100 A and 100B may be transmitters, receivers, or transceivers, or the individual components thereof such as one or more of the following: a tuner 104, an encoder 105, a decoder 105, a multiplexer 106, a demultiplexer 107, an encryptor 108, a decryptor 109, a modulator 110, and a demodulator 111.
The RF interface resources 100 may be coupled to an arbitration module 32. The arbitration module 32 receives all requests for the resources 100 from applications, such as the applications 30a, 30b, and 30c, that are active on the platform. The arbitration module 32 controls access to and from the radio frequency interface resource 100. In some embodiments, the arbitration module 32 may be a software component and, in some cases, it may be a portion of an operating system. The arbitration module 32 may allow access to the resources 100 on a selective basis. The arbitration module 32 enforces a priority scheme to decide which application 30 is granted access to one or more RF interface resources 100. It should be understood that in some cases N resources may be accessible to M applications where M is greater than N. Thus, contention may result and the arbitration module 32 may be responsible for serving up access to the N resources by the M applications according to a priority scheme.
Some embodiments of the present invention may support a multitude of media services transmitted or received at different times and over different radio frequencies, in an environment constrained by a limited number of RF interface resources.
Media, in the form of audio, video, voice or data, or any combination thereof, can be communicated over signals carrying data. Examples of how signals and data may be carried include over-the-air terrestrial or satellite transmission, and copper wire or optical fiber networks. An example of a media service is the delivery of Nideo-On-Demand application where movie content is delivered in an MPEG-2 transport stream to a PC or Set top box for viewing Another example of a media service is a rich multi-media Internet application where content is delivered to a cell phone or personal digital assistant (PDA). Another example of a media service is a gaming or software application where games or other software is delivered to a handheld or portable computer, a desktop PC, or a wireless appliance. Still another example is an MP3 music or MPEG-4 video content is received on your mobile phone or PDA, or the reverse, where pictures captured and uploaded by your mobile phone or PDA are transmitted to someone else..
A variety of media services may be provided as a variety of RF frequencies or "channels," just as there are many television channels for TN programs. In fact, television programming is just another example of a media service, where the media is television programs, which are delivered on a plurality of RF frequencies reserved for television. In addition to carrying television programs, those same television RF frequencies can also be used to carry other media services like the Nideo-On-Demand or other data services mentioned above. Unlike television programming in general though, media services need not be delivered on continuous, 24x7 basis. Rather, some media services may only be available at particular time periods. This is frequently the case for data services now being delivered over analog and digital television. Data content, which could include things like video, games, software, Internet, news, stock listings, etc, is often broadcast during discrete, noncontiguous blocks of time throughout the day. Even where data services are broadcast on a continuous basis, data is usually rebroadcast repeatedly over a time period to ensure that the data gets received. Many media service applications tailor what content is actually received to match user preferences, meaning, some content is deliberately skipped or ignored.
As an example, platforms, such as televisions, PCs, PDAs, or mobile phones phones, having only a single radio frequency tuner, can only be tuned to a single radio frequency carrier at a time. In some cases, more than one of a given type of RF interface resource is provided, but even so, any given platform can only receive or transmit on a finite number of radio frequencies at any given time, and be similarly restricted on the number of data signals it can process simultaneously, as many as the number of give resources allow. In practice, the number of concurrent uses for RF interface resources will always exceed the number of RF interface resources available in any practical system.
When services which use different RF frequencies attempt to operate concurrently, conflicts may arise over the RF interface resource used to receive or transmit content. Similar conflicts between applications may arise over a particular resource, like an encoder or decoder used to process content for viewing, rendering, or play back, after it has been received or before it will be transmitted. These conflicts may. arise because more than one application may require the use of the same RF interface resource at any given time. For example, three different data service applications may compete for the TN tuner, each wanting to tune to its channel to receive its content. When the number of simultaneous requests for resources exceeds the number of available RF interface resources, a problem arises.
In one embodiment, the contention resolution may involve determining the priority of each application seeking RF interface resource access and granting access based on that priority. Priority is the recognized right to precedence of one application over another, for example by order of urgency or importance. Priority may be assigned in any viable way. In some embodiments, priority can be based on any number or combination of factors, including but not limited to: user preferences; whether an application is paid for or free; the order in which an application appeared, was selected or installed; when or where an application is available; whether an application is essential to the operation of the device; or whether an application requires other hardware or software resources that may or may not be present on the system. Priority may be assigned by the user, the application, or the system, or any combination thereof, to mention a few examples. Referring to Figure 2, a processor-based RF reception platform 10 may include a processor-based system 12. The system 12 may include the RF interface resources 100 and the arbitration module 32 in one embodiment. The system 12 may be a personal computer, a set top box, a PDA, or a mobile phone, to mention a few examples. The system 12 may be coupled to an output device 16, such as a display system, such as a television or a computer monitor, a built-in display such as an LCD panel, or may simply use a speaker for output. The system 12 may be coupled to or include an input device 37, such as a keyboard, keypad, mouse, touchpad, pointing device, remote control unit, or microphone for receiving commands and inputs from the user. The input device 37, in one embodiment, may be used to change channels on a system with a broadcast TN receiver. A signal may be received by an interface 100 from an antenna, a satellite receiver, a cable receiver or a computer network including the Internet, to mention common examples. The data processed by the RF interface resource 100 may even be communicated by another application via a software programming interface. An RF interface resource 100, in one embodiment, may be a television add-in card on a PC comprising a tuner, demodulator, demultiplexer or decoder. Some embodiments may arbitrate the use of these components individually, or in groups of one or more components. An RF interface resource 100 may be implemented in hardware, or software or in any combination of hardware and software. The system 12 may include an interface 24 that interfaces the system 12 with the resources 100. The interface 24, in one embodiment of the present invention, may be coupled to a bus 26, in turn, coupled to an interface 36, that may be a bridge in one embodiment. The interface 36, in one architecture, may be coupled to a storage 28, a processor 40, and the input device 37. While in one embodiment the output device 16 may act as the display for the processor-based system 12 and the display for media, in other embodiments, separate displays may be available. In addition, while one architecture for a processor-based system 12 is shown in Figure 2, the present invention is applicable to any available architecture.
The storage 28, in one embodiment of the present invention, may be a hard disk drive (HDD) or a non- volatile storage device such as flash memory. The storage 28 may store a plurality of applications 30 requiring access to RF interface resources 100.. In addition, a resource arbitration module 32 may also be stored on the storage 28. In accordance with one embodiment of the present invention, contention between applications 30 seeking access to the interfaces 100 may be resolved in an advantageous fashion. This contention may arise because multiple applications 30 may wish to access the same RF interface resource at the same time so that the number of requests exceeds the capacity of the system's available resources.
Referring to Figure 3, the arbitration module 32 controls the ability of applications
30 to access the resources 100. The requests for the resources are scheduled as indicated in block 54. A schedule is provided that reserves given time slots for given resources as requested by various applications 30 in accordance with one embodiment of the present invention. In one embodiment, applications 30 may be assigned time slots to access resources needed to receive data that they expect to be broadcast, for example, based on an available schedule of data service broadcasts.
A check at diamond 56 determines whether a conflict exists. A conflict or contention arises when two different applications 30 request access to a limited number of resources 100 at the same time and the requested number of resultant resource usage requests to receive the data services exceeds the capacity of the system 10, such as requests to tune to three different television channels by three applications, when only two television tuners are present to mention one common example. Some other common example would be conflicting requests over: an HDTV demodulator, an MPEG-2 transport stream demultiplexer, or an MPEG-4 decoder. If no conflict arises, the flow simply grants use of the resource 100 according to the prearranged schedule as indicated in block 74.
If a conflict is identified, in accordance with one embodiment of the present invention, the arbitration module 32 may issue a request to the various applications 30 to indicate their priorities. Alternatively, that priority information may already reside in the arbitration module 32 or may be separately accessible by the application 30 from a database, or may require prompting of the user to supply information, as additional examples.
The priority information may be received from the applications 30, in accordance with one embodiment of the present invention, as indicated in block 58. In accordance with one embodiment of the present invention, a conflict resolution may be devised based on the relative priorities of different applications 30 as indicated in block 60. For example, in the situation where two applications 30 are requesting resources in the same time period and sufficient resources are not available to provide all requests, the system 10 may allocate the resource based on the priority of different applications 30. Namely, the application 30 with a higher priority gets the requested resource, if available.
In such case, the applications 30 that receive the requested resource are so advised, as indicated in block 62, and those applications which did not receive the requested time slots are also apprised. In some cases, responses to the allocation may be received from applications 30 in block 64. In such cases, these responses may advise the application 30 that while the request was made for a given time slot, the application 30 still wants that time slot or some part thereof if it subsequently becomes available. Also, a given application 30 may advise the arbitration module 32 that the application 30 may be able to use less than all of the available time that it requested. As still another alternative, some applications 30 that receive priority may advise that they may be able to yield that priority over a portion of the allocated time period.
The circumstances that permit a given application to yield its allocation are various. As one example, an application may receive sufficient information in less than the entire allocated time period to enable it to achieve the function that it needs to achieve. In such case, the application may then yield its allocation after receiving all the data it needs.
As indicated in block 66, check times are set. The check times are times developed based on the application responses to re-check if an application that received the allocation may be able to yield all or part of the allocated resource. Even though the contention may be resolved by assigning the resource based on priority, a recheck may have been requested by an application to determine whether another application subsequently can yield its allocated resource. As one example, in some cases, the same content may be repeatedly broadcast. An application 30 may therefore receive the information it intended to access in a given time slot, at an earlier time and therefore may be willing thereafter to yield its resource allocation.
A check at diamond 68 determines whether a check time has arisen. The check time may correspond to the time of the resource contention or may be slightly before or even after that time.
At block 70, when the check time has arrived, a request for yield may be provided to the higher priority application, as indicated in block 70. If the yield request is granted, the schedule may then be revised as indicated in block 72. Thereafter the interface 14 is operated according to the schedule as indicated in block 74.
In some embodiments the arbitration module 32 may be part of an operating system, layered on top of an operating system, an application program, or part of an application program interface (API). Examples of RF interface resources that are arbitrated include a tuner, a demodulator, a modulator, a demultiplexer, a multiplexer, an encoder, a decoder. Encoding and decoding can mean converting data from one format to another, or converting data from an encrypted format to an unencrypted format. The arbitrated or exclusive use of these resources by applications may be controlled individually, as individual resources, or as a combination several components combined into one logical resource. In some embodiments, it may not make sense to have access to the tuner, without access to the demodulator, demultiplexer, and decode components as well, hence, they may be bundled together as a single logical resource. In other embodiments, it may make sense to keep components separate, to allow concurrent use of all components in certain combinations - e.g. those needed for reception for storage and later playback, versus those components needed just for playback (of previously recorded content). The granularity or scope of resource arbitration that would be appropriate depends on the needs and purposes of the particular system and its applications.
Each of the applications 30 may include a module that interconnects with the arbitration module 32, in accordance with one embodiment of the present invention, as shown in Figure 4. Initially, each application 30 forwards a resource request to the arbitration module 32 as indicated in block 80. Thus, based on available scheduling information, a given application 30 knows that it needs to a resource for a particular time period.. Therefore, the application 30 makes the request for this resource to the arbitration module 32.
Thereafter, the application 30 eventually receives a request for priority information from the arbitration module 32, if a conflict arises. If no priority request is received then it may be determined, after the passage of time, the request was granted. If a priority request is received, as indicated in diamond 82, the requested priority information may be provided from the application 30 in one embodiment, as indicated in block 84. Thereafter, the resource requesting application 30 receives a conflict resolution as determined in diamond 86. If the request is unsatisfied, as indicated in diamond 88, a yield may be requested in some cases as indicated in block 90. For example, if the application 30 determines that it must have the resource if at all possible, it can formulate an appropriate yield request to the arbitration agent 32. The application 30 then awaits a decision on the yield request. Simultaneously, a higher priority resource allocated application may receive yield requests from the arbitration agent 32, as indicated in block 92. If a yield request is received, an application 30 makes a yield decision as indicated in block 94. It then communicates that yield decision to the arbitration agent 32 as indicated in block 96.
As two examples, an application may yield when it either has processed all the data it needs or the data it still does not have may be communicated in a future time slot where there are no conflicts. Either condition may be known by the potentially yielding application, the system 12 or both. For the application to know that it has processed all the data it needs to, additional metadata, like a data manifest that lists all the necessary data resources, may be provided. The application 30 may have received all of the data it needs as determined from the manifest, and the data may be communicated repeatedly.
Metadata may also indicate what data is essential," which data is optional and which is available by other means. As an example, a video on demand application may not yield if it was receiving a movie it knows the user wants, but it may yield if it knows its cache is already full of next week's movie trailers and that is what is being rebroadcast now. An application 30 (or the system 12 itself) may know that a resource may not be needed until a future time due to the availability of scheduling information which indicates when data may be communicated. This scheduling information may be made available in a variety of fashions, including system information carried in the signal itself, or the use of electronic programming guides. Information about what data will be communicated repeatedly and when may be simply additional metadata that may be exposed to the application or system in order to determine whether a yield can happen.
In Figure 5, depicting one embodiment, there are three data services X, Y and Z being offered on three different physical channels A, B and C which represent three different RF television frequencies. It may be assumed that the time scale covers twenty- four hours and each service time period is repeated at the same time every day. It can also be assumed that the system 12 has only one television tuner that can be controlled exclusively by one application at a time. If all service applications X, Y and Z start running at system start time, each service requests the system to tune to its respective channel during its requested time slot. The service X request would be granted unconditionally because there are no competing application resource requests. The service Y and Z's request would be handled based on the respective priorities in one embodiment. If service Y has a higher priority, then its request would be granted unconditionally and the television tuner 14 would be tuned to channel B starting at time T3 for as long as service Y wants the bandwidth up until time T4. Service Z would not have a chance at the television tuner until time T4 (or sooner if the service Y yields the tuner before then). If the service Z has a higher priority than the service Y, the platform 10 may respond in one of two ways in one embodiment. The platform 10 may tell the service Y that it may tune to channel B until time T5, leaving the choice of whether to tune there at all to the service Y. The service Z would definitely get its data on channel C starting at T5 until T6. If the service Y does not want the tuner as long as it can get it, shortly before the time T5, the system may check with service Z to determine if the service Z is willing to yield until time T4. If the service Z is willing to yield, the system may stay tuned to channel B until time T4. If the service Z is not willing to yield, the platform 10 may tune to channel C at time T5. If the service Z yields the tuner anytime before time T4, the system may see if service Y still wants the bandwidth, and if so, turn back to channel B. While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention. What is claimed is:

Claims

1. A method comprising: receiving radio frequency interface resource requests on a platform from at least two applications that create contention because the platform does not have the resources to grant both requests; determining the priority of the applications; and based on the priority, granting one of said resource requests.
2. The method of claim 1 including granting all of the resource requests that can be handled by the platform.
3. The method of claim 1 including receiving at least two requests for access to a resource and scheduling those requests automatically.
4. The method of claim 3 including determining when two applications request access to the same resource.
5. The method of claim 4 including obtaining priority information from the requesting applications.
6. The method of claim 4 including obtaining priority information from a database.
7. The method of claim 4 including obtaining priority information from the user.
8. The method of claim 3 including advising the requesting applications of granting the resource request of one of said applications.
9. The method of claim 8 including receiving a response to the granting of the resource request from an application whose request was not granted.
10. The method of claim 9 including, in response to said response from said application whose request was not granted, requesting that the application, whose request was granted, yield the resource to an application whose request was not granted.
11. The method of claim 10 including automatically setting a time to request that an application yield its priority to another application.
12. The method of claim 11 including setting the time to request an application yield close in time to the time of the schedule contention.
13. An article comprising a medium storing instructions that, if executed, enable a processor-based system to: receive a radio frequency interface resource requests from at least two applications that create contention because the available system resource is insufficient to grant both requests; determine the priority of the applications; and grant one of said resource requests based on the priority.
14. The article of claim 13 further storing instructions that enable the processor-based system to receive a plurality of requests for access to the resource and to schedule those requests automatically.
15. The article of claim 14 further storing instructions that enable the processor-based system to determine when two applications request access to the same resource at the same time.
16. The article of claim 15 further storing instructions that enable the processor-based system to obtain priority information from the requesting applications.
17. The article of claim 15 further storing instructions that enable the processor-based system to obtain priority information from a database.
18. The article of claim 15 further storing instructions that enable the processor-based system to advise the requesting applications of the granting of the resource request of one of said applications.
19. The article of claim 18 further storing instructions that enable the processor-based system to receive a response to the granting of the resource request from an application whose request was not granted.
20. The article of claim 19 further storing instructions that enable the processor-based system to request that an application whose request was granted yield the resource to the application whose request was not granted.
21. The article of claim 20 further storing instructions that enable the processor-based system to automatically set a time to request an application yield its priority to another application.
22. The article of claim 21 further storing instructions that enable the processor-based system to set the time to request an application yield close in time to the time of the schedule contention.
23. A system comprising: a processor; and a storage storing instructions that enable the processor to receive radio frequency interface resource requests from at least two applications that create contention because the system does not have the resources to grant both requests, determine the priority of each application and, based on the priority, grant one of the resource requests.
24. The system of claim 23 wherein said storage stores instructions that enable the system to grant as many requests for resources as possible.
25. The system of claim 23 including a broadcast receiver.
26. The system of claim 23 including a television receiver.
27. The system of claim 23 including a radio receiver.
28. The system of claim 23 including one of: a set top box, a personal digital assistant, a desktop computer, a portable computer, a handheld computer, a media server, a media gateway, a mobile phone, a wireless appliance.
29. The system of claim 23 including a radio frequency interface resource coupled to said processor, said resource including at least one element selected from the group including a tuner, a modulator, a demodulator, a multiplexer, a demultiplexer, an encoder, or a decoder.
30. The system of claim 23 including a first resource of a particular type, said type being from the group including a tuner, a modulator, a demodulator, a multiplexer, a demultiplexer, an encoder, a decoder, or any combination thereof, said resource coupled to said processor.
31. The system of claim 30 including a second resource of substantially the same type as said first resource.
32. The system of claim 31 including additional resources of substantially the same type as said first resource.
33. The system of claim 23 wherein said storage stores instructions to receive a plurality of requests for access to a resource and to schedule those requests automatically.
PCT/US2003/039828 2002-12-30 2003-12-12 Sharing a radio frequency interface resource WO2004061638A2 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN200380107702XA CN1839373B (en) 2002-12-30 2003-12-12 Method, equipment and system for sharing a radio frequency interface resource
DE60320850T DE60320850D1 (en) 2002-12-30 2003-12-12 COMMON USE OF A HIGH FREQUENCY INTERFACE AGENCY
JP2004565481A JP2006512854A (en) 2002-12-30 2003-12-12 Sharing radio frequency interface resources
AU2003297093A AU2003297093A1 (en) 2002-12-30 2003-12-12 Sharing a radio frequency interface resource
EP03814794A EP1579324B1 (en) 2002-12-30 2003-12-12 Sharing a radio frequency interface resource

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/331,687 US7574233B2 (en) 2002-12-30 2002-12-30 Sharing a radio frequency interface resource
US10/331,687 2002-12-30

Publications (2)

Publication Number Publication Date
WO2004061638A2 true WO2004061638A2 (en) 2004-07-22
WO2004061638A3 WO2004061638A3 (en) 2005-04-21

Family

ID=32710843

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/039828 WO2004061638A2 (en) 2002-12-30 2003-12-12 Sharing a radio frequency interface resource

Country Status (10)

Country Link
US (3) US7574233B2 (en)
EP (1) EP1579324B1 (en)
JP (2) JP2006512854A (en)
KR (1) KR100737592B1 (en)
CN (2) CN101790238B (en)
AT (1) ATE394738T1 (en)
AU (1) AU2003297093A1 (en)
DE (1) DE60320850D1 (en)
TW (1) TWI237507B (en)
WO (1) WO2004061638A2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1783961A1 (en) * 2005-11-04 2007-05-09 Research In Motion Limited Contention resolution among applications requiring data connections between a mobile communications device and a wireless packet data network
WO2008001147A1 (en) 2006-06-23 2008-01-03 Nokia Corporation Resource-limited electronic device comprising means for prioritizing services
JP2008536419A (en) * 2005-04-15 2008-09-04 トムソン ライセンシング Apparatus and method for managing reception service in local area network
US7474671B2 (en) 2005-11-04 2009-01-06 Research In Motion Limited System and method for resolving contention among applications requiring data connections between a mobile communications device and a wireless network
WO2009116939A2 (en) * 2008-03-21 2009-09-24 Telefonaktiebolaget L M Ericsson (Publ) Prohibiting unnecessary scheduling requests for uplink grants
GB2471486A (en) * 2009-06-30 2011-01-05 Nokia Corp Apparatus and method for resolving resource contention using access priority.
CN104080233A (en) * 2013-03-29 2014-10-01 国民技术股份有限公司 Information broadcasting method and system, lighting equipment of information broadcasting system and connection control device for lighting equipment
EP1836846A4 (en) * 2005-01-12 2016-12-28 Alticast Corp Apparatus and method for resource management in data broadcast receiver

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7610061B2 (en) * 2003-09-20 2009-10-27 Samsung Electronics Co., Ltd. Communication device and method having a common platform
US20050157668A1 (en) * 2003-12-24 2005-07-21 Michael Sivan Wireless remote control and data transfer system
DE102005016510A1 (en) * 2005-04-08 2006-10-12 Buderus Schleiftechnik Gmbh Device for machining hardened workpieces
JP2008543118A (en) 2005-05-31 2008-11-27 松下電器産業株式会社 Broadcast receiving terminal and program execution method
US8208072B2 (en) * 2005-08-05 2012-06-26 Samsung Electronics Co., Ltd. Apparatus for providing multiple screens and method of dynamically configuring multiple screens
KR100753511B1 (en) * 2005-08-24 2007-08-31 엘지전자 주식회사 Method and apparatus of recording broadcasting signal
KR100785104B1 (en) * 2005-10-19 2007-12-12 엘지전자 주식회사 Apparatus and method for resource management of mobile telecommunication terminal
US20080229319A1 (en) * 2007-03-08 2008-09-18 Benoit Marchand Global Resource Allocation Control
CN101299875A (en) * 2007-04-30 2008-11-05 世意法(北京)半导体研发有限责任公司 Inquiry database for solving question of blind base station operation colliding with protective service
EP2218001B1 (en) * 2007-11-02 2017-12-20 QUALCOMM Incorporated Configurable system event and resource arbitration management
EP2173066B1 (en) * 2008-10-01 2012-05-16 STMicroelectronics Srl Method of exchanging information in a Network-on-Chip communication network, corresponding Network-on-Chip communication network and computer program product
US20110231762A1 (en) * 2009-10-30 2011-09-22 Pioneer Corporation Play list generating apparatus, playlist generating method, playlist generating program, and recording medium
US20110117944A1 (en) * 2009-11-17 2011-05-19 Yaxin Cao Method and system for task-level access arbitration between virtual modems in a multi-sim multi-standby communication device
KR101653410B1 (en) 2010-01-11 2016-09-02 삼성전자주식회사 Data transmission/reception method and apparatus for performing contention based access in mobile telecommunication system
EP2579608B1 (en) * 2011-10-07 2019-06-19 Nokia Solutions and Networks Oy Conflict processing accessing a personal TV functionality by a plurality of users
CN106575981A (en) * 2015-05-25 2017-04-19 华为技术有限公司 Method, device, DH, and NFCC for resolving conflict in radiofrequency interface extension
CN108540975B (en) * 2017-03-01 2022-07-01 三星电子株式会社 Method for sharing radio frequency RF resources in dual SIM dual standby device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0964332A1 (en) * 1998-06-10 1999-12-15 Sun Microsystems, Inc. Scheduling processes for resource allocation
US6177931B1 (en) * 1996-12-19 2001-01-23 Index Systems, Inc. Systems and methods for displaying and recording control interface with television programs, video, advertising information and program scheduling information
US6363434B1 (en) * 1999-03-30 2002-03-26 Sony Corporation Of Japan Method of managing resources within a network of consumer electronic devices
EP1205847A1 (en) * 2000-10-23 2002-05-15 Sony International (Europe) GmbH Resource conflict resolution
US20020168178A1 (en) * 2001-05-11 2002-11-14 Rodriguez Arturo A. Channel buffering and display management system for multi-tuner set-top box

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US168178A (en) * 1875-09-28 Improvement in clothes-driers
JPH06295248A (en) * 1993-04-08 1994-10-21 Mitsubishi Electric Corp Task resource release system
EP0788714B1 (en) * 1994-10-24 2006-03-22 Intel Corporation Video indexing protocol
US5615249A (en) * 1994-11-30 1997-03-25 Lucent Technologies Inc. Service prioritization in a cellular telephone system
US5574977A (en) * 1995-04-17 1996-11-12 Telefonaktiebolaget Lm Ericsson System and method for providing priority access and channel assignment in a cellular telecommunication system
US5752193A (en) * 1995-09-01 1998-05-12 Motorola, Inc. Method and apparatus for communicating in a wireless communication system
DE19625161C2 (en) * 1996-06-24 1998-08-06 Siemens Ag Method for controlling the construction and use of transmission paths (bearers) between radio transmission / radio reception devices in wireless telecommunication systems, in particular in a DECT-specific RLL-WLL system integrated as a local message transmission loop in an ISDN system
US6115613A (en) * 1997-07-02 2000-09-05 Telefonaktiebolaget L M Ericsson System and method for providing telephone service to each member of a group of radio telephone subscribers
DE19751110B4 (en) * 1997-11-18 2004-04-08 Siemens Ag Procedure for the allocation of radio resources and facility for radio resource management
US6208865B1 (en) * 1998-08-07 2001-03-27 Samsung Electronics Co., Ltd Cellular telephone system which increases efficiency of reserved channel usage
BR9913127A (en) * 1998-08-20 2001-11-06 Qualcomm Inc System and method for assigning priority access channel in a cell phone system
US6738637B1 (en) * 1998-12-16 2004-05-18 Lucent Technologies Inc. Dynamic variation of class of service in a communication network based on network resources
JP4545939B2 (en) * 1998-12-18 2010-09-15 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Resource acquisition method and apparatus in mobile radio communication system
KR100539871B1 (en) * 1998-12-26 2006-04-21 삼성전자주식회사 How to Display Received Messages on a Television Cell Phone
US6184829B1 (en) * 1999-01-08 2001-02-06 Trueposition, Inc. Calibration for wireless location system
EP1166564A1 (en) 1999-03-30 2002-01-02 Sony Electronics Inc. A method and a device for managing resources in a network
US6282429B1 (en) * 1999-10-20 2001-08-28 Lucent Technologies Inc. System for providing prioritized wireless communication service to wireless communication subscribers
JP3379516B2 (en) * 2000-06-16 2003-02-24 日本電気株式会社 Access control device
US7028329B1 (en) * 2000-10-13 2006-04-11 Seiko Epson Corporation Remote accessible programming
US20030054833A1 (en) * 2001-09-18 2003-03-20 Intel Corporation Application execution method and apparatus
US7876837B2 (en) * 2002-09-30 2011-01-25 Motorola Mobility, Inc. Method for reducing access noise in a spread spectrum communication system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6177931B1 (en) * 1996-12-19 2001-01-23 Index Systems, Inc. Systems and methods for displaying and recording control interface with television programs, video, advertising information and program scheduling information
EP0964332A1 (en) * 1998-06-10 1999-12-15 Sun Microsystems, Inc. Scheduling processes for resource allocation
US6363434B1 (en) * 1999-03-30 2002-03-26 Sony Corporation Of Japan Method of managing resources within a network of consumer electronic devices
EP1205847A1 (en) * 2000-10-23 2002-05-15 Sony International (Europe) GmbH Resource conflict resolution
US20020168178A1 (en) * 2001-05-11 2002-11-14 Rodriguez Arturo A. Channel buffering and display management system for multi-tuner set-top box

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1836846A4 (en) * 2005-01-12 2016-12-28 Alticast Corp Apparatus and method for resource management in data broadcast receiver
JP2008536419A (en) * 2005-04-15 2008-09-04 トムソン ライセンシング Apparatus and method for managing reception service in local area network
JP2011155658A (en) * 2005-11-04 2011-08-11 Research In Motion Ltd System and method for resolving contention among applications requiring data connection between mobile communication device and wireless network
JP2007129715A (en) * 2005-11-04 2007-05-24 Research In Motion Ltd System and method for resolving competition between applications which requests data connection between mobile communication device and wireless network
EP1924037A1 (en) 2005-11-04 2008-05-21 Research In Motion Limited Contention resolution among applications requiring data connections between a mobile communications device and a wireless packet data network
US7474671B2 (en) 2005-11-04 2009-01-06 Research In Motion Limited System and method for resolving contention among applications requiring data connections between a mobile communications device and a wireless network
EP1783961A1 (en) * 2005-11-04 2007-05-09 Research In Motion Limited Contention resolution among applications requiring data connections between a mobile communications device and a wireless packet data network
AU2010257363B2 (en) * 2005-11-04 2013-03-07 3G Licensing S.A. System and method for resolving contention among applications requiring data connections between a mobile communications device and a wireless network
EP2184946A1 (en) * 2005-11-04 2010-05-12 Research in Motion Contention resolution among applications requiring data connections between a mobile communications device and a wireless packet data network
AU2006235810B2 (en) * 2005-11-04 2010-11-11 3G Licensing S.A. System and method for resolving contention among applications requiring data connections between a mobile communications device and a wireless network
US8379666B2 (en) 2005-11-04 2013-02-19 Research In Motion Limited System and method for resolving contention among applications requiring data connections between a mobile communications device and a wireless network
US8189611B2 (en) 2005-11-04 2012-05-29 Research In Motion Limited System and method for resolving contention among applications requiring data connections between a mobile communications device and a wireless network
EP2033465A1 (en) * 2006-06-23 2009-03-11 Nokia Corporation Resource-limited electronic device comprising means for prioritizing services
EP2033465A4 (en) * 2006-06-23 2011-08-24 Nokia Corp Resource-limited electronic device comprising means for prioritizing services
WO2008001147A1 (en) 2006-06-23 2008-01-03 Nokia Corporation Resource-limited electronic device comprising means for prioritizing services
WO2009116939A2 (en) * 2008-03-21 2009-09-24 Telefonaktiebolaget L M Ericsson (Publ) Prohibiting unnecessary scheduling requests for uplink grants
US8582514B2 (en) 2008-03-21 2013-11-12 Telefonaktiebolaget L M Ericsson (Publ) Prohibiting unnecessary scheduling requests for uplink grants
US8861474B2 (en) 2008-03-21 2014-10-14 Telefonaktiebolaget L M Ericsson (Publ) Prohibiting unnecessary scheduling requests for uplink grants
EP2449839A1 (en) * 2009-06-30 2012-05-09 Nokia Corp. An apparatus and a method for resource contention
WO2011001355A1 (en) 2009-06-30 2011-01-06 Nokia Corporation An apparatus and a method for resource contention
GB2471486A (en) * 2009-06-30 2011-01-05 Nokia Corp Apparatus and method for resolving resource contention using access priority.
EP2449839A4 (en) * 2009-06-30 2014-02-26 Nokia Corp An apparatus and a method for resource contention
CN104080233A (en) * 2013-03-29 2014-10-01 国民技术股份有限公司 Information broadcasting method and system, lighting equipment of information broadcasting system and connection control device for lighting equipment
CN104080233B (en) * 2013-03-29 2017-04-05 国民技术股份有限公司 Information broadcast method, system and its luminaire and connection control device

Also Published As

Publication number Publication date
WO2004061638A3 (en) 2005-04-21
US20040209643A1 (en) 2004-10-21
US7574233B2 (en) 2009-08-11
CN1839373B (en) 2010-05-05
US20090290490A1 (en) 2009-11-26
KR100737592B1 (en) 2007-07-10
US7899493B2 (en) 2011-03-01
TWI237507B (en) 2005-08-01
CN1839373A (en) 2006-09-27
EP1579324B1 (en) 2008-05-07
US8165631B2 (en) 2012-04-24
CN101790238A (en) 2010-07-28
DE60320850D1 (en) 2008-06-19
EP1579324A2 (en) 2005-09-28
US20110117950A1 (en) 2011-05-19
ATE394738T1 (en) 2008-05-15
CN101790238B (en) 2012-05-30
AU2003297093A8 (en) 2004-07-29
JP2006512854A (en) 2006-04-13
TW200415921A (en) 2004-08-16
JP2009194941A (en) 2009-08-27
AU2003297093A1 (en) 2004-07-29
KR20050093811A (en) 2005-09-23

Similar Documents

Publication Publication Date Title
US7899493B2 (en) Sharing a radio frequency interface resource
US9961401B2 (en) Media content crowdsource
US9288539B2 (en) System and method for a user interface to manage the recording, downloading and sharing of content from multiple sources
US9979996B2 (en) Method and system for operating a multi-room digital video recording system
US9143832B2 (en) Customized content calendar
US7526788B2 (en) Graphic user interface alternate download options for unavailable PRM content
RU2449476C2 (en) Delivery of individual content via broadcasting network
US9521463B2 (en) Method and system of using idle receiving unit resources for receiving content and communicating the content to other receiving units in the network
KR20020094027A (en) Activity schedule controls personalized electronic content guide
JP2001292436A (en) Management unit and method
US11496791B2 (en) Devices, systems and processes for facilitating seamless use of tuners across multiple devices within a local area network
KR20070013717A (en) Method and device for providing broadcasting service according to broadcasting organization by user
US20220086527A1 (en) Seamless timers
KR100655498B1 (en) Establishment method for private television system on the internet
WO2008105567A1 (en) Establishment method for private television system on the internet
KR20080038691A (en) System for network electronic program guide service, client unit and apparatus for receiving digital broadcasting

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003814794

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 20038A7702X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2004565481

Country of ref document: JP

Ref document number: 1020057012342

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 1020057012342

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2003814794

Country of ref document: EP