Patent Description:
Satellite links, especially those utilizing Ka-band, can degrade due to adverse weather conditions. Since bad weather conditions are typically not persistent, however, the satellite backhaul network cannot be sized based on the worst link conditions because most of the time satellite capacity would be underutilized. In order to utilize maximum capacity over the satellite link the available bandwidth is calculated based on the least robust modulation/coding resulting in higher throughput under clear sky conditions.

Satellite backhaul networks support two main types of bandwidth quality of service (QoS), namely guaranteed bandwidth and best effort bandwidth. Best effort bandwidth is shared by multiple terminals and used for best effort types of applications, such as file transfer, backup, etc. Guaranteed bandwidth, however, is dedicated and normally used by real time applications or applications that require stringent latency and jitter factors. If the guaranteed bandwidth is oversubscribed, then congestion conditions can appear.

At the time of congestion, TCP based applications using end to end TCP flow control mechanism, along with performance enhancing proxy (PEP) flow control schemes within the satellite network, can adjust the rates to combat the congestion condition. However, non-TCP applications, notably voice and video applications will suffer. In the absence of admission control for non-TCP <NUM>/LTE conversational applications inside the satellite network, new calls will be blindly admitted. Such a condition can cause packets from all calls to be randomly dropped, thus affecting every session. Further, if sufficient bandwidth is not available due to link degradation, calls will be randomly affected. Based on the foregoing, there is a need for a mechanism of admission control of mobile conversational user sessions by a satellite network.

According to <CIT>, in the event an entity receives a message including an unknown quality of service parameter (e.g., class identifier) for a bearer, the entity may select a quality of service parameter for the bearer from a set of known quality of service parameters. Here, a guaranteed bit rate quality of service parameter may be selected from the set upon determining that the unknown quality of service parameter is associated with a guaranteed bit rate bearer. Conversely, a non-guaranteed bit rate quality of service parameter may be selected from the set upon determining that the unknown quality of service parameter is not associated with a guaranteed bit rate bearer.

<CIT> discloses a control technique in which a node of a multi-radio access technology (RAT) system acquires resource status information associated with each RAT of the multi-RAT system. The resource status information of the RATs of the multi-RAT system can be acquired by sniffing higher layer protocol information pertaining to call setup requests and/or call terminated messages. The node further maintains a flag representing overall resource availability associated with the RATs of the multi-RAT system, based on the acquired resource status information, for use in admission control and/or load balancing. The flag is associated with a predefined set of overall resource availability states of the multi-RAT system, where the availability states are defined in terms of admission control decisions. The availability states comprise at least one of the following admission control decisions: i) unconditional acceptance of all services; ii) conditional acceptance of broadband guaranteed bit rate (GBR) services and unconditional acceptance of all other services; iii) conditional acceptance of broadband GBR services, conditional acceptance of narrowband GBR services, and unconditional acceptance of other services; or iv) unconditional rejection of all services.

Various exemplary embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which:.

A method and system for admission control of mobile conversational user sessions by a satellite network is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosed embodiments. It will become apparent, however, to one skilled in the art that various embodiments 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 various embodiments.

<FIG> is a diagram of a system capable of performing admission control of <NUM>/LTE sessions, according to one embodiment. The system <NUM> includes a satellite <NUM> capable of transmitting and receiving signals from various terrestrial-based communications systems. The system <NUM> also includes a gateway <NUM>, and a plurality of remote terminals <NUM> (only one shown). The system <NUM> facilitates admission and transport of sessions from external networks that can include an evolved packet core (EPC) <NUM> and multiple Evolved Node B (eNodeB) stations 160a, 160b. According to at least one embodiment, the external network can be a mobile <NUM>/LTE network. According to further embodiments, the external network can be other types of mobile networks utilizing data packets for transmission of voice and/or data sessions. As further illustrated in <FIG>, the EPC <NUM> can communicate with various public/private networks <NUM> such as the internet, public data networks (PDN), public land mobile networks (PLMN), IP media subsystems (IMS), public switched telephone networks (PSTN), etc. Additionally, the eNodeB is capable of communicating directly with user equipment such as mobile handsets.

