Patent Application
20100220643
Radio communication systems, such as a wireless data networks (e.g., Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) systems, spread spectrum systems (such as Code Division Multiple Access (CDMA) networks), Time Division Multiple Access (TDMA) networks, WiMAX (Worldwide Interoperability for Microwave Access), etc.), provide users with the convenience of mobility along with a rich set of services and features. This convenience has spawned significant adoption by an ever growing number of consumers as an accepted mode of communication for business and personal uses, resulting in a high population of subscribers. The telecommunication industry, from manufacturers to service providers, has agreed at great expense and effort to develop standards for communication protocols that underlie the various services and features to ensure interoperability and efficient network operations.
Therefore, there is a need for an approach for providing efficient network operations, while being mindful of developing and already developed standards and protocols.
According to one embodiment of the invention, a method comprises configuring a multicast group to include one or more neighboring nodes of a meshed wireless network. The method also comprises assigning a multicast link identifier to each link to the neighboring nodes. Further, the method comprises generating scheduling information for distribution to the multicast group over the corresponding links.
According to another embodiment of the invention, an apparatus comprises logic configured to configure a multicast group to include one or more neighboring nodes of a meshed wireless network, to assign a multicast link identifier to each link to the neighboring nodes, and to generate scheduling information for distribution to the multicast group over the corresponding links.
According to another embodiment of the invention, an apparatus comprises means for configuring a multicast group to include one or more neighboring nodes of a meshed wireless network. The apparatus also comprises means for assigning a multicast link identifier to each link to the neighboring nodes. Further, the apparatus comprises means for generating scheduling information for distribution to the multicast group over the corresponding links.
According to another embodiment of the invention, a system comprises a plurality of nodes arranged as a meshed network, wherein one of the nodes is configured to distribute scheduling information using a multicast protocol to neighboring ones of the nodes, to generate a multicast request message specifying bandwidth requests and slot availability information to the neighboring nodes in the multicast group, and to receive a first grant message, in response to the request message, specifying a set of slots corresponding to the slot availability information. The one node is further configured to track responses from the neighboring nodes designated as requestee nodes, to send a second grant message to indicate a final multicast schedule to the neighboring nodes, and to receive a third grant message from the neighboring nodes confirming the final multicast schedule, the third grant message being further provided to neighboring nodes of the requestee nodes. The one node is further configured to transmit data irrespective of whether the third grant message is received.
According to another embodiment of the invention, a method comprises receiving a multicast scheduling request from a requester node over a meshed wireless network, wherein a multicast group is formed by neighboring nodes of the requester. The method also comprises sending a grant to the requester in response to the request to indicate a selection of transmission opportunities. Further, the method comprises receiving a multicast schedule from the requestor, wherein multicast schedule specifies one or more of the transmission opportunities, and confirming the multicast schedule.
According to yet another embodiment of the invention, an apparatus comprises a first module configured to receive a multicast scheduling request from a requester node over a meshed wireless network, wherein a multicast group is formed by neighboring nodes of the requester. The apparatus also comprises a second module to send a grant to the requester in response to the request to indicate a selection of transmission opportunities. Further, the first module is configured to receive a multicast schedule from the requestor, wherein multicast schedule specifies one or more of the transmission opportunities, and the second module is configured to confirm the multicast schedule.
Still other aspects, features, and advantages of the invention are readily apparent from the following detailed description, simply by illustrating a number of particular embodiments and implementations, including the best mode contemplated for carrying out the invention. The invention is also capable of other and different embodiments, and its several details can be modified in various obvious respects, all without departing from the spirit and scope of the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.
The embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings:
An apparatus, method, and software for multicasting scheduling information are disclosed. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. It is apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments of the invention.
Although the embodiments of the invention are discussed with respect to a wireless communication network (e.g., compliant with Institute of Electrical & Electronics Engineers (IEEE) 802.16) utilizing multicasting, it is recognized by one of ordinary skill in the art that the embodiments of the inventions have applicability to any type of communication system and equivalent functional capabilities.
In the wireless case, the base station 103a employs a transceiver 107, which transmits information to the UE 101a via one or more antennas 109 for transmitting and receiving electromagnetic signals. For instance, the base station 103a may utilize a Multiple Input Multiple Output (MIMO) antenna system 109 for supporting the parallel transmission of independent data streams to achieve high data rates between the UE 101a and base station 103a. The base station 103, in an exemplary embodiment, uses OFDM (Orthogonal Frequency Divisional Multiplexing) as a downlink (DL) transmission scheme and a single-carrier transmission (e.g., SC-FDMA (Single Carrier-Frequency Division Multiple Access) with cyclic prefix for the uplink (UL) transmission scheme. SC-FDMA can also be realized using a DFT-S-OFDM principle, which is detailed in 3GGP TR 25.814, entitled “Physical Layer Aspects for Evolved UTRA,” v.1.5.0, May 2006 (which is incorporated herein by reference in its entirety). SC-FDMA, also referred to as Multi-User-SC-FDMA, allows multiple users to transmit simultaneously on different sub-bands.
Furthermore, the base station 103 includes a scheduling logic 111 and a multicast logic 113 to provide a mechanism creating a contention-free multicast schedule between a source node and a group of target nodes.
For the purposes of illustration, the communication system of
In an exemplary embodiment, the communication system of
In an exemplary embodiment, each of the base stations 103 uses a medium access control layer (MAC) to allocate uplink and downlink bandwidth. As shown, Orthogonal Frequency Division Multiplexing (OFDM) is utilized to communicate from one base station to another base station. For example, IEEE 802.16x defines a MAC (media access control) layer that supports multiple physical layer (PHY) specifications. For instance, IEEE 802.16a specifies three PHY options: an OFDM with 256 sub-carriers; OFDMA, with 2048 sub-carriers; and a single carrier option for addressing multipath problems. Additionally, IEEE 802.16a provides for adaptive modulation. For example, IEEE 802.16j specifies a multihop relay network, which can employ one or more relay stations to extend radio coverage.
The service areas of the RAN can extend, for instance, from 31 to 50 miles (e.g., using 2-11 GHz). The RAN can utilize point-to-multipoint or mesh topologies. Under the mobile standard, users can communicate via handsets within about a 50 mile range. Furthermore, the radio access network can support IEEE 802.11 hotspots.
The communication system of
According to one embodiment, the nodes (e.g., BSs 103 and relay stations 105 and UEs 101) can form a mesh network, as explained in the architecture of
According to one embodiment, a four-way handshake procedure (as shown in
Traditionally, in the distributed scheduling of typical WMNs (e.g., IEEE 802.16 mesh mode), two directional physical links exist between every pair of neighboring nodes. Each directional physical link has a link ID, which is assigned by the transmitting node when the link is created between the transmitting node and the receiving node. The transmitting node uses the link ID to address the receiving node. The receiving node knows from the link ID and the transmitting Node ID of a received packet whether this packet targets for itself. Data packet transmission is scheduled over a physical link between a transmitting node and a receiving node, i.e., in a unicast way. Broadcast is used when controlling messages are transmitted. Thus, in traditional protocols of these WMNs, MAC-layer multicast is not supported, because there is neither a scheduling procedure for multicast transmission, nor a multicast addressing method.
Two examples are given below to illustrate the potential drawbacks of conventional systems. In the first scenario, group data dissemination is examined. In
It is assumed that Node C has the same data packets to send to the group of nodes B, D, F. Traditionally, without MAC-layer multicast, the same packets can be scheduled serially over the links (C, B), (C, F) and (C, D). Because the same data are transmitted three times, network resources are wasted. On the other hand, if Node C schedules a broadcast transmission for the packets, then Node G cannot use the very opportunity to transmit data to Node H; although the following is noted: 1) Node G need not receive the broadcast packets; 2) Node H is not interfered by the broadcast; and 3) Nodes B/F/D are not interfered by the transmission of Node G. In this case, though transmitting energy would be saved, bandwidths of uncorrelated links tend to be lost. However, if a multicast transmission could be scheduled in this scenario, energy and bandwidth will be saved simultaneously. These savings are particularly prominent with in low-speed real-time applications, such as real-time gaming.
As a second example, when low-speed real-time traffic are transmitted from a node to multiple other nodes in an 802.16/rooftop mesh network and distributed scheduling is used, the transmission efficiency is poor because of the overhead (e.g., the PHY (physical layer) preamble) added to the data packets. By way of illustration, Voice over IP (VoIP) traffic is transported over the network; i.e., VoIP traffic from Node C to Nodes B, D and F simultaneously. For example, if Global System for Mobile Communications (GSM) 6.10 is chosen for the voice codec, there is a 33-byte voice packet every 20 ms for every VoIP link. Under the conventional system, such traffic is scheduled over the three links separately. For every link, the overhead of a mesh MAC PDU (Protocol Data Unit) is 12 bytes, including a 6-byte MAC header, a 2-byte mesh subheader and an optional 4-byte CRC (Cyclic Redundancy Check). The IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-time Transport Protocol) header is 40-byte long. Thus, the PHY payload of a VoIP packet is about 85 bytes, which typically needs 2 Orthogonal Frequency Division Modulation (OFDM) symbols. Otherwise, every PHY burst in 802.16 mesh mode has a preamble of 2 OFDM symbols. Therefore, to transmit all the three VoIP traffic, at least (2+2)*3=12 OFDM symbols are needed every 20 ms—this is not efficient.
However, it is recognized that if the small packets could be multiplexed into a single PHY burst and multicast to the target node group, according to an exemplary embodiment, the transmission efficiency can be much improved. Under this approach, only one preamble and one MAC overhead is needed. Therefore, every 20 ms at most 2*3+2=8 OFDM symbols are needed to transmit the packets. In certain scenarios, the three IP/UDP/RTP headers can be replaced with three 2-byte mini-headers plus one IP/UDP header of 28 bytes. In this case, the overall PHY overhead is (33+2)*3+28+12=145 bytes, which is typically about 3 to 4 OFDM symbols. Consequently, inclusive of the preamble, at most 6 symbols are needed.
In
The four-way handshake scheduling procedure, as shown in
A grant message (MSH-DSCH:Grant) is sent back to the requester from every requestee to indicate a set of all the slots that could be used by the requestee in the suggested availabilities. Because a requestee cannot know the selection of transmission opportunities by other requestees, it selects a maximum possible number of transmission opportunities from the suggested ones from the requester, so that the requester can decide the final schedule using the intersection of the requestees' selections. Thus, the schedule granted in this message is only a temporary schedule (reservation). The neighbors of the requestees not involved in this multicast schedule can assume the transmissions take place as granted by the temporary schedule.
In
In step 315, the process determines whether two or more grants have been received. If multiple grants have been received, then the above steps 307-313 can be performed. Otherwise, as in step 317, a grant (with zero transmission opportunities specified) can indicate the failure of the schedule. Namely, if there are no possible transmission opportunities that can be found for the multicast, then a schedule with zero transmission opportunity will be sent to the requestees in the grant message to announce the failure of the multicast schedule (step 319).
Each requestee checks the grant message from the requester. In step 343, it is determined whether the final schedule is possible. If the granted slots are available to the requestee, the requestee will send for the second time a grant message, as in step 345, to the requester to confirm the final schedule, and to inform all its neighbors that the temporary schedule granted is cancelled (step 347). The neighbors of the requestees not involved in this multicast schedule assume the transmissions are provided as granted by the new schedule. If the slots granted by the requester are not available to the requestee, the requestee knows that it is now excluded from the multicast link and can still send a grant message to cancel the temporary schedule that was previously granted.
It is noted that there are some exceptional circumstances in which the grant from the requester cannot reach a requestee. In this case, the requestee can automatically quit from the multicast schedule after timeout and send a grant message to cancel the temporary schedule that was granted.
As shown in
Next, the requester successfully receives the temporary bandwidth grants and decides a feasible schedule. The request then broadcasts to its neighbors a grant message including the multicast schedule information, as in step 405. Subsequently, the two requestees successfully receive the grant message. Each one broadcasts, as in step 407, a grant message to confirm the final multicast schedule to the requester and to inform all its neighbors to release the temporary schedule. The above steps 401-407 constitute the four-way handshake.
Every multicast transmission is identified by a multicast link ID. The link ID can be created before or during the four-way handshake. After all the scheduled transmissions finish, the source node can choose to release the link ID or not. The procedure to create/release the multicast group link ID of target nodes is as follows. To create the multicast link ID, a request for every requestee to create the new multicast link ID is transmitted in a MSH-DSCH message from the requester. Thereafter, a grant to confirm the creation is sent back to the requester in a MSH-DSCH message from every requestee.
To release the multicast link ID, a request for every requestee to release the new multicast link ID is transmitted in a MSH-DSCH message from the requester. A grant to confirm the release is sent back to the requester in a MSH-DSCH message from every requestee.
If the multicast link ID does not exist before the multicast scheduling handshake, the multicast link ID creation can be performed using the same messages as those in the first two steps of the four-way handshake procedure. When the multicast link ID is created, two (directional) link IDs between the source and every target node involved in the multicast are provided. The first one is the formerly assigned unicast link ID when creating the unicast link between the two nodes. The second one is the multicast link ID for the multicast transmission, which is a common link ID to all of the target nodes.
In a three-way handshake (as employed in the 802.16/rooftop WMN distributed scheduling), several messages have been defined that can be used and/or modified for the four-way handshake procedure. That is, it is possible to introduce multicast transmission by modifying the messages so that the procedures defined here are supported. For example, modifications are made to the mesh distributed scheduling message (MSH-DSCH) of 802.16 mesh mode.
According to one embodiment, the entries of the modified MSH-DSCH message (over the conventional format) are shown in Table 1 (in bold text). The entries of the original MSH-DSCH message are mainly preserved, except that the reserved bits are modified to be two flags, whose meaning are explained Table 1. Therefore, when the two flags are all set to be zero, i.e., no special multicast function is included, the message resembles the original version. By way of example, it is assumed that the expiration times of T0 and T1 (in
The bandwidth request/grant information elements (IEs) are of the same format for the cases of both multicast and original unicast transmission, except for the temporary schedule grant IE for the second step (step 403) of the procedure.
When the request/grant is related to a multicast transmission, the link ID of the multicast is used in the IE by the requester. After a node receives a bandwidth request to it, it judges from the link ID that whether this request is for a multicast transmission. If it is and only for this case, the requestee transmits MSH-DSCH Multicast Temporary Grant IE in the next MSH-DSCH message to grant the transmission, as the second step (step 403) of the four-way handshake. In the third and fourth steps (steps 405 and 407) of the procedure, the MSH-DSCH Grant IE will be used. The entries of the MSH-DSCH Multicast Temporary Grant IE are shown in Table 2.
The multicast link ID is created and released using the MSH-DSCH Multicast link IE, the entries of which are shown in Table 3.
The multicast link ID can be created before or simultaneously with the multicast bandwidth scheduling handshake. For the link ID creation process before the scheduling, the source node sends a Multicast link request IE in a MSH-DSCH message with the grant/request flag being set to 1 and the creation/release flag being 0. If the receiving node receives the message and accepts this creation, the receiving node sends back a Multicast link grant IE with the flags set according to Table 3. Otherwise, the node sends nothing.
For the link ID creation process (performed, e.g., simultaneously, with the scheduling handshake), in the bandwidth request of a multicast transmission, a multicast link creation request IE is involved in the MSH-DSCH:Request message from the requester. The multicast link ID in the link creation request IE is the same with the one in the bandwidth request IE. In this case, the requestees add themselves to link denoted by the multicast link ID immediately and make the MSH-DSCH:Grant messages to grant the bandwidth request. Multicast link creation grant IEs is involved in the same MSH-DSCH:Grant messages from the requestees in the second step (step 403) of the procedure.
The multicast link ID is released also by the multicast link IE with the flags set according to Table 3, which can be performed whenever the source node wants to, after or before the finish of the multicast transmission as scheduled. If the source node uses the IE to inform the target nodes that the multicast link ID should be released before the transmission finishes as scheduled, thereby terminating the multicast transmission. The requestees can grant the release using the Multicast link IE in a MSH-DSCH message thereafter and release the remaining reserved transmission opportunities. It is also contemplated that after the multicast transmission finishes per the schedule, the source node does not release the multicast link ID, which will be left available for future usage.
Two kinds of distributed scheduling are defined in the 802.16 mesh mode: coordinated and uncoordinated. In the uncoordinated distributed scheduling, the scheduling messages are transmitted in a contention-based way. Accordingly, in an exemplary embodiment, multicast scheduling can also be contention-based. For the coordinated scheduling, the protocol speculates that the MSH-DSCH is to be sent in a coordinated way, namely in the collision-free scheduling control subframe based on the pseudo-random distributed election algorithm.
As mentioned, delay can be relatively longer under the four-way multicast scheduling approach, as opposed to three-way unicast scheduling. Consequently, the following approach is explained to minimize this delay. The temporary grants in second step (step 403) of the handshake and the final grants in the fourth step (step 407) are still transmitted in the control subframe. The grant message of the third step (step 405) is transmitted in the scheduled transmission opportunities in the data subframe, which have already been reserved temporarily by the grants in the second step. As earlier mentioned, the requester multicasts the data after the third step, regardless of whether it has already received the grants of the fourth step. In this way, the delay of the whole procedure can be significantly reduced (e.g., not longer than the three-way procedure for unicast), while the grant messages can be transmitted in a contention-free manner.
The above approach can also support a multiplex-multicast method for low-speed real-time traffic. It is noted that the bandwidth requested by the requester may be larger than what is finally granted, because the bandwidth for this kind of multicast is related to the number of the requestees. The requester requests for the bandwidth reservation that could contain the data for all the requestees. However, some requestees may not be able to join the multicast. In this case, the data to be multicasted will be less than requested. The requester will compute the final bandwidth reservation based on the maximum number of requestees that can receive the data.
The described processes provide, according to certain embodiments, MAC-layer multicast in the 802.16/rooftop distributed scheduled WMN. This approach advantageously can improve power and bandwidth efficiency when group transmission and low-speed real-time applications are transmitted over it.
Subscriber or mobile stations 501 can communicate with an access service network (ASN) 503, which includes one or more base stations (BS) 505. In this exemplary system, the BS 505, in addition to providing the air interface to the mobile stations 501, possesses such management functions as handoff triggering and tunnel establishment, radio resource management, quality of service (QoS) policy enforcement, traffic classification, DHCP (Dynamic Host Control Protocol) proxy, key management, session management, and multicast group management.
The base station 505 has connectivity to an access network 507. The access network 507 utilizes an ASN gateway 509 to access a connectivity service network (CSN) 511 over, for example, a data network 513. By way of example, the network 513 can be a public data network, such as the global Internet.
The ASN gateway 509 provides a Layer 2 traffic aggregation point within the ASN 503. The ASN gateway 509 can additionally provide intra-ASN location management and paging, radio resource management and admission control, caching of subscriber profiles and encryption keys, AAA client functionality, establishment and management of mobility tunnel with base stations, QoS and policy enforcement, foreign agent functionality for mobile IP, and routing to the selected CSN 511.
The CSN 511 interfaces with various systems, such as application service provider (ASP) 515, a public switched telephone network (PSTN) 517, and a Third Generation Partnership Project (3GPP)/3GPP2 system 519, and enterprise networks (not shown).
The CSN 511 can include the following components: Access, Authorization and Accounting system (AAA) 521, a mobile IP-Home Agent (MIP-HA) 523, an operation support system (OSS)/business support system (BSS) 525, and a gateway 527. The AAA system 521, which can be implemented as one or more servers, provide support authentication for the devices, users, and specific services. The CSN 511 also provides per user policy management of QoS and security, as well as IP address management, support for roaming between different network service providers (NSPs), location management among ASNs.
R4 is defined between ASNs 503a and 503b to support inter-ASN mobility. R5 is defined to support roaming across multiple NSPs (e.g., visited NSP 529a and home NSP 529b).
As mentioned, other wireless systems can be utilized, such as 3GPP LTE, as next explained.
The communication system 600 is compliant with 3GPP LTE, entitled “Long Term Evolution of the 3GPP Radio Technology” (which is incorporated herein by reference in its entirety). As shown in
MME (Mobile Management Entity)/Serving Gateways 601 are connected to the eNBs 103 in a full or partial mesh configuration using tunneling over a packet transport network (e.g., Internet Protocol (IP) network) 603. Exemplary functions of the MME/Serving GW 601 include distribution of paging messages to the eNBs 103, termination of U-plane packets for paging reasons, and switching of U-plane for support of UE mobility. Since the GWs 601 serve as a gateway to external networks, e.g., the Internet or private networks 603, the GWs 601 include an Access, Authorization and Accounting system (AAA) 605 to securely determine the identity and privileges of a user and to track each user's activities. Namely, the MME Serving Gateway 601 is the key control-node for the LTE access-network and is responsible for idle mode UE tracking and paging procedure including retransmissions. Also, the MME 601 is involved in the bearer activation/deactivation process and is responsible for selecting the SGW (Serving Gateway) for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation.
A more detailed description of the LTE interface is provided in 3GPP TR 25.813, entitled “E-UTRA and E-UTRAN: Radio Interface Protocol Aspects,” which is incorporated herein by reference in its entirety.
In
As seen in
The MME 608, as a key control node, is responsible for managing mobility UE identifies and security parameters and paging procedure including retransmissions. The MME 608 is involved in the bearer activation/deactivation process and is also responsible for choosing Serving Gateway 610 for the UE 101. MME 608 functions include Non Access Stratum (NAS) signaling and related security. MME 608 checks the authorization of the UE 101 to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE 101 roaming restrictions. The MME 608 also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME 608 from the SGSN (Serving GPRS Support Node) 614.
The SGSN 614 is responsible for the delivery of data packets from and to the mobile stations within its geographical service area. Its tasks include packet routing and transfer, mobility management, logical link management, and authentication and charging functions. The S6a interface enables transfer of subscription and authentication data for authenticating/authorizing user access to the evolved system (AAA interface) between MME 608 and HSS (Home Subscriber Server) 616. The S10 interface between MMEs 608 provides MME relocation and MME 608 to MME 608 information transfer. The Serving Gateway 610 is the node that terminates the interface towards the E-UTRAN 612 via S1-U.
The S1-U interface provides a per bearer user plane tunneling between the E-UTRAN 612 and Serving Gateway 610. It contains support for path switching during handover between eNBs 103. The S4 interface provides the user plane with related control and mobility support between SGSN 614 and the 3GPP Anchor function of Serving Gateway 610.
The S12 is an interface between UTRAN 606 and Serving Gateway 610. Packet Data Network (PDN) Gateway 618 provides connectivity to the UE 101 to external packet data networks by being the point of exit and entry of traffic for the UE 101. The PDN Gateway 618 performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening. Another role of the PDN Gateway 618 is to act as the anchor for mobility between 3GPP and non-3GPP technologies such as WiMax and 3GPP2 (CDMA 1X and EvDO (Evolution Data Only)).
The S7 interface provides transfer of QoS policy and charging rules from PCRF (Policy and Charging Role Function) 620 to Policy and Charging Enforcement Function (PCEF) in the PDN Gateway 618. The SGi interface is the interface between the PDN Gateway and the operator's IP services including packet data network 622. Packet data network 622 may be an operator external public or private packet data network or an intra operator packet data network, e.g., for provision of IMS (IP Multimedia Subsystem) services. Rx+ is the interface between the PCRF and the packet data network 622.
As seen in
The eNB 103 communicates with the aGW 601 (Access Gateway) via an S1 interface. The aGW 601 includes a User Plane 601a and a Control plane 601b. The control plane 601b provides the following components: SAE (System Architecture Evolution) Bearer Control 635 and MM (Mobile Management) Entity 637. The user plane 601b includes a PDCP (Packet Data Convergence Protocol) 639 and a user plane functions 641. It is noted that the functionality of the aGW 601 can also be provided by a combination of a serving gateway (SGW) and a packet data network (PDN) GW. The aGW 601 can also interface with a packet network, such as the Internet 643.
In an alternative embodiment, as shown in
In the system of
The eNB 103 interfaces via the S1 to the Serving Gateway 645, which includes a Mobility Anchoring function 647. According to this architecture, the MME (Mobility Management Entity) 649 provides SAE (System Architecture Evolution) Bearer Control 651, Idle State Mobility Handling 653, and NAS (Non-Access Stratum) Security 655.
One of ordinary skill in the art would recognize that the processes for scheduling may be implemented via software, hardware (e.g., general processor, Digital Signal Processing (DSP) chip, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Arrays (FPGAs), etc.), firmware, or a combination thereof. Such exemplary hardware for performing the described functions is detailed below.
The computing system 700 may be coupled via the bus 701 to a display 711, such as a liquid crystal display, or active matrix display, for displaying information to a user. An input device 713, such as a keyboard including alphanumeric and other keys, may be coupled to the bus 701 for communicating information and command selections to the processor 703. The input device 713 can include a cursor control, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor 703 and for controlling cursor movement on the display 711.
According to various embodiments of the invention, the processes described herein can be provided by the computing system 700 in response to the processor 703 executing an arrangement of instructions contained in main memory 705. Such instructions can be read into main memory 705 from another computer-readable medium, such as the storage device 709. Execution of the arrangement of instructions contained in main memory 705 causes the processor 703 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the instructions contained in main memory 705. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the embodiment of the invention. In another example, reconfigurable hardware such as Field Programmable Gate Arrays (FPGAs) can be used, in which the functionality and connection topology of its logic gates are customizable at run-time, typically by programming memory look up tables. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The computing system 700 also includes at least one communication interface 715 coupled to bus 701. The communication interface 715 provides a two-way data communication coupling to a network link (not shown). The communication interface 715 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. Further, the communication interface 715 can include peripheral interface devices, such as a Universal Serial Bus (USB) interface, a PCMCIA (Personal Computer Memory Card International Association) interface, etc.
The processor 703 may execute the transmitted code while being received and/or store the code in the storage device 709, or other non-volatile storage for later execution. In this manner, the computing system 700 may obtain application code in the form of a carrier wave.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to the processor 703 for execution. Such a medium may take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as the storage device 709. Volatile media include dynamic memory, such as main memory 705. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 701. Transmission media can also take the form of acoustic, optical, or electromagnetic waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, CDRW, DVD, any other optical medium, punch cards, paper tape, optical mark sheets, any other physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave, or any other medium from which a computer can read.
Various forms of computer-readable media may be involved in providing instructions to a processor for execution. For example, the instructions for carrying out at least part of the invention may initially be borne on a magnetic disk of a remote computer. In such a scenario, the remote computer loads the instructions into main memory and sends the instructions over a telephone line using a modem. A modem of a local system receives the data on the telephone line and uses an infrared transmitter to convert the data to an infrared signal and transmit the infrared signal to a portable computing device, such as a personal digital assistant (PDA) or a laptop. An infrared detector on the portable computing device receives the information and instructions borne by the infrared signal and places the data on a bus. The bus conveys the data to main memory, from which a processor retrieves and executes the instructions. The instructions received by main memory can optionally be stored on storage device either before or after execution by processor.
While the invention has been described in connection with a number of embodiments and implementations, the invention is not so limited but covers various obvious modifications and equivalent arrangements, which fall within the purview of the appended claims. Although features of the invention are expressed in certain combinations among the claims, it is contemplated that these features can be arranged in any combination and order.
This application claims the benefit of the earlier filing date under 35 U.S.C. §119(e) of U.S. Provisional Application Ser. No. 60/944,595 filed Jun. 18, 2007, entitled “Method and Apparatus For Providing Distributed Scheduling,” the entirety of which is incorporated herein by reference.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IB2008/001573 | 6/17/2008 | WO | 00 | 5/6/2010 |
| Number | Date | Country | |
|---|---|---|---|
| 60944595 | Jun 2007 | US |