The gateway <NUM> can include various components to facilitate communication with the satellite <NUM> and EPC <NUM>, as well as admission of conversational user sessions from the external network over the satellite network. According to at least one embodiment, the gateway <NUM> can include a radio frequency (RF) transceiver <NUM>, a processing unit <NUM> (or computer, CPU, etc.), and a data storage unit <NUM>. The data storage unit <NUM> can be used to store and provide various access to information pertaining, in part, to operations in the satellite network. According to other embodiments, the gateway <NUM> can include multiple processing units <NUM> and multiple data storage units <NUM> in order to accommodate the needs of a particular system implementation. The gateway <NUM> can also include one or more workstations <NUM> (e.g., computers, laptops, etc.) in place of, or in addition to, the one or more processing units <NUM>.

As illustrated in <FIG>, the gateway <NUM> includes an admission control unit <NUM> which monitors the bandwidth, or bit rate, allocated to each external terminal <NUM> (or simply terminal) by the satellite network in order to meet a desired and/or required quality of service. For example, the admission control unit <NUM> can determine and maintain the total guaranteed bit rate (GBR) allocated to each terminal <NUM>, as well as the portion of the allocated guaranteed bit rate (GBR) that remains available. The available GBR can be used to accommodate new sessions that are admitted to the satellite network. The admission control unit <NUM> can also access the maximum bit rate available within the satellite network to be used as a pooled resource for all terminals <NUM>. Some, or all, of this the information pertaining to bit rates can be periodically and/or selectively supplied to each terminal <NUM> within the satellite network. According to various implementations, the processing unit <NUM> and/or workstation <NUM> are capable of executing program instructions such that they become configured to perform various functions associated with operation of the gateway <NUM>. The evolved packet core (EPC) <NUM> can include a mobility management entity (MME) <NUM>, a serving gateway (S-GW) <NUM>, a packet data gateway (PGW) <NUM>, and a policy and charging rules (PCRF) unit148. Although not illustrated in <FIG>, the EPC <NUM> can also include computers and/or processing units that are capable of executing program instructions such that they become configured to perform various functions associated with the operation thereof.

According to at least one embodiment, the mobility management entity (MME) <NUM> can be configured to perform various paging and tagging activities for user equipment capable of accessing the system <NUM>. The MME <NUM> can also perform functions associated with bearer activation and deactivation. Depending on the specific configuration of the EPC <NUM>, the MME <NUM> can also manage security keys and lawful interception of transmissions over the satellite network. The S-GW <NUM> can be configured to route data packets received from public/private networks <NUM> to the terminal <NUM> and vice versa, when sessions are admitted over the satellite network. According to at least one embodiment, the S-GW <NUM> can be configured to manage and store user equipment contexts, such as internal routing information, bearer identification information (e.g., S1AP ID, E-RAB ID), etc. The S-GW <NUM> can also be configured to replicate specific user traffic in order to implement lawful intercepts.

The PGW <NUM> can be configured to provide connectivity to data packets being transmitted over the satellite network to/from the public/private networks <NUM>. For example, the PGW <NUM> can provide policy enforcement, filter and/or screen packets transmitted over the satellite network, etc. The PCRF unit <NUM> performs real-time operations associated with policy determination and enforcement, particularly with regards to multimedia communications. The PCRF unit <NUM> can also access subscriber information for the external network as well as information associated with the service available to the public/private networks <NUM> from the satellite network.

The system <NUM> also includes multiple terminals <NUM> (only one shown) that are part of the satellite network. Such terminals <NUM> can be configured, for example, as very small aperture terminals (VSAT) that are capable of transmitting/receiving information to/from the satellite <NUM>. As such, the terminal <NUM> includes hardware such as computing units, modulator/demodulator, physical interfaces (e.g., network interface controller), RF transceiver, etc. that facilitate connection to an eNodeB 160a, 160b, which is an entity/hardware component of a mobile network and provides direct communication with mobile user equipment (e.g., handsets, tablets, modems, etc.). According to the illustrated embodiment, an S1 interface is used to facilitate communication between the eNodeB 160a, 160b and the EPC <NUM>. Accordingly, standard S1 interface protocols can be used. As further illustrated in <FIG>, multiple eNodeB 160a, 160b can be supported by a single terminal <NUM>. The eNodeB 160a, 160b utilizes an X2 interface to facilitate communication and handovers of user devices (or user equipment) to maintain and/or complete sessions.

According to at least one embodiment, the terminal <NUM> can also include an admission control unit <NUM> which monitors the bandwidth, or bit rate, allocated to the terminal <NUM> by the satellite network in order to meet a desired and/or required quality of service. For example, the admission control unit <NUM> can maintain the total guaranteed bit rate (GBR) allocated to the terminal <NUM>, as well as the portion of the allocated guaranteed bit rate (GBR) that remains available. The available GBR can be used to accommodate new sessions that are admitted to the satellite network. The admission control unit <NUM> can also access the maximum bit rate available within the satellite network to be used as a pooled resource for all terminals.

According to various embodiments, the gateway <NUM> can also include the admission control unit <NUM> in addition to, or in place of, the admission control unit <NUM> located within the terminal <NUM>. When the gateway <NUM> contains the only admission control unit <NUM> in the satellite network, information pertaining to GBR, available bit rate, and maximum bit rate for all terminals <NUM> is determined and maintained at the gateway <NUM>. This information can be stored and maintained, for example, in the storage unit <NUM>. Some, or all, of the information pertaining to bit rates can be periodically and/or selectively supplied to each terminal <NUM> within the satellite network. When the terminal <NUM> also includes admission control unit <NUM>, bit rate information can be redundantly maintained at both the gateway <NUM> and the terminal <NUM>. According to various embodiments, however, the terminal's admission control unit <NUM> may only monitor the GBR allocated to the terminal <NUM> and available bit rate. Information related to the maximum bit rate for the entire satellite network can be maintained by the admission control unit <NUM> located at the gateway <NUM>, and periodically transmitted to each terminal <NUM>.

According to an embodiment, the terminal <NUM> can keep track of the context for each session. The context stores the guaranteed bit rate requirement of the session. Since the guaranteed bit rate is reserved by the satellite network once the session is successfully admitted, new sessions cannot take away this bandwidth. If weather conditions degrade and the terminal <NUM> is required to use a lower or more robust forward error correction (FEC) rate, modulation, and/or symbol rate, the available bandwidth for the terminal <NUM> will be reduced as more MHz spectrum is needed. The terminal <NUM> can re-request bandwidth reservation from the satellite network with the new link conditions. If more MHz spectrum is available, the reservation will be successful. According to at least one embodiment, if the reservation is not successful, the terminal <NUM> can periodically drop packets equally from all existing sessions so that all calls are equally affected. According to another embodiment, the terminal <NUM> can drop all packets from low priority sessions to accommodate other sessions with the originally requested GBR. According to still further embodiments, the terminal <NUM> can drop all packets from low priority sessions and periodically drop packets equally from higher priority sessions.

<FIG> is a flowchart of a process for performing admission control, according to one embodiment. At <NUM>, a radio access bearer (RAB) setup request is received by the gateway. According to at least one embodiment, the radio access bearer setup request can be received from the eNodeB. According to other embodiments, however, the radio access bearer setup request can be received from the EPC. Furthermore, the packet data gateway can be configured as the entity which facilitates transmission of the request, and therefore, would include the necessary hardware to interface with the public/private networks as well as the gateway. At <NUM>, the request is transmitted to the terminal. According to at least one embodiment, this can be accomplished by utilizing the RF transceiver to transmit the request, via the satellite, to the terminal.

At <NUM>, it is determined whether a requested guaranteed bit rate (GBR) for the session is available at the terminal. According to at least one embodiment, this can be accomplished based on information stored and maintained at the admission control unit located within the terminal. According to other embodiments, however, the determination can be made using the admission control unit located at the gateway. If the requested guaranteed bit rate is not available, control passes to <NUM> where the session is denied. More particularly, the session would not be admitted for transmission over the satellite network. According to an embodiment, the satellite network can drop subsequent bearer setup signaling messages so that the new bearer does not get established in the mobile network. Accordingly, it would be necessary to obtain a different network (e.g., terrestrial, wireless, etc.) to carry the session. Once the session is denied, the process ends at <NUM>.

According to at least one embodiment, if the requested guaranteed bit rate is not available, the session can be admitted, but using best effort delivery completion. This is illustrated at <NUM>. As previously discussed, best effort QoS utilizes bandwidth that is shared by multiple, or all, terminals in the network. The bit rate utilized for the session, therefore, would vary based on overall usage of the bandwidth by other terminals in the satellite network, as well as other best effort sessions supported by the terminal. According to one or more embodiments, the external network can be subsequently notified, at <NUM>, that the session has been admitted, but not with the requested guaranteed bit rate. According to other embodiments, however, step <NUM> is omitted and a notification is not sent. In such circumstances, the external network can monitor the session to determine if the required guaranteed bit rate and QoS are satisfied. If the session performance degrades below levels set by the external network, the session may be dropped. The process would then end at <NUM>. Depending on the specific priority level assigned to the session by the external network, it is possible that the session may be immediately dropped due to the lack of available guaranteed bit rate from the terminal.

If it is determined that the requested guaranteed bit rate is available, the request is forwarded to the eNodeB associated with (i.e., serviced by) the particular terminal at <NUM> in order to complete any necessary handshaking/negotiation required to establish end to end completion of the session. At <NUM>, the session is admitted within the satellite network using the requested guaranteed bit rate. More particularly, the initial context setup signaling is allowed to be completed by the satellite network. The satellite network can further save the context of the session (e.g., TEID pairs of the bearer, QCI of the bearer, GBR of the bearer, etc.), and mark the session admitted. Accordingly, all traffic associated with the session would be transmitted from the EPC to the eNodeB, and vice versa) via the satellite network. The process then ends at <NUM>.

<FIG> is a flowchart of a process for performing admission control, according to another embodiment. At <NUM>, a radio access bearer setup request is received. As previously discussed, the request can include, in part, information which uniquely identifies the user equipment being used for the session, and can be received by the gateway. As previously discussed, the request can be transmitted from the EPC. As will be discussed in greater detail below, it is also possible to receive a request from the eNodeB. At <NUM>, the contents of the request are examined. According to at least one embodiment, the gateway can snoop the request in order to obtain various information. For example, the gateway can obtain the user equipment S1AP ID and/or ERAB ID for the session and store such information at <NUM>. At <NUM>, the request is transmitted to the terminal using the satellite network.

At <NUM>, the terminal examines the message in order to determine whether the QoS class identifier (QCI) specifies a guaranteed bit rate resource type. According to various embodiments, QoS class identifiers having a value of <NUM>-<NUM>, <NUM>, or <NUM> require guaranteed bit rates. If the QoS class identifier does not require a guaranteed bit rate, the session is admitted as best effort delivery completion at <NUM>. The process would then end at <NUM>. Although not illustrated in <FIG>, the terminal would forward the request to the eNodeB in order to perform all necessary protocol negotiation/handshaking required to establish end-to-end connectivity between the eNodeB and EPC.

If the resource type requests a guaranteed bit rate, the terminal further checks to determine whether or not the guaranteed bit rate being requested for the session remains available. According to at least one embodiment, the admission control unit collocated with the terminal can determine whether or not the requested amount of guaranteed bit rate remains available from the terminal's total amount of allocated guaranteed bit rate. According to other embodiments, the availability of the requested guaranteed bit rate can be determined by the admission control unit located at the gateway. For example, the terminal can transmit a message indicating the amount of requested guaranteed bit rate, and the gateway can respond with an indication as to whether or not the requested guaranteed bit rate is available. The gateway response can also include information indicative of the terminal's current available guaranteed bit rate.

If the requested guaranteed bit rate is not available, then control passes to the <NUM> where the session is denied admission to the satellite network. According to various embodiments, the session can be admitted, for example, as best effort but only to complete the initial protocol negotiations and/or handshaking. This is illustrated at <NUM>. At <NUM>, the terminal or gateway can monitor transmissions from the external network. The gateway would allow the signaling messages to complete and for the bearer to setup. However, the particular session is marked as not admitted in the satellite network. All subsequent packets for user traffic received on the non-admitted session would be dropped. Thus, from an end-to-end perspective, it appears as though a call was successfully setup, but unable to be completed. This differs, for example, from the situation where the session is simply denied (e.g., at <NUM>), which appears as though the call cannot be setup at all. If the requested guaranteed bit rate is available, control passes to <NUM>. The request is forwarded to the eNodeB serviced by the terminal, and all necessary handshaking is completed. At <NUM>, the session is admitted with the requested guaranteed bit rate. The process then ends at <NUM>.

According to an alternative embodiment, the terminal can release the setup request to the eNodeB, and mark the context "not-admitted. " The terminal can further convey the same information to the gateway. Thus, both the terminal and gateway would drop all traffic corresponding to this session by not sending them over the air (i.e., via the satellite) to each other, thereby saving satellite bandwidth. If the session still exists (i.e., not torn down by the mobile network), the terminal retries the bandwidth reservation procedure based on predetermined triggers such as: the use of higher symbol rates, less robust FEC rate or modulation rate, reclaimed bandwidth from other terminals, etc..

<FIG> is a flowchart of a process for admitting sessions when bandwidth cannot be guaranteed, according to various embodiments. The process begins at <NUM>, after it has already been determined that the requested guaranteed bit rate is not available. At <NUM>, it is determined whether the amount of guaranteed bit rate currently available from the terminal is greater than or equal to one half of the requested guaranteed bit rate. For example, the terminal may be capable of providing <NUM>% of the requested guaranteed bit rate. If the available guaranteed bit rate from the terminal is not greater than or equal to one half of the requested guaranteed bit rate, control passes to <NUM> where the session is denied. The process would subsequently end.

According to the illustrated embodiment, if the terminal's available guaranteed bit rate is greater than one half of the requested guaranteed bit rate, then the session is admitted using a quasi-guaranteed bit rate. This is illustrated at <NUM>. In order to implement the quasi-guaranteed bit rate, the terminal allocates a portion of the requested guaranteed bit rate using its remaining available guaranteed bit rate at <NUM>. For example, if the terminal only has <NUM>% of the requested guaranteed bit rate available, then it allocates the entire amount to the session. The remaining <NUM>% of the requested guaranteed bit rate cannot be provided (or fulfilled) by the terminal. At <NUM>, the terminal allocates the remainder of the requested guaranteed bit rate to best effort delivery completion. Thus, a portion (<NUM>%) of the requested guaranteed bit rate for the session would be carried using the pooled maximum bit rate available to all terminals in the satellite network.

At <NUM>, the external network is notified of the session status. More particularly, the network would be notified that the entire amount of requested guaranteed bit rate was not available. However, <NUM>% was available. Thus, the session was admitted as quasi-guaranteed bit rate session. Depending on the specific requirements for the session (e.g., latency and jitter tolerance), the external network may cancel the session and obtain a different backhaul network. Alternatively, if the latency requirements can be satisfied using the terminal's guaranteed bit rate for <NUM>% of the requested guaranteed bit rate, the external network may allow the session to proceed. The external network can also monitor the session in order to determine whether the required QoS is satisfied. If the session quality degrades to a level that prevents satisfaction of the required QoS, the external network can cancel the session. The process would optionally end.

According to one or more embodiments, it is conceivable that a new request can be received to admit a second session over the satellite network, even though the entire amount of the terminal's guaranteed bit rate is currently in use. This is illustrated at <NUM>, where a second request is received to admit a second session. At <NUM>, the contents of the second request are examined in order to determine whether the QoS class identifier requires a guaranteed bit rate, and the amount of guaranteed bit rate being requested. For purposes of explanation and simplicity, the previous intermediate steps performed at the gateway prior to transmission to the terminal have been omitted.

At <NUM>, it is determined whether the terminal's available guaranteed bit rate is greater than or equal to the second requested guaranteed bit rate. According to the illustrated embodiment, the available guaranteed bit rate being examined corresponds to the amount previously allocated to the first session as part of the quasi-guaranteed bit rate. More particularly, this available guaranteed bit rate corresponds to the amount equal to <NUM>% of the first session requested guaranteed bit rate (from <NUM>). If the available guaranteed bit rate from the terminal is not greater than or equal to the second requested guaranteed bit rate, then the second session is denied at <NUM>. Control then passes the <NUM> where the process end. If the terminal's available guaranteed bit rate, however, is greater than or equal to the second requested guaranteed bit rate, control passes to <NUM>. The second session is admitted and allocated the second requested guaranteed bit rate. At <NUM>, the first session is changed from a quasi-guaranteed bit rate session to best effort delivery completion.

Depending on the specific amount of the terminal's available guaranteed bit rate and the second requested guaranteed bit rate, there may be sufficient availability to maintain the first session as a quasi-guaranteed bit rate session. For example, a situation can arise where the second requested guaranteed bit rate is less than <NUM>% of the first session's requested guaranteed bit rate, e.g., <NUM>%. Using the comparison at <NUM>, the terminal would accept the second session with the second requested guaranteed bit rate. Based on the evaluation at <NUM>, however, the terminal would still have more than one half (specifically <NUM>%) of the requested guaranteed bit rate from the first session. Thus, it would still be possible for the terminal to maintain the first session as a quasi-guaranteed bit rate session. The process then ends at <NUM>.

<FIG> is a flowchart of a process for admitting sessions when bandwidth is not available, according to at least one embodiment. The process begins at <NUM>, after it has already been determined that the requested guaranteed bit rate is not available. At <NUM>, the new session is admitted using a temporary guaranteed bit rate. At <NUM>, the terminal determines the priority for all sessions that it currently supports. This includes the new session that was admitted with the temporary guaranteed bit rate. According to at least one embodiment, the priority of the sessions can be based, at least in part, on the QoS class identifier contained in the initial context setup request. At <NUM>, the guaranteed bit rate allocated for each session is reduced, based on priority, in order to meet (or satisfy) the terminal's available guaranteed bit rate.

For example, if all the sessions supported by the terminal currently occupy <NUM>% of the terminal's allocated guaranteed bit rate, then the terminal only has <NUM>% remaining for new session. According to an exemplary condition, the new session now requires an additional <NUM>% guaranteed bit rate from the terminal. Thus, the total guaranteed bit rate being requested is <NUM>% of the terminal's maximum allocation. Accordingly, the terminal would reduce the guaranteed bit rate for each session until the total allocation is reduced to <NUM>% (or less). The process would then end at <NUM>. The terminal would now be capable of carrying all of the sessions using a (reduced) guaranteed bit rate criteria. According to at least one embodiment, it is also possible for the terminal to equally reduce the guaranteed bit rate allocated for all sessions in order to meet the total available guaranteed bit rate requirements, without consideration for the QoS class identifier. This is illustrated at <NUM>. According to the embodiment illustrated in <FIG>, all active sessions would be affected by the reduction in guaranteed bit rate. Packets could be randomly dropped from all sessions in order to provide a substantially equal reduction in quality.

<FIG> is a ladder diagram illustrating successful admission of a session, according to one or more embodiments. At <NUM>, the radio access bearer (RAB) setup request is transmitted from the eNodeB to the VSAT (or terminal) which serves the eNodeB. At <NUM>, the terminal snoops the request in order to obtain information such as the QoS class identifier. At <NUM>, the terminal determines if the QoS class identifier requires guaranteed bit rate service. If guaranteed bit rate is not required, then the terminal passes the initial context setup request to the gateway at <NUM>. If it is determined that a guaranteed bit rate service is required, the terminal transmits a request for the guaranteed bit rate to the admission control unit at <NUM>. As previously discussed, the admission control unit can be located at the terminal, the gateway, or both. At <NUM>, the admission control unit responds with a message indicating that the requested guaranteed bit rate has been granted. At <NUM>, the RAB setup request is transmitted to the gateway.

The gateway snoops the request at <NUM>, and stores the user equipment S1AP ID and/or ERAB ID at <NUM>. At <NUM>, the RAB setup request is transmitted from the gateway to the EPC. At <NUM>, the EPC transmits a RAB setup response back to the gateway. Depending on the particular session, the response can include information specific to internet protocol (IP) and/or stream control transmission protocol (SCTP). At <NUM>, the gateway again snoops the response and attempts to match the values for the user equipment S1AP ID and/or ERAB ID contained in the response with those previously saved. If a match is found, then a pairing and GPRS tunneling protocol (GTP) context is created at <NUM>. At <NUM>, the RAB setup response is forwarded from the gateway to the terminal. At <NUM>, the terminal transmits the RAB response to the eNodeB. At <NUM>, the gateway transmits a request to the terminal to setup a corresponding tunnel context for the session. At <NUM>, the terminal creates the GTP tunnel context. The terminal subsequently transmits an acknowledgment back to the gateway at <NUM>. The acknowledgement can be used, for example, to indicate that the tunnel has been successfully established. All packets associated with the session would now be carried, over the satellite network, from the eNodeB to the EPC and vice versa using the requested GBR or best effort delivery.

<FIG> is a ladder diagram illustrating denial of a session, according to one embodiment. At <NUM>, the radio access bearer (RAB) setup request is transmitted from the eNodeB to the terminal. At <NUM>, the terminal snoops the request in order to obtain information such as the QoS class identifier. At <NUM>, the terminal determines if the QoS class identifier requires guaranteed bit rate service. If guaranteed bit rate is not required, then the terminal admits the session using best effort delivery completion at <NUM>. The RAB setup request is completed with no guaranteed bit rate at <NUM>. For purposes of illustrating the details of session denial, the specific steps performed to complete the RAB setup request are not shown in <FIG>. Such steps, however, correspond to those illustrated in <FIG> and beginning at <NUM> after it has been determined that guaranteed bit rate is not required.

If the QoS class identifier requires guaranteed bit rate, however, then the terminal transmits a request to the appropriate admission control unit for the requested guaranteed bit rate at <NUM>. As previously discussed, the embodiment illustrated in <FIG> shows a situation where the requested guaranteed bit rate is not available from the terminal. Accordingly, the admission control unit denies the request for guaranteed bit rate at <NUM>. At <NUM>, transmission of the RAB setup request to the gateway is not completed (i.e., not performed) by the terminal.

According to at least one embodiment, after a predetermined amount of time has expired, the external network (e.g., mobile network) may retransmit the RAB setup request. Under such conditions, the eNodeB forwards this request to the terminal at <NUM>. Alternatively, the eNodeB may independently initiate the retransmission and forward the request to the terminal at <NUM>. Since the requested guaranteed bit rate is not available from the terminal, no RAB setup request is forwarded to the gateway. This is illustrated at <NUM>.

According to one or more embodiments, the terminal may again check with the admission control unit to see if any of the previously active sessions have ended in order to reassess the available guaranteed bit rate. Control would therefore return to <NUM>, where a request for GBR is transmitted to the admission control unit. This is illustrated at <NUM>. Thus, if the requested guaranteed bit rate becomes available, the terminal would now admit the session. However, the session would again be denied if the requested guaranteed bit rate remains unavailable. Alternatively, it may be possible to admit the new session as a quasi-guaranteed bit rate session based on the previously discussed embodiments. The session may also be admitted by reducing the guaranteed bit rate allocated to all active sessions, as discussed with respect to previous embodiments.

Although the foregoing embodiments have illustrated and described exchange of initial context setup request/response for a default bearer, it should be noted that a dedicated bearer can be setup in a similar manner. More particularly, the dedicated bearer can be setup by exchanging E-RAB setup request/response between the eNodeB and EPC in a manner similar to those previously described.

The processes described herein 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. The terms software, computer software computer program, program code, and application program may be used interchangeably and are generally intended to include any sequence of machine or human recognizable instructions intended to program/configure a computer, processor, server, etc. to perform one or more functions. Such software can be rendered in any appropriate programming language or environment including, without limitation: C, C++, C#, Python, R, Fortran, COBOL, assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), Java, JavaScript, etc..

As used herein, the terms processor, microprocessor, digital processor, and CPU are meant generally to include all types of processing devices including, without limitation, single/multi-core microprocessors, digital signal processors (DSPs), reduced instruction set computers (RISC), general-purpose (CISC) processors, gate arrays (e.g., FPGAs), PLDs, reconfigurable compute fabrics (RCFs), array processors, secure microprocessors, and application-specific integrated circuits (ASICs). Such digital processors may be contained on a single unitary IC die, or distributed across multiple components. Such exemplary hardware for performing the described functions is detailed below.

<FIG> is a diagram of a computer system that can be used to implement various embodiments. The computer system <NUM> includes a bus <NUM> or other communication mechanism for communicating information and a processor <NUM> coupled to the bus <NUM> for processing information. The computer system <NUM> also includes main memory <NUM>, such as a random access memory (RAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random-access memory (DDR SDRAM), DDR2 SDRAM, DDR3 SDRAM, DDR4 SDRAM, etc., or other dynamic storage device (e.g., flash RAM), coupled to the bus <NUM> for storing information and instructions to be executed by the processor <NUM>. Main memory <NUM> can also be used for storing temporary variables or other intermediate information during execution of instructions by the processor <NUM>. The computer system <NUM> may further include a read only memory (ROM) <NUM> or other static storage device coupled to the bus <NUM> for storing static information and instructions for the processor <NUM>. A storage device <NUM>, such as a magnetic disk or optical disk, is coupled to the bus <NUM> for persistently storing information and instructions.

The computer system <NUM> may be coupled via the bus <NUM> to a display <NUM>, such as a light emitting diode (LED) or other flat panel displays, for displaying information to a computer user. An input device <NUM>, such as a keyboard including alphanumeric and other keys, is coupled to the bus <NUM> for communicating information and command selections to the processor <NUM>. Another type of user input device is a cursor control <NUM>, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor <NUM> and for controlling cursor movement on the display <NUM>. Additionally, the display <NUM> can be touch enabled (i.e., capacitive or resistive) in order facilitate user input via touch or gestures.

According to an exemplary embodiment, the processes described herein are performed by the computer system <NUM>, in response to the processor <NUM> executing an arrangement of instructions contained in main memory <NUM>. Execution of the arrangement of instructions contained in main memory <NUM> causes the processor <NUM> 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 <NUM>. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement exemplary embodiments. Thus, exemplary embodiments are not limited to any specific combination of hardware circuitry and software.

The computer system <NUM> also includes a communication interface <NUM> coupled to bus <NUM>. The communication interface <NUM> provides a two-way data communication coupling to a network link <NUM> connected to a local network <NUM>. For example, the communication interface <NUM> may be a digital subscriber line (DSL) card or modem, an integrated services digital network (ISDN) card, a cable modem, fiber optic service (FiOS) line, or any other communication interface to provide a data communication connection to a corresponding type of communication line. As another example, communication interface <NUM> may be a local area network (LAN) card (e.g. for Ethernet™ or an Asynchronous Transfer Mode (ATM) network) to provide a data communication connection to a compatible LAN. Wireless links can also be implemented. In any such implementation, communication interface <NUM> sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. Further, the communication interface <NUM> can include peripheral interface devices, such as a Universal Serial Bus (USB) interface, a High Definition Multimedia Interface (HDMI), etc. Although a single communication interface <NUM> is depicted in <FIG>, multiple communication interfaces can also be employed.

The network link <NUM> typically provides data communication through one or more networks to other data devices. For example, the network link <NUM> may provide a connection through local network <NUM> to a host computer <NUM>, which has connectivity to a network <NUM> such as a wide area network (WAN) or the Internet. The local network <NUM> and the network <NUM> both use electrical, electromagnetic, or optical signals to convey information and instructions. The signals through the various networks and the signals on the network link <NUM> and through the communication interface <NUM>, which communicate digital data with the computer system <NUM>, are exemplary forms of carrier waves bearing the information and instructions.

The computer system <NUM> can send messages and receive data, including program code, through the network(s), the network link <NUM>, and the communication interface <NUM>. In the Internet example, a server (not shown) might transmit requested code belonging to an application program for implementing an exemplary embodiment through the network <NUM>, the local network <NUM> and the communication interface <NUM>. The processor <NUM> may execute the transmitted code while being received and/or store the code in the storage device <NUM>, or other non-volatile storage for later execution. In this manner, the computer system <NUM> 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 <NUM> 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 <NUM>. Non-volatile media can further include flash drives, USB drives, microSD cards, etc. Volatile media include dynamic memory, such as main memory <NUM>. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise the bus <NUM>. 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 USB drive, microSD card, hard disk drive, solid state drive, optical disk (e.g., DVD, DVD RW, Blu-ray), or any other medium from which a computer can read.

<FIG> illustrates a chip set <NUM> upon which an embodiment of the invention may be implemented. Chip set <NUM> is programmed to implement various features as described herein and includes, for instance, the processor and memory components described with respect to <FIG> incorporated in one or more physical packages (e.g., chips). By way of example, a physical package includes an arrangement of one or more materials, components, and/or wires on a structural assembly (e.g., a baseboard) to provide one or more characteristics such as physical strength, conservation of size, and/or limitation of electrical interaction. It is contemplated that in certain embodiments the chip set can be implemented in a single chip. Chip set <NUM>, or a portion thereof, constitutes a means for performing one or more steps of the figures.

Claim 1:
A method comprising:
receiving a radio access bearer setup request, at a remote terminal of a satellite network, to admit a new session from an external network over the satellite network; determining whether a requested guaranteed bit rate for the new session is available from the remote terminal; and
when the requested guaranteed bit rate is available:
forwarding the request to a gateway of the satellite network, and
admitting the new session, over the satellite network, to the external network using the requested guaranteed bit rate;the method being characterized in that
when the requested guaranteed bit rate is not available:
determining (<NUM>) whether the available guaranteed bit rate from the remote terminal is greater than or equal to <NUM>% of the requested guaranteed bit rate; and
when the available guaranteed bit rate from the remote terminal is greater than or equal to <NUM>% of the requested guaranteed bit rate:
admitting (<NUM>) the new session using a quasi-guaranteed bit rate; and
notifying the external network of the new session status,
wherein the quasi-guaranteed bit rate is defined as a bit rate including:
a portion of the requested guaranteed bit rate allocated (<NUM>) from the remote terminal's guaranteed bit rate, and
a remainder of the requested guaranteed bit rate allocated (<NUM>) from the remote terminal's maximum available bit rate using best effort delivery completion.