TECHNIQUES FOR USER PLANE CONGESTION MITIGATION
Various embodiments are generally directed to improved techniques for UPCON mitigation. In one embodiment, for example, an evolved node B (eNB) may comprise a processor circuit, a detection component for execution by the processor circuit to detect user plane congestion between an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN) and a serving gateway (S-GW) of an evolved packet core (EPC), and a configuration component for execution by the processor circuit to select a set of user equipment (UEs) served by the E-UTRAN and the S-GW and send a request to utilize an alternate S-GW of the EPC to serve the set of UEs while maintaining a current packet data network (PDN) gateway (P-GW) for the set of UEs. Other embodiments are described and claimed.
Latest Intel Patents:
- PROTECTION OF COMMUNICATIONS BETWEEN TRUSTED EXECUTION ENVIRONMENT AND HARDWARE ACCELERATOR UTILIZING ENHANCED END-TO-END ENCRYPTION AND INTER-CONTEXT SECURITY
- MOISTURE HERMETIC GUARD RING FOR SEMICONDUCTOR ON INSULATOR DEVICES
- OPTIMIZING THE COEXISTENCE OF OPPORTUNISTIC WIRELESS ENCRYPTION AND OPEN MODE IN WIRELESS NETWORKS
- MAGNETOELECTRIC LOGIC WITH MAGNETIC TUNNEL JUNCTIONS
- SALIENCY MAPS AND CONCEPT FORMATION INTENSITY FOR DIFFUSION MODELS
This application is a continuation of, claims the benefit of and priority to previously filed U. S. patent application Ser. No. 14/129,952 filed Dec. 28, 2013, which is a national stage application of PCT/US2013/068491 filed Nov. 5, 2013, which claims priority to U. S. Provisional Patent Application No. 61/752,386, filed Jan. 14, 2013; all of the above are hereby incorporated by reference in their entirety.
TECHNICAL FIELDEmbodiments herein generally relate to wireless mobile broadband communications.
BACKGROUNDIn various wireless communications systems, mobile devices in various cells of a radio access network may obtain data service from a packet core via a radio-to-packet interface between the radio access network and the packet core. User plane congestion (UPCON) may occur if the total amount of data traffic of the mobile devices in the various cells approaches, reaches, and/or exceeds a capacity of the radio-to-packet interface. One approach for UPCON mitigation may involve reallocating data traffic of one or more mobile devices to an alternate radio-to-packet interface. However, conventional techniques for performing such reallocation may involve unnecessarily modifying more than one waypoint in the data path, rather than modifying a single waypoint. For example, a conventional UPCON mitigation technique may involve selecting both an alternate serving gateway and an alternate packet gateway for handling reallocated data traffic, rather than simply selecting an alternate serving gateway while maintaining a current packet gateway for the reallocated data traffic.
Various embodiments are generally directed to improved techniques for UPCON mitigation. According to such improved techniques, UPCON mitigation may be performed without unnecessarily modifying more than one waypoint in a data path between one or more affected mobile devices and a core network. In one embodiment, for example, an evolved node B (eNB) may comprise a processor circuit, a detection component for execution by the processor circuit to detect user plane congestion between an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN) and a serving gateway (S-GW) of an evolved packet core (EPC), and a configuration component for execution by the processor circuit to select a set of user equipment (UEs) served by the E-UTRAN and the S-GW and send a request to utilize an alternate S-GW of the EPC to serve the set of UEs while maintaining a current packet data network (PDN) gateway (P-GW) for the set of UEs. Other embodiments are described and claimed.
Various embodiments may comprise one or more elements. An element may comprise any structure arranged to perform certain operations. Each element may be implemented as hardware, software, or any combination thereof, as desired for a given set of design parameters or performance constraints. Although an embodiment may be described with a limited number of elements in a certain topology by way of example, the embodiment may include more or less elements in alternate topologies as desired for a given implementation. It is worthy to note that any reference to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrases “in one embodiment,” “in some embodiments,” and “in various embodiments” in various places in the specification are not necessarily all referring to the same embodiment.
The techniques disclosed herein may involve transmission of data over one or more wireless connections using one or more wireless mobile broadband technologies. For example, various embodiments may involve transmissions over one or more wireless connections according to one or more 3rd Generation Partnership Project (3GPP), 3GPP Long Term Evolution (LTE), and/or 3GPP LTE-Advanced (LTE ADV) technologies and/or standards, including their revisions, progeny and variants. Some embodiments may additionally or alternatively involve transmissions according to one or more Global System for Mobile Communications (GSM)/Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecommunications System (UMTS)/High Speed Packet Access (HSPA), and/or GSM with General Packet Radio Service (GPRS) system (GSM/GPRS) technologies and/or standards, including their revisions, progeny and variants.
Examples of wireless mobile broadband technologies may also include without limitation any of the Institute of Electrical and Electronics Engineers (IEEE) 802.16m and/or 802.16p, International Mobile Telecommunications Advanced (IMT-ADV), Worldwide Interoperability for Microwave Access (WiMAX) and/or WiMAX II, Code Division Multiple Access (CDMA) 2000 (e.g., CDMA2000 1xRTT, CDMA2000 EV-DO, CDMA EV-DV, and so forth), High Performance Radio Metropolitan Area Network (HIPERMAN), Wireless Broadband (WiBro), High Speed Downlink Packet Access (HSDPA), High Speed Orthogonal Frequency-Division Multiplexing (OFDM) Packet Access (HSOPA), High-Speed Uplink Packet Access (HSUPA) technologies and/or standards, including their revisions, progeny and variants. The embodiments are not limited in this context.
In addition to transmission over one or more wireless connections, the techniques disclosed herein may involve transmission of content over one or more wired connections through one or more wired communications media. Examples of wired communications media may include a wire, cable, metal leads, printed circuit board (PCB), backplane, switch fabric, semiconductor material, twisted-pair wire, co-axial cable, fiber optics, and so forth. The embodiments are not limited in this context.
Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments may be practiced without these specific details. In other instances, well known structures and devices are shown in block diagram form in order to facilitate a description thereof. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject matter.
In some embodiments, serving gateway 120 may comprise a network entity operative to route and/or forward user data packets for one or more mobile devices 110 in radio access network 102. In various embodiments, packet gateway 122 may comprise a network entity operative as a point of exit from and entry into an external packet data network for data exchanged between one or more mobile devices 110 in radio access network 102 and the external packet data network. In some embodiments, for example, packet gateway may provide data connectivity to the internet for one or more mobile devices 110 in radio access network 102. In various embodiments, serving gateway 120 and/or packet gateway 122 may comprise network devices and/or nodes of a core network. For example, in some embodiments, serving gateway 120 may comprise a serving gateway (S-GW) of an evolved packet core (EPC) structured according to a system architecture evolution (SAE) architecture, and packet gateway 122 may comprise a packet data network (PDN) gateway (P-GW) of the EPC. The embodiments are not limited to this example.
In various embodiments, base stations 104, 106, and 108 may be operative to communicate with serving gateway 120 via respective connections 112, 114, and 116 of a radio-to-packet interface 118. Radio-to-packet interface 118 may comprise any combination of network communications interfaces, connections, and/or devices operative to enable radio access network 102 to exchange user plane data with serving gateway 120. In some embodiments, for example, radio-to-packet interface 118 may comprise an interface that enables a 3GPP radio access network (RAN) to exchange user plane data with an S-GW of an EPC. In various embodiments, radio-to-packet interface 118 may include one or more intermediate network devices and/or nodes. In some embodiments, some or all of the one or more intermediate network devices and/or nodes may comprise intermediate packet routing devices and/or nodes. In various embodiments, one or more intermediate packet routing devices and/or nodes may enable radio access network 102 to exchange user plane data with serving gateway 120 when radio access network 102 operates according to a different protocol than serving gateway 120. For example, in some embodiments, radio-to-packet interface 118 may include a serving GPRS support node (SGSN) that enables the exchange of user plane data between a UMTS terrestrial radio access network (UTRAN) and an S-GW. The embodiments are not limited in this context.
In various embodiments, radio access network 102 may comprise a 4G radio access network. In an example embodiment, radio access network 102 may comprise an evolved UTRAN (E-UTRAN), base stations 104, 106, and 108 may comprise evolved node Bs (eNBs), serving gateway 120 may comprise an S-GW of an EPC, and connections 112, 114, and 116 may comprise S1-U interface connections between the eNBs and the S-GW. The embodiments are not limited to this example.
In some other embodiments, radio access network 102 may comprise a 3G or 2G radio access network. In various such embodiments, radio-to-packet interface 118 may include one or more intermediate network devices and/or nodes. In some embodiments, the one or more intermediate network devices and/or nodes may include one or more intermediate packet routing devices and/or nodes operative to enable the 3G or 2G radio access network to exchange user plane data with the serving gateway.
In an example embodiment, radio access network 102 may comprise a UTRAN, base stations 104, 106, and 108 may comprise node Bs, serving gateway 120 may comprise an S-GW of an EPC, and radio-to-packet interface 118 may include a radio network controller (RNC) and an SGSN. In this example embodiment, connections 112, 114, and 116 may comprise Iu-B interface connections between the node Bs and the RNC, and the RNC may communicate with the SGSN over an Iu-PS interface connection.
In another example embodiment, radio access network 102 may comprise a GSM/EDGE radio access network (GERAN), base stations 104, 106, and 108 may comprise base transceiver stations (BTSs), and radio-to-packet interface 118 may include a base station controller (BSC) and an SGSN. In this example embodiment, connections 112, 114, and 116 may comprise Abis interface connections between the BTSs and the BSC, and the BSC may communicate with the SGSN over a Gb interface connection. The embodiments are not limited to these examples.
In various embodiments, radio-to-packet interface 118 may have an associated uplink capacity and an associated downlink capacity, which may comprise overall rates at which radio-to-packet interface 118 can convey user plane data between radio access network 102 and serving gateway 120 in the uplink and downlink directions, respectively. In some embodiments, an uplink capacity of radio-to-packet interface 118 may be different than a downlink capacity of radio-to-packet interface 118, while in other embodiments, the uplink and downlink capacities of radio-to-packet interface 118 may be the same. The embodiments are not limited in this context.
In various embodiments, the uplink and/or downlink capacities of radio-to-packet interface 118 may be defined by and/or related to uplink and/or downlink capacities of one or more interfaces for connections to and/or within radio-to-packet interface 118. In an example embodiment, radio access network 102 may comprise an E-UTRAN, connections 112, 114, and 116 may comprise S1-U interface connections, and the uplink and/or downlink capacities of radio-to-packet interface 118 may comprise overall uplink and/or downlink S1-U interface capacities for radio-to-packet interface 118. In another example embodiment, radio access network 102 may comprise a UTRAN, radio-to-packet interface 118 may include an RNC that communicates with an SGSN over an Iu-PS interface connection, and the uplink and/or downlink capacities of radio-to-packet interface 118 may comprise overall uplink and/or downlink Iu-PS interface capacities for radio-to-packet interface 118. In yet another example embodiment, radio access network 102 may comprise a GERAN, radio-to-packet interface 118 may include a BSC that communicates with an SGSN over a Gb interface connection, and the uplink and/or downlink capacities of radio-to-packet interface 118 may comprise overall uplink and/or downlink Gb interface capacities for radio-to-packet interface 118. The embodiments are not limited to these examples.
In some embodiments, when the sums of the uplink and/or downlink user plane data rates of connections 112, 114, and 116 approach, reach, and/or exceed the uplink and/or downlink capacity of radio-to-packet interface 118, user plane congestion may result. For example, if radio-to-packet interface 118 has an uplink capacity of 100 Mbps and base stations 104, 106, and 108 attempt to send user plane data to serving gateway 120 through respective connections 112, 114, and 116 at a collective total rate of 105 Mbps, uplink user plane congestion may occur in radio-to-packet interface 118. The embodiments are not limited to this example.
In order to reduce, eliminate, and/or prevent user plane congestion in radio-to-packet interface 118, user plane congestion (UPCON) mitigation techniques may be employed. According to such UPCON mitigation techniques, an alternate radio-to-packet interface may be used to accommodate some of the uplink and/or downlink user plane traffic for radio access network 102, in order to reduce and/or prevent uplink and/or downlink user plane congestion in radio-to-packet interface 118. In various embodiments, utilizing such an alternate radio-to-packet interface may involve allocating some of the uplink and/or downlink user plane traffic of radio access network 102 for communication via an alternate serving gateway. In some embodiments, utilizing such an alternate radio-to-packet interface may alternatively or additionally involve allocating some of the uplink and/or downlink user plane traffic of radio access network 102 for communication via an alternative to an intermediate device or node within radio-to-packet interface 118. For example, in embodiments in which radio-to-packet interface 118 includes an SGSN, utilizing an alternate radio-to-packet interface may comprise allocating some or all of the uplink and/or downlink user plane traffic of radio access network 102 for communication via an alternate SGSN. The embodiments are not limited to this example.
In various embodiments, the UPCON mitigation techniques may involve modifying one waypoint in a data path between radio access network 102 and packet gateway 122 while maintaining one or more other waypoints in the data path. For example, in some embodiments, some or all of the uplink and/or downlink user plane traffic of radio access network 102 may be allocated to an alternate serving gateway while packet gateway 122 is maintained for handling of that user plane traffic. In various other embodiments, some or all of the uplink and/or downlink user plane traffic of radio access network 102 may be allocated to an alternate SGSN within radio-to-packet interface 118 while serving gateway 120 and packet gateway 122 are maintained for handling of that user plane traffic. One advantage of some embodiments may be that by avoiding unnecessary changes to data path waypoints other than those at which user plane congestion occurs, UPCON mitigation may be performed with reduced signaling overhead. Other advantages may be associated with various embodiments, and the embodiments are not limited in this context.
It is worthy of note that in some embodiments, such UPCON mitigation may involve allocating user plane traffic to an alternate radio-to-packet interface at a mobile device level of granularity. As such, in various embodiments, UPCON mitigation may involve allocating uplink and/or downlink user plane traffic of particular mobile devices 110 in a given cell to an alternate radio-to-packet interface, and continuing to use radio-to-packet interface 118 to handle uplink and/or downlink user plane traffic of other mobile devices 110 in that cell. It is to be understood that in some embodiments, other levels of granularity may additionally or alternatively be employed. In various embodiments, the particular mobile devices 110 may be selected only from among those that are in a connected mode. The embodiments are not limited in this context.
In some embodiments, any particular UPCON mitigation process may be initiated by one of base stations 104, 106, and 108. For example, in various embodiments, an UPCON mitigation process may be initiated by an eNB. In some embodiments, any particular UPCON mitigation process may be initiated by an intermediate network device or node within radio-to-packet interface 118, or another network device or node with which radio access network 102 communicates. For example, in various embodiments, an UPCON mitigation process may be initiated by an RNC, a BSC, an SGSN, or a mobility management entity (MME). In some embodiments, more than one of the aforementioned devices may be capable of initiating an UPCON mitigation process. For example, in various embodiments, each of base stations 104, 106, and 108 may comprise an eNB capable of initiating UPCON mitigation, and radio access network 102 may communicate with an MME that is also capable of initiating UPCON mitigation. The embodiments are not limited to this example.
In some embodiments, apparatus 200 may comprise processor circuit 202. Processor circuit 202 may be implemented using any processor or logic device, such as a complex instruction set computer (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, an x86 instruction set compatible processor, a processor implementing a combination of instruction sets, a multi-core processor such as a dual-core processor or dual-core mobile processor, or any other microprocessor or central processing unit (CPU). Processor circuit 102 may also be implemented as a dedicated processor, such as a controller, a microcontroller, an embedded processor, a chip multiprocessor (CMP), a co-processor, a digital signal processor (DSP), a network processor, a media processor, an input/output (I/O) processor, a media access control (MAC) processor, a radio baseband processor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device (PLD), and so forth. In one embodiment, for example, processor circuit 102 may be implemented as a general purpose processor, such as a processor made by Intel® Corporation, Santa Clara, Calif. The embodiments are not limited in this context.
In various embodiments, apparatus 200 may comprise or be arranged to communicatively couple with a memory unit 204. Memory unit 204 may be implemented using any machine-readable or computer-readable media capable of storing data, including both volatile and non-volatile memory. For example, memory unit 204 may include read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, or any other type of media suitable for storing information. It is worthy of note that some portion or all of memory unit 204 may be included on the same integrated circuit as processor circuit 202, or alternatively some portion or all of memory unit 204 may be disposed on an integrated circuit or other medium, for example a hard disk drive, that is external to the integrated circuit of processor circuit 202. Although memory unit 204 is comprised within apparatus 200 in
In general operation, apparatus 200 and/or system 240 may be operative to monitor a radio-to-packet interface 218 in order to detect downlink and/or uplink user plane congestion therein. Radio-to-packet interface 218 may be the same as or similar to radio-to-packet interface 118 of
In some embodiments, apparatus 200 and/or system 240 may be operative to initiate UPCON mitigation that comprises maintaining a current serving gateway and/or a current packet gateway associated with radio-to-packet interface 218. In an example embodiment, the UPCON mitigation may comprise maintaining a current packet gateway, such that user plane traffic allocated to an alternate serving gateway is still handled by the current packet gateway. In another example embodiment, the UPCON mitigation may comprise maintaining a current serving gateway, such that user plane traffic allocated to an alternate SGSN is still handled by the current serving gateway. The embodiments are not limited to these examples.
In various embodiments, apparatus 200 and/or system 240 may comprise a detection component 206. Detection component 206 may comprise logic, circuitry, and/or instructions operative to monitor radio-to-packet interface 218 in order to detect uplink and/or downlink user plane congestion therein. In some embodiments, detection component 206 may be operative to monitor radio-to-packet interface 218 based on user plane traffic information 210. User plane traffic information 210 may comprise information indicating amounts of uplink and/or downlink user plane traffic allocated for handling by radio-to-packet interface 218 and/or by a network device or node associated therewith. In an example embodiment, apparatus 200 and/or system 240 may comprise an eNB or MME, and user plane traffic information 210 may comprise information indicating amounts of uplink and/or downlink S1-U interface traffic allocated for handling by an S-GW. In another example embodiment, apparatus 200 and/or system 240 may comprise an RNC or an SGSN, and user plane traffic information 210 may comprise information indicating amounts of uplink and/or downlink Iu-PS interface traffic allocated for handling by the SGSN. In yet another example embodiment, apparatus 200 and/or system 240 may comprise a BSC or an SGSN, and user plane traffic information 210 may comprise information indicating amounts of uplink and/or downlink Gb interface traffic allocated for handling by the SGSN. The embodiments are not limited to these examples.
In various embodiments, detection component 206 may be operative to detect uplink and/or downlink user plane congestion in radio-to-packet interface 218 based on user plane traffic information 210 and interface capacity information 212. Interface capacity information 212 may comprise information indicating an uplink capacity and/or a downlink capacity for radio-to-packet interface 218, which may comprise overall rates at which radio-to-packet interface 218 can convey user plane data in the uplink and downlink directions, respectively. In some embodiments, an uplink capacity of radio-to-packet interface 218 may be different than a downlink capacity of radio-to-packet interface 218, while in other embodiments, the uplink and downlink capacities of radio-to-packet interface 218 may be the same. The embodiments are not limited in this context.
In various embodiments, interface capacity information 212 may comprise information indicating uplink and/or downlink capacities of one or more interfaces for connections to and/or within radio-to-packet interface 218. In an example embodiment, radio-to-packet interface 218 may connect an E-UTRAN with an evolved packet core, and interface capacity information 212 may indicate uplink and/or downlink S1-U interface capacities for an S-GW of the evolved packet core. In another example embodiment, radio-to-packet interface 218 may include an SGSN and may connect a UTRAN with an evolved packet core, and interface capacity information 212 may indicate uplink and/or downlink Iu-PS interface capacities for the SGSN. In yet another example embodiment, radio-to-packet interface 218 may include an SGSN and may connect a GERAN with an evolved packet core, and interface capacity information 212 may indicate uplink and/or downlink Gb interface capacities for the SGSN. The embodiments are not limited to these examples.
In some embodiments, detection component 206 may be operative to detect uplink and/or downlink user plane congestion by comparing uplink and/or downlink user plane traffic levels indicated by user plane traffic information 210 with uplink and/or downlink capacities indicated by interface capacity information 212. In various embodiments, detection component 206 may be operative to detect user plane congestion in a particular direction when the user plane traffic level in that direction nears the capacity for that direction. For example, detection component 206 may be operative to detect user plane congestion in a particular direction when the user plane traffic level in that direction reaches a certain percentage of the capacity or increases to a level that is within a particular number of Mbps of the capacity. In some other embodiments, detection component 206 may be operative to detect user plane congestion in a particular direction when the user plane traffic level in that direction reaches or exceeds the capacity for that direction. The embodiments are not limited in this context.
In various embodiments, apparatus 200 and/or system 240 may comprise a configuration component 208. Configuration component 208 may comprise logic, circuitry, and/or instructions operative to initiate and/or implement UPCON mitigation techniques to reduce, eliminate, and/or prevent uplink and/or downlink user plane congestion in radio-to-packet interface 218. In some embodiments, when detection component 206 detects uplink and/or downlink user plane congestion in radio-to-packet interface 218, configuration component 208 may be operative to exchange one or more configuration messages 214 with one or more network devices and/or nodes in order to initiate and/or implement UPCON mitigation. In various embodiments, the UPCON mitigation may comprise configuring one or more network devices and/or nodes in order to use an alternate radio-to-packet interface 220 to accommodate some of the uplink and/or downlink user plane traffic currently allocated to radio-to-packet interface 218.
In some embodiments, configuration component 208 may be operative to exchange one or more configuration messages 214 to directly configure one or more network devices and/or nodes in conjunction with UPCON mitigation. In an example embodiment, configuration component 208 is comprised in an MME and exchanges configuration messages 214 with an eNB in order to configure the eNB to use an alternate S-GW for some user plane data in conjunction with UPCON mitigation. In various embodiments, configuration component 208 may alternatively or additionally be operative to exchange one or more configuration messages 214 to indirectly configure one or more network devices and/or nodes by causing a different device and/or node to perform the direct configuration. In an example embodiment, configuration component 208 is comprised in an eNB and exchanges configuration messages 214 with an MME in order to cause the MME to configure an alternate S-GW to handle some of the user plane data of the eNB in conjunction with UPCON mitigation. The embodiments are not limited to these examples.
In some embodiments, the one or more configured network devices and/or nodes may include devices and/or nodes located in an uplink direction with respect to apparatus 200 and/or system 240, located in a downlink direction with respect to apparatus 200 and/or system 240, or both. Additionally, in various embodiments, apparatus 200 and/or system 240 may comprise one of the one or more configured network devices and/or nodes. Examples of network devices and/or nodes that configuration component 208 may be operative to directly and/or indirectly configure include an eNB, an MME, a serving gateway, a packet gateway, an RNC, a BSC, and an SGSN. The embodiments are not limited to these examples.
In some embodiments, configuration component 208 may be operative to initiate and/or implement an UPCON mitigation technique that comprises maintaining a current serving gateway and/or a current packet gateway associated with radio-to-packet interface 218. In an example embodiment, configuration component 208 may be operative to directly and/or indirectly configure one or more network devices and/or nodes such that some uplink and/or downlink user plane traffic is allocated to an alternate serving gateway but still handled by a current packet gateway. In another example embodiment, configuration component 208 may be operative to directly and/or indirectly configure one or more network devices and/or nodes such that some uplink and/or downlink user plane traffic is allocated to an alternate SGSN but still handled by a current serving gateway. The embodiments are not limited to these examples.
Operations for the above embodiments may be further described with reference to the following figures and accompanying examples. Some of the figures may include a logic flow. Although such figures presented herein may include a particular logic flow, it can be appreciated that the logic flow merely provides an example of how the general functionality as described herein can be implemented. Further, the given logic flow does not necessarily have to be executed in the order presented unless otherwise indicated. In addition, the given logic flow may be implemented by a hardware element, a software element executed by a processor, or any combination thereof. The embodiments are not limited in this context.
At 304, a set of mobile devices served by the radio access network and the serving gateway may be selected. For example, configuration component 208 of
At 604, the eNB may send a Path Switch Request to an MME of the E-UTRAN. In some embodiments, the Path Switch Request may comprise one or more information elements indicating that S1-U interface UPCON mitigation is being performed for the source S-GW. In various embodiments, the Path Switch Request may comprise one or more information elements indicating whether the S1-U interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Path Switch Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, an S1-MME address for the eNB; an international mobile subscriber identity (IMSI) for each impacted UE; an access point name (APN) and/or linked evolved packet system (EPS) bearer identifier (ID) for each affected PDN connection; and/or an EPS bearer ID and/or eNB S1-U address for each affected EPS bearer. In some embodiments, the eNB S1-MME address and/or the eNB S1-U addresses may comprise a fully qualified tunnel endpoint identifier (F-TEID) format. Although the F-TEID format shall not be mentioned in the remaining discussion for purposes of brevity, it is to be understood that the F-TEID format may be used for any or all of the other device addresses discussed below with respect to communications flow 600, as well as those discussed with respect to the other communications flows discussed herein. The embodiments are not limited in this context.
Upon receipt of the Path Switch Request, the MME may select as the target S-GW an S-GW for which an S1-U interface to the eNB is uncongested. In various embodiments, the MME may perform this selection based on user plane traffic information for the target S-GW, such as user plane traffic information 210 of
After receiving the Create Session Request, the target S-GW may send a Modify Bearer Request to a P-GW that supports PDN connections of the selected set of UEs at 608. It is to be understood that although example communications flow 600 illustrates a single P-GW, embodiments are both possible and contemplated in which Modify Bearer Requests are sent to multiple affected P-GWs, and the embodiments are not limited in this context. In some embodiments, the Modify Bearer Request may comprise one or more information elements indicating that S1-U interface UPCON mitigation is being performed for the source S-GW. In various embodiments, the Modify Bearer Request may comprise one or more information elements indicating whether the S1-U interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Modify Bearer Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, a control plane address for the target S-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S5/S8 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 610, in response to receiving the Modify Bearer Request, the P-GW may modify the associated EPS bearer information for each PDN connection of the impacted UEs of the Modify Bearer Request and send a Modify Bearer Response to the target S-GW. As noted above, although communications flow 600 illustrates a single P-GW, there may be multiple affected P-GWs in some embodiments, and thus the target S-GW may receive multiple Modify Bearer Responses at 610. In various embodiments, the Modify Bearer Response may comprise one or more information elements including, for example, an S5/S8 control plane address for the P-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or P-GW S5/S8 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 612, the target S-GW may send a Create Session Response to the MME. In some embodiments, the Create Session Response may comprise one or more information elements including, for example, an S11 address for the target S-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S1-U user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 614, the MME may send a Path Switch Request Acknowledgement to the eNB. In various embodiments, the Path Switch Request Acknowledgement may comprise one or more information elements including, for example, an S1-MME address of the MME; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S1-U user plane address for each affected EPS bearer. In some embodiments, the eNB may modify the affected UEs' EPS bearer information after receiving the Path Switch Request Acknowledgement. The embodiments are not limited in this context.
At 616, the MME may send a Modify Bearer Request or Delete Session Request to the source S-GW, in order to remove the affected UEs' EPS bearer information. In various embodiments, the Modify Bearer Request or Delete Session Request may comprise one or more information elements indicating whether the affected UEs' S1-U traffic has been removed in the uplink direction, the downlink direction, or both. In some embodiments, the Modify Bearer Request or Delete Session Request may comprise one or more additional information elements indicating, for example, an IMSI for each impacted UE; and/or an APN and/or linked EPS bearer ID for each affected PDN connection. At 618, in response to the Modify Bearer Request or Delete Session Request, the source S-GW may send a Modify Bearer Response or Delete Session Response to the MME. In various embodiments, the MME and the S-GW may be operative to exchange a Modify Bearer Request at 616 and a Modify Bearer Response at 618 if the UPCON mitigation is performed with respect to only the uplink direction or only the downlink direction. The embodiments are not limited in this context.
At 704, the MME may then send a Create Session Request to the target S-GW. In some embodiments, the Create Session Request may comprise one or more information elements indicating that S1-U interface UPCON mitigation is being performed for the source S-GW. In various embodiments, the Create Session Request may comprise one or more information elements indicating whether the S1-U interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Create Session Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, an S11 address for the MME; an IMSI for each impacted UE; an APN, linked EPS bearer ID, and/or P-GW S5/S8 control plane or PMIP address for each affected PDN connection; and/or an EPS bearer ID for each affected EPS bearer. The embodiments are not limited in this context.
At 706, the target S-GW may modify the affected UEs' EPS bearer information based on the Create Session Request and then send a Modify Bearer Request to a P-GW that supports PDN connections of the affected UEs. It is to be understood that although example communications flow 700 illustrates a single P-GW, embodiments are both possible and contemplated in which Modify Bearer Requests are sent to multiple affected P-GWs, and the embodiments are not limited in this context. In some embodiments, the Modify Bearer Request may comprise one or more information elements indicating that S1-U interface UPCON mitigation is being performed for the source S-GW. In various embodiments, the Modify Bearer Request may comprise one or more information elements indicating whether the S1-U interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Modify Bearer Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, a control plane address for the target S-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S5/S8 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 708, in response to receiving the Modify Bearer Request, a P-GW may modify the associated EPS bearer information for each PDN connection of the impacted UEs of the Modify Bearer Request and send a Modify Bearer Response to the target S-GW. As noted above, although communications flow 700 illustrates a single P-GW, there may be multiple affected P-GWs in some embodiments, and thus the target S-GW may receive multiple Modify Bearer Responses at 708. In various embodiments, the Modify Bearer Response may comprise one or more information elements including, for example, an S5/S8 control plane address for the P-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or P-GW S5/S8 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 710, the target S-GW may send a Create Session Response to the MME. In some embodiments, the Create Session Response may comprise one or more information elements including, for example, an S11 address for the target S-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S1-U user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 712, the MME may send an E-UTRAN radio access bearer (E-RAB) Modify Request to the eNB. In various embodiments, the E-RAB Modify Request may comprise one or more information elements indicating that S1-U interface UPCON mitigation is being performed for the source S-GW. In some embodiments, the E-RAB Modify Request may comprise one or more information elements indicating whether the S1-U interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In various embodiments, the E-RAB Modify Request may comprise one or more additional information elements. In some embodiments, the one or more additional information elements may comprise, for example, an S1-MME address for the MME; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S1-U user plane address for each affected EPS bearer. The embodiments are not limited in this context.
Upon receiving the E-RAB Modify Request from the MME, the eNB may modify the EPS bearer information for the affected UEs. Then, at 714, the eNB may send an E-RAB Modify Response to the MME in response to the E-RAB Modify Request. In various embodiments, the E-RAB Modify Response may comprise one or more information elements including, for example, an S1-MME address for the eNB; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or eNB S1-U address for each affected EPS bearer. The embodiments are not limited in this context.
At 716, the MME may send a Modify Bearer Request or Delete Session Request to the source S-GW, in order to remove the affected UEs' EPS bearer information. In some embodiments, the Modify Bearer Request or Delete Session Request may comprise one or more information elements indicating whether the affected UEs' S1-U traffic has been removed in the uplink direction, the downlink direction, or both. In various embodiments, the Modify Bearer Request or Delete Session Request may comprise one or more additional information elements indicating, for example, an IMSI for each impacted UE; and/or an APN and/or linked EPS bearer ID for each affected PDN connection. At 718, in response to the Modify Bearer Request or Delete Session Request, the source S-GW may send a Modify Bearer Response or Delete Session Response to the MME. In some embodiments, the MME and the S-GW may be operative to exchange a Modify Bearer Request at 716 and a Modify Bearer Response at 718 if the UPCON mitigation is performed with respect to only the uplink direction or only the downlink direction. The embodiments are not limited in this context.
At 802, the MME may elect to initiate UPCON mitigation. In various embodiments, the MME may elect to initiate UPCON mitigation because the uplink and/or downlink user plane traffic of an S1-U interface between the E-UTRAN and a source S-GW has neared, reached, or exceeded uplink and/or downlink capacities of the S1-U interface. In conjunction with electing to initiate UPCON mitigation, the MME may select, from among the UEs in a cell of an eNB, a set of UEs that are served by the source S-GW and that are to be reassigned to a target S-GW for service. In some embodiments, the MME may select the set of UEs only from among UEs in the cell that are in a connected mode.
At 804, the MME may send an E-RAB Modify Request to the eNB. In various embodiments, the E-RAB Modify Request may comprise one or more information elements indicating that S1-U interface UPCON mitigation is being performed for the source S-GW. In some embodiments, the E-RAB Modify Request may comprise one or more information elements indicating whether the S1-U interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In various embodiments, the E-Docket RAB Modify Request may comprise one or more additional information elements. In some embodiments, the one or more additional information elements may comprise, for example, an S1-MME address for the MME and/or an IMSI for each impacted UE. The embodiments are not limited in this context.
At 806, the eNB may reply to the E-RAB Modify Request by sending an E-RAB Modify Response to the MME. In various embodiments, the E-RAB Modify Response may comprise one or more information elements including, for example, an S1-MME address for the eNB; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or eNB S1-U address for each affected EPS bearer. The embodiments are not limited in this context.
Upon receiving the E-RAB Modify Response, the MME may select as the target S-GW an S-GW for which an S1-U interface to the eNB is uncongested. In some embodiments, the MME may perform this selection based on user plane traffic information for the target S-GW, such as user plane traffic information 210 of
At 810, the target S-GW may modify the affected UEs' EPS bearer information based on the Create Session Request and then send a Modify Bearer Request to a P-GW that supports PDN connections of the affected UEs. It is to be understood that although example communications flow 800 illustrates a single P-GW, embodiments are both possible and contemplated in which Modify Bearer Requests are sent to multiple affected P-GWs, and the embodiments are not limited in this context. In various embodiments, the Modify Bearer Request may comprise one or more information elements indicating that S1-U interface UPCON mitigation is being performed for the source S-GW. In some embodiments, the Modify Bearer Request may comprise one or more information elements indicating whether the S1-U interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In various embodiments, the Modify Bearer Request may comprise one or more additional information elements. In some embodiments, the one or more additional information elements may comprise, for example, a control plane address for the target S-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S5/S8 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 812, in response to receiving the Modify Bearer Request, a P-GW may modify the associated EPS bearer information for each PDN connection of the impacted UEs of the Modify Bearer Request and send a Modify Bearer Response to the target S-GW. As noted above, although communications flow 800 illustrates a single P-GW, there may be multiple affected P-GWs in various embodiments, and thus the target S-GW may receive multiple Modify Bearer Responses at 812. In some embodiments, the Modify Bearer Response may comprise one or more information elements including, for example, an S5/S8 control plane address for the P-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or P-GW S5/S8 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 814, the target S-GW may send a Create Session Response to the MME. In various embodiments, the Create Session Response may comprise one or more information elements including, for example, an S11 address for the target S-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S1-U user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 816, the MME may send an E-RAB Modify Response Acknowledgment to the eNB. In some embodiments, the E-RAB Modify Response Acknowledgment may comprise one or more information elements including, for example, an S1-MME address for the MME; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target S-GW S1-U user plane address for each affected EPS bearer. In various embodiments, the eNB may modify the affected UEs' EPS bearer information upon receipt of the E-RAB Modify Response Acknowledgment. The embodiments are not limited in this context.
At 818, the MME may send a Modify Bearer Request or Delete Session Request to the source S-GW, in order to remove the affected UEs' EPS bearer information. In some embodiments, the Modify Bearer Request or Delete Session Request may comprise one or more information elements indicating whether the affected UEs' S1-U traffic has been removed in the uplink direction, the downlink direction, or both. In various embodiments, the Modify Bearer Request or Delete Session Request may comprise one or more additional information elements indicating, for example, an IMSI for each impacted UE; and/or an APN and/or linked EPS bearer ID for each affected PDN connection. At 820, in response to the Modify Bearer Request or Delete Session Request, the source S-GW may send a Modify Bearer Response or Delete Session Response to the MME. In some embodiments, the MME and the S-GW may be operative to exchange a Modify Bearer Request at 818 and a Modify Bearer Response at 820 if the UPCON mitigation is performed with respect to only the uplink direction or only the downlink direction. The embodiments are not limited in this context.
At 904, a set of mobile devices served by the radio access network and the intermediate packet routing device may be selected. For example, configuration component 208 of
At 1204, the RNC may send an Iu Switch Request to the target SGSN. In some embodiments, the Iu Switch Request may comprise one or more information elements indicating that Iu-PS interface UPCON mitigation is being performed for the source SGSN. In various embodiments, the Iu Switch Request may comprise one or more information elements indicating whether the Iu-PS interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Iu Switch Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, an IMSI for each impacted UE; and/or an RAB ID, transport layer address, and/or Iu transport association for each affected RAB. The embodiments are not limited in this context.
At 1206, the target SGSN may send a Modify Bearer Request to an S-GW that supports PDN connections of the selected set of UEs. It is to be understood that although example communications flow 1200 illustrates a single S-GW, embodiments are both possible and contemplated in which Modify Bearer Requests are sent to multiple affected S-GWs, and the embodiments are not limited in this context. In some embodiments, the Modify Bearer Request may comprise one or more information elements indicating that Iu-PS interface UPCON mitigation is being performed for the source SGSN. In various embodiments, the Modify Bearer Request may comprise one or more information elements indicating whether the Iu-PS interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Modify Bearer Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, a target SGSN S4 control plane address; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target SGSN S4 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 1208, in response to receiving the Modify Bearer Request, the S-GW may modify the associated EPS bearer information for each PDN connection of the impacted UEs of the Modify Bearer Request and send a Modify Bearer Response to the target SGSN. As noted above, although communications flow 1200 illustrates a single S-GW, there may be multiple affected S-GWs in some embodiments, and thus the target SGSN may receive multiple Modify Bearer Responses at 1208. In various embodiments, the Modify Bearer Response may comprise one or more information elements including, for example, an S4 control plane address for the S-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or S-GW S4 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 1210, the target SGSN may modify the associated RAB information for the affected RABs associated with the Modify Bearer Response and send an Iu Switch Request Acknowledgment to the RNC. In some embodiments, the Iu Switch Request Acknowledgment may comprise one or more information elements including, for example, an IMSI for each impacted UE; and/or an RAB ID, transport layer address, and/or Iu transport association for each affected RAB. The embodiments are not limited in this context.
At 1212, the RNC may modify the associated RAB information for the affected RABs associated with the Iu Switch Request Acknowledgment and may send an Iu Release Request or a RAB Release Request to the source SGSN. In various embodiments, the Iu Release Request or RAB Release Request may comprise one or more information elements indicating whether the affected UEs' Iu-PS traffic has been removed in the uplink direction, the downlink direction, or both. In some embodiments, the Iu Release Request or RAB Release Request may comprise one or more additional information elements indicating, for example, an IMSI for each impacted UE. At 1214, in response to the Iu Release Request or RAB Release Request, the source SGSN may remove the impacted RNC context for the impacted UEs and optionally send an Iu Release Request Acknowledgment or RAB Release Request Acknowledgment to the RNC. The embodiments are not limited in this context.
At 1302, the source SGSN may elect to initiate UPCON mitigation. In various embodiments, the source SGSN may elect to initiate UPCON mitigation because the uplink and/or downlink user plane traffic of an Iu-PS interface between the UTRAN and the source SGSN has neared, reached, or exceeded uplink and/or downlink capacities of the Iu-PS interface. In conjunction with electing to initiate UPCON mitigation, the source SGSN may select, from among the UEs in a cell of a node B served by an RNC, a set of UEs that are served by the source SGSN and that are to be reassigned to a target SGSN for service. In some embodiments, the source SGSN may select the set of UEs only from among UEs in the cell that are in a connected mode. In various embodiments, the source SGSN may select as the target SGSN an SGSN for which an Iu-PS interface to the node B is uncongested. In some embodiments, the source SGSN may perform this selection based on user plane traffic information for the target SGSN, such as user plane traffic information 210 of
At 1304, the source SGSN may send an Iu Switch Trigger to the RNC. In various embodiments, the Iu Switch Trigger may comprise one or more information elements indicating that Iu-PS interface UPCON mitigation is being performed for the source SGSN. In some embodiments, the Iu Switch Trigger may comprise one or more information elements indicating whether the Iu-PS interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In various embodiments, the Iu Switch Trigger may comprise one or more information elements indicating a control plane address for the target SGSN. In some embodiments, the Iu Switch Trigger may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, an IMSI for each impacted UE. The embodiments are not limited in this context.
At 1306, the RNC may send an Iu Switch Request to the target SGSN. In some embodiments, the Iu Switch Request may comprise one or more information elements indicating that Iu-PS interface UPCON mitigation is being performed for the source SGSN. In various embodiments, the Iu Switch Request may comprise one or more information elements indicating whether the Iu-PS interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Iu Switch Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, an IMSI for each impacted UE; and/or an RAB ID, transport layer address, and/or Iu transport association for each affected RAB. The embodiments are not limited in this context.
At 1308, the target SGSN may send a Modify Bearer Request to an S-GW that supports PDN connections of the selected set of UEs. It is to be understood that although example communications flow 1300 illustrates a single S-GW, embodiments are both possible and contemplated in which Modify Bearer Requests are sent to multiple affected S-GWs, and the embodiments are not limited in this context. In some embodiments, the Modify Bearer Request may comprise one or more information elements indicating that Iu-PS interface UPCON mitigation is being performed for the source SGSN. In various embodiments, the Modify Bearer Request may comprise one or more information elements indicating whether the Iu-PS interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Modify Bearer Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, a target SGSN S4 control plane address; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target SGSN S4 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 1310, in response to receiving the Modify Bearer Request, the S-GW may modify the associated EPS bearer information for each PDN connection of the impacted UEs of the Modify Bearer Request and send a Modify Bearer Response to the target SGSN. As noted above, although communications flow 1300 illustrates a single S-GW, there may be multiple affected S-GWs in some embodiments, and thus the target SGSN may receive multiple Modify Bearer Responses at 1310. In various embodiments, the Modify Bearer Response may comprise one or more information elements including, for example, an S4 control plane address for the S-GW; an IMSI for each impacted UE; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or S-GW S4 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 1312, the target SGSN may modify the associated RAB information for the affected RABs associated with the Modify Bearer Response and send an Iu Switch Request Acknowledgment to the RNC. In some embodiments, the Iu Switch Request Acknowledgment may comprise one or more information elements including, for example, an IMSI for each impacted UE; and/or an RAB ID, transport layer address, and/or Iu transport association for each affected RAB. The embodiments are not limited in this context.
At 1314, the RNC may modify the associated RAB information for the affected RABs associated with the Iu Switch Request Acknowledgment and may send an Iu Release Request or a RAB Release Request to the source SGSN. In various embodiments, the Iu Release Request or RAB Release Request may comprise one or more information elements indicating whether the affected UEs' Iu-PS traffic has been removed in the uplink direction, the downlink direction, or both. In some embodiments, the Iu Release Request or RAB Release Request may comprise one or more additional information elements indicating, for example, an IMSI for each impacted UE. At 1316, in response to the Iu Release Request or RAB Release Request, the source SGSN may remove the impacted RNC context for the impacted UEs and optionally send an Iu Release Request Acknowledgment or RAB Release Request Acknowledgment to the RNC. The embodiments are not limited in this context.
At 1604, the BSC may send a Gb Switch Request to the target SGSN. In some embodiments, the Gb Switch Request may comprise one or more information elements indicating that Gb interface UPCON mitigation is being performed for the source SGSN. In various embodiments, the Gb Switch Request may comprise one or more information elements indicating whether the Gb interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Gb Switch Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, an IMSI for each impacted MS. The embodiments are not limited in this context.
At 1606, the target SGSN may send a Modify Bearer Request to an S-GW that supports PDN connections of the selected set of MSs. It is to be understood that although example communications flow 1600 illustrates a single S-GW, embodiments are both possible and contemplated in which Modify Bearer Requests are sent to multiple affected S-GWs, and the embodiments are not limited in this context. In some embodiments, the Modify Bearer Request may comprise one or more information elements indicating that Gb interface UPCON mitigation is being performed for the source SGSN. In various embodiments, the Modify Bearer Request may comprise one or more information elements indicating whether the Gb interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Modify Bearer Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, a target SGSN S4 control plane address; an IMSI for each impacted MS; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target SGSN S4 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 1608, in response to receiving the Modify Bearer Request, the S-GW may modify the associated EPS bearer information for each PDN connection of the impacted MSs of the Modify Bearer Request and send a Modify Bearer Response to the target SGSN. As noted above, although communications flow 1600 illustrates a single S-GW, there may be multiple affected S-GWs in some embodiments, and thus the target SGSN may receive multiple Modify Bearer Responses at 1608. In various embodiments, the Modify Bearer Response may comprise one or more information elements including, for example, an S4 control plane address for the S-GW; an IMSI for each impacted MS; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or S-GW S4 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 1610, the target SGSN may modify the affected BSS context information associated with the Modify Bearer Response and send a Gb Switch Request Acknowledgment to the BSC. In some embodiments, the Gb Switch Request Acknowledgment may comprise one or more information elements including, for example, an IMSI for each impacted MS. The embodiments are not limited in this context.
At 1612, the BSC may modify the affected BSS context information associated with the Gb Switch Request Acknowledgment and may send a Gb Release Request or a RAB Release Request to the source SGSN. In various embodiments, the Gb Release Request or RAB Release Request may comprise one or more information elements indicating whether the affected MSs' Gb traffic has been removed in the uplink direction, the downlink direction, or both. In some embodiments, the Gb Release Request or RAB Release Request may comprise one or more additional information elements indicating, for example, an IMSI for each impacted MS. At 1614, in response to the Gb Release Request or RAB Release Request, the source SGSN may remove the impacted BSS context for the impacted MSs and optionally send a Gb Release Request Acknowledgment or RAB Release Request Acknowledgment to the BSC. The embodiments are not limited in this context.
At 1702, the source SGSN may elect to initiate UPCON mitigation. In various embodiments, the source SGSN may elect to initiate UPCON mitigation because the uplink and/or downlink user plane traffic of a Gb interface between the GERAN and the source SGSN has neared, reached, or exceeded uplink and/or downlink capacities of the Gb interface. In conjunction with electing to initiate UPCON mitigation, the source SGSN may select, from among the MSs in a cell of a BTS served by a BSC, a set of MSs that are served by the source SGSN and that are to be reassigned to a target SGSN for service. In some embodiments, the source SGSN may select the set of MSs only from among MSs in the cell that are in a connected mode. In various embodiments, the source SGSN may select as the target SGSN an SGSN for which a Gb interface to the BTS is uncongested. In some embodiments, the source SGSN may perform this selection based on user plane traffic information for the target SGSN, such as user plane traffic information 210 of
At 1704, the source SGSN may send a Gb Switch Trigger to the BSC. In various embodiments, the Gb Switch Trigger may comprise one or more information elements indicating that Gb interface UPCON mitigation is being performed for the source SGSN. In some embodiments, the Gb Switch Trigger may comprise one or more information elements indicating whether the Gb interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In various embodiments, the Gb Switch Trigger may comprise one or more information elements indicating a control plane address for the target SGSN. In some embodiments, the Gb Switch Trigger may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, an IMSI for each impacted MS. The embodiments are not limited in this context.
At 1706, the BSC may send a Gb Switch Request to the target SGSN. In some embodiments, the Gb Switch Request may comprise one or more information elements indicating that Gb interface UPCON mitigation is being performed for the source SGSN. In various embodiments, the Gb Switch Request may comprise one or more information elements indicating whether the Gb interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Gb Switch Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, an IMSI for each impacted MS. The embodiments are not limited in this context.
At 1708, the target SGSN may send a Modify Bearer Request to an S-GW that supports PDN connections of the selected set of MSs. It is to be understood that although example communications flow 1700 illustrates a single S-GW, embodiments are both possible and contemplated in which Modify Bearer Requests are sent to multiple affected S-GWs, and the embodiments are not limited in this context. In some embodiments, the Modify Bearer Request may comprise one or more information elements indicating that Gb interface UPCON mitigation is being performed for the source SGSN. In various embodiments, the Modify Bearer Request may comprise one or more information elements indicating whether the Gb interface UPCON mitigation is being performed with respect to the uplink direction, the downlink direction, or both. In some embodiments, the Modify Bearer Request may comprise one or more additional information elements. In various embodiments, the one or more additional information elements may comprise, for example, a target SGSN S4 control plane address; an IMSI for each impacted MS; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or target SGSN S4 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 1710, in response to receiving the Modify Bearer Request, the S-GW may modify the associated EPS bearer information for each PDN connection of the impacted MSs of the Modify Bearer Request and send a Modify Bearer Response to the target SGSN. As noted above, although communications flow 1700 illustrates a single S-GW, there may be multiple affected S-GWs in some embodiments, and thus the target SGSN may receive multiple Modify Bearer Responses at 1710. In various embodiments, the Modify Bearer Response may comprise one or more information elements including, for example, an S4 control plane address for the S-GW; an IMSI for each impacted MS; an APN and/or linked EPS bearer ID for each affected PDN connection; and/or an EPS bearer ID and/or S-GW S4 user plane address for each affected EPS bearer. The embodiments are not limited in this context.
At 1712, the target SGSN may modify the affected BSS context information associated with the Modify Bearer Response and send a Gb Switch Request Acknowledgment to the BSC. In some embodiments, the Gb Switch Request Acknowledgment may comprise one or more information elements including, for example, an IMSI for each impacted MS. The embodiments are not limited in this context.
At 1714, the BSC may modify the affected BSS context information associated with the Gb Switch Request Acknowledgment and may send a Gb Release Request or a RAB Release Request to the source SGSN. In various embodiments, the Gb Release Request or RAB Release Request may comprise one or more information elements indicating whether the affected MSs' Gb traffic has been removed in the uplink direction, the downlink direction, or both. In some embodiments, the Gb Release Request or RAB Release Request may comprise one or more additional information elements indicating, for example, an IMSI for each impacted MS. At 1716, in response to the Gb Release Request or RAB Release Request, the source SGSN may remove the impacted BSS context for the impacted MSs and optionally send a Gb Release Request Acknowledgment or RAB Release Request Acknowledgment to the BSC. The embodiments are not limited in this context.
The device 1900 may implement some or all of the structure and/or operations for the apparatus 200, system 240, storage medium 1800, and/or logic circuit 1928 in a single computing entity, such as entirely within a single device. Alternatively, the device 1900 may distribute portions of the structure and/or operations for the apparatus 200, system 240, storage medium 1800, and/or logic circuit 1928 across multiple computing entities using a distributed system architecture, such as a client-server architecture, a 3-tier architecture, an N-tier architecture, a tightly-coupled or clustered architecture, a peer-to-peer architecture, a master-slave architecture, a shared database architecture, and other types of distributed systems. The embodiments are not limited in this context.
In one embodiment, radio interface 1910 may include a component or combination of components adapted for transmitting and/or receiving single carrier or multi-carrier modulated signals (e.g., including complementary code keying (CCK) and/or orthogonal frequency division multiplexing (OFDM) symbols) although the embodiments are not limited to any specific over-the-air interface or modulation scheme. Radio interface 1910 may include, for example, a receiver 1912, a frequency synthesizer 1914, and/or a transmitter 1916. Radio interface 1910 may include bias controls, a crystal oscillator and/or one or more antennas 1918-f. In another embodiment, radio interface 1910 may use external voltage-controlled oscillators (VCOs), surface acoustic wave filters, intermediate frequency (IF) filters and/or RF filters, as desired. Due to the variety of potential RF interface designs an expansive description thereof is omitted.
Baseband circuitry 1920 may communicate with radio interface 1910 to process receive and/or transmit signals and may include, for example, an analog-to-digital converter 1922 for down converting received signals, a digital-to-analog converter 1924 for up converting signals for transmission. Further, baseband circuitry 1920 may include a baseband or physical layer (PHY) processing circuit 1926 for PHY link layer processing of respective receive/transmit signals. Baseband circuitry 1920 may include, for example, a medium access control (MAC) processing circuit 1927 for MAC/data link layer processing. Baseband circuitry 1920 may include a memory controller 1932 for communicating with MAC processing circuit 1927 and/or a computing platform 1930, for example, via one or more interfaces 1934.
In some embodiments, PHY processing circuit 1926 may include a frame construction and/or detection module, in combination with additional circuitry such as a buffer memory, to construct and/or deconstruct communication frames and/or packets. Alternatively or in addition, MAC processing circuit 1927 may share processing for certain of these functions or perform these processes independent of PHY processing circuit 1926. In some embodiments, MAC and PHY processing may be integrated into a single circuit.
The computing platform 1930 may provide computing functionality for the device 1900. As shown, the computing platform 1930 may include a processing component 1940. In addition to, or alternatively of, the baseband circuitry 1920, the device 1900 may execute processing operations or logic for the apparatus 200, system 240, storage medium 1800, and/or logic circuit 1928 using the processing component 1940. The processing component 1940 (and/or PHY 1926 and/or MAC 1927) may comprise various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processor circuits (e.g., processor circuit 120), circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.
The computing platform 1930 may further include other platform components 1950. Other platform components 1950 include common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components (e.g., digital displays), power supplies, and so forth. Examples of memory units may include without limitation various types of computer readable and machine readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information.
Device 1900 may be, for example, an ultra-mobile device, a mobile device, a fixed device, a machine-to-machine (M2M) device, a personal digital assistant (PDA), a mobile computing device, a smart phone, a telephone, a digital telephone, a cellular telephone, user equipment, eBook readers, a handset, a one-way pager, a two-way pager, a messaging device, a computer, a personal computer (PC), a desktop computer, a laptop computer, a notebook computer, a netbook computer, a handheld computer, a tablet computer, a server, a server array or server farm, a web server, a network server, an Internet server, a work station, a mini-computer, a main frame computer, a supercomputer, a network appliance, a web appliance, a distributed computing system, multiprocessor systems, processor-based systems, consumer electronics, programmable consumer electronics, game devices, television, digital television, set top box, wireless access point, base station, node B, subscriber station, mobile subscriber center, radio network controller, router, hub, gateway, bridge, switch, machine, or combination thereof. Accordingly, functions and/or specific configurations of device 1900 described herein, may be included or omitted in various embodiments of device 1900, as suitably desired. In some embodiments, device 1900 may be configured to be compatible with protocols and frequencies associated one or more of the 3GPP LTE Specifications and/or IEEE 802.16 Standards for WMANs, and/or other broadband wireless networks, cited herein, although the embodiments are not limited in this respect.
Embodiments of device 1900 may be implemented using single input single output (SISO) architectures. However, certain implementations may include multiple antennas (e.g., antennas 1918-f) for transmission and/or reception using adaptive antenna techniques for beamforming or spatial division multiple access (SDMA) and/or using MIMO communication techniques.
The components and features of device 1900 may be implemented using any combination of discrete circuitry, application specific integrated circuits (ASICs), logic gates and/or single chip architectures. Further, the features of device 1900 may be implemented using microcontrollers, programmable logic arrays and/or microprocessors or any combination of the foregoing where suitably appropriate. It is noted that hardware, firmware and/or software elements may be collectively or individually referred to herein as “logic” or “circuit.”
It should be appreciated that the exemplary device 1900 shown in the block diagram of
In the exemplary broadband wireless access system 2000, access service networks (ASN) 2012, 2018 are capable of coupling with base stations (BS) (or eNodeBs) 2014, 2020, respectively, to provide wireless communication between one or more fixed devices 2016 and internet 2010 and/or between or one or more mobile devices 2022 and Internet 2010. One example of a fixed device 2016 and a mobile device 2022 is device 1900, with the fixed device 2016 comprising a stationary version of device 1900 and the mobile device 2022 comprising a mobile version of device 1900. ASNs 2012, 2018 may implement profiles that are capable of defining the mapping of network functions to one or more physical entities on broadband wireless access system 2000. Base stations (or eNodeBs) 2014, 2020 may comprise radio equipment to provide RF communication with fixed device 2016 and/or mobile device 2022, such as described with reference to device 1900, and may comprise, for example, the PHY and MAC layer equipment in compliance with a 3GPP LTE Specification or an IEEE 802.16 Standard. Base stations (or eNodeBs) 2014, 2020 may further comprise an IP backplane to couple to Internet 2010 via ASNs 2012, 2018, respectively, although the scope of the claimed subject matter is not limited in these respects.
Broadband wireless access system 2000 may further comprise a visited connectivity service network (CSN) 2024 capable of providing one or more network functions including but not limited to proxy and/or relay type functions, for example authentication, authorization and accounting (AAA) functions, dynamic host configuration protocol (DHCP) functions, or domain name service controls or the like, domain gateways such as public switched telephone network (PSTN) gateways or voice over internet protocol (VoIP) gateways, and/or internet protocol (IP) type server functions, or the like. However, these are merely example of the types of functions that are capable of being provided by visited CSN 2024 or home CSN 2026, and the scope of the claimed subject matter is not limited in these respects. Visited CSN 2024 may be referred to as a visited CSN in the case where visited CSN 2024 is not part of the regular service provider of fixed device 2016 or mobile device 2022, for example where fixed device 2016 or mobile device 2022 is roaming away from its respective home CSN 2026, or where broadband wireless access system 2000 is part of the regular service provider of fixed device 2016 or mobile device 2022 but where broadband wireless access system 2000 may be in another location or state that is not the main or home location of fixed device 2016 or mobile device 2022.
Fixed device 2016 may be located anywhere within range of one or both base stations (or eNodeBs) 2014, 2020, such as in or near a home or business to provide home or business customer broadband access to Internet 2010 via base stations (or eNodeBs) 2014, 2020 and ASNs 2012, 2018, respectively, and home CSN 2026. It is worthy of note that although fixed device 2016 is generally disposed in a stationary location, it may be moved to different locations as needed. Mobile device 2022 may be utilized at one or more locations if mobile device 2022 is within range of one or both base stations (or eNodeBs) 2014, 2020, for example.
In accordance with one or more embodiments, operation support system (OSS) 2028 may be part of broadband wireless access system 2000 to provide management functions for broadband wireless access system 2000 and to provide interfaces between functional entities of broadband wireless access system 2000. Broadband wireless access system 2000 of
Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints.
One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as “IP cores” may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor. Some embodiments may be implemented, for example, using a machine-readable medium or article which may store an instruction or a set of instructions that, if executed by a machine, may cause the machine to perform a method and/or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage unit, for example, memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.
The following examples pertain to further embodiments:
Example 1 is an evolved node B (eNB), comprising: a processor circuit; a detection component for execution by the processor circuit to detect user plane congestion between an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN) and a serving gateway (S-GW) of an evolved packet core (EPC); and a configuration component for execution by the processor circuit to select a set of user equipment (UEs) served by the E-UTRAN and the S-GW and send a request to utilize an alternate S-GW of the EPC to serve the set of UEs while maintaining a current packet data network (PDN) gateway (P-GW) for the set of UEs.
In Example 2, the detection component of Example 1 may optionally be for execution by the processor circuit to detect the user plane congestion in an S1-U interface between the E-UTRAN and the S-GW.
In Example 3, the configuration component of any one of Examples 1 to 2 may optionally be for execution by the processor circuit to select the set of UEs from among a plurality of UEs that are in a connected mode.
In Example 4, the configuration component of any one of Examples 1 to 3 may optionally be for execution by the processor circuit to select the set of UEs from among a plurality of UEs served by the eNB.
In Example 5, the request of any one of Examples 1 to 4 may optionally comprise a request to utilize the alternate S-GW to serve the set of UEs in both an uplink direction and a downlink direction when the detection component detects the user plane congestion in both the uplink direction and the downlink direction.
In Example 6, the request of any one of Examples 1 to 5 may optionally comprise a request to utilize the alternate S-GW to serve the set of UEs in only an uplink direction or only a downlink direction when the detection component detects the user plane congestion in only the uplink direction or only the downlink direction.
In Example 7, the request of any one of Examples 1 to 6 may optionally comprise a Path Switch Request message including an information element indicating that user plane congestion (UPCON) mitigation is to be performed for an S1-U interface between the E-UTRAN and the S-GW.
In Example 8, the eNB of any one of Examples 1 to 7 may optionally comprise one or more radio frequency (RF) antennas.
Example 9 is a mobility management entity (MME), comprising: processing circuitry; a detection component for execution by the processing circuitry to identify S1-U interface congestion with respect to an interface between a source serving gateway (S-GW) and an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN); and a configuration component for execution by the processing circuitry to select a target S-GW for which an S1-U interface to the E-UTRAN is uncongested, select, from among user equipment (UEs) served by an evolved node B (eNB) of the E-UTRAN, a set of UEs for which the source S-GW provides data plane connectivity to a packet data network (PDN) gateway (P-GW), and initiate congestion mitigation comprising reassigning the set of UEs to the target S-GW for data plane connectivity to the P-GW with respect to at least one of a downlink direction and an uplink direction, while maintaining the P-GW for the set of UEs.
In Example 10, the configuration component of Example 9 may optionally be for execution by the processing circuitry to: when S1-U interface congestion is identified with respect to only the downlink direction, initiate congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to only the downlink direction while maintaining the source S-GW with respect to the uplink direction; when S1-U interface congestion is identified with respect to only the uplink direction, initiate congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to only the uplink direction while maintaining the source S-GW with respect to the downlink direction; and when S1-U interface congestion is identified with respect to both the downlink direction and the uplink direction, initiate congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to both the uplink direction and the downlink direction.
In Example 11, the detection component of any one of Examples 9 to 10 may optionally be for execution by the processing circuitry to identify the S1-U interface congestion with respect to the interface between the source S-GW and the E-UTRAN based on one or both of a comparison of a downlink traffic level of the interface with a downlink capacity of the interface and a comparison of an uplink traffic level of the interface with an uplink capacity of the interface.
In Example 12, the set of UEs of any one of Examples 9 to 11 may optionally be selected from among connected mode UEs served by the eNB.
In Example 13, the configuration component of any one of Examples 9 to 12 may optionally be for execution by the processing circuitry to initiate the congestion mitigation by sending a Create Session Request message.
In Example 14, the configuration component of any one of Examples 9 to 12 may optionally be for execution by the processing circuitry to initiate the congestion mitigation by sending an E-UTRAN radio access bearer (E-RAB) message.
In Example 15, the detection component of any one of Examples 9 to 14 may optionally be for execution by the processing circuitry to receive traffic information for the target S-GW and determine that the S1-U interface from the target S-GW to the E-UTRAN is uncongested based on the traffic information.
In Example 16, the congestion mitigation of any one of Examples 9 to 15 may optionally comprise maintaining the source S-GW for at least one UE served by the eNB.
In Example 17, the MME of any one of Examples 9 to 16 may optionally comprise a radio frequency (RF) transceiver and one or more RF antennas.
Example 18 is a congestion mitigation method, comprising: detecting, by processing circuitry at a first serving general packet radio service support node (SGSN), user plane congestion (UPCON) with respect to one or both of an uplink direction and a downlink direction in an interface between a radio access network and the first SGSN; selecting a second SGSN; and sending a trigger message to initiate UPCON mitigation comprising reallocating user plane traffic of a set of mobile devices from the first SGSN to the second SGSN, while maintaining a current serving gateway (S-GW) to handle the user plane traffic of the set of mobile devices.
In Example 19, the congestion mitigation method of Example 18 may optionally comprise selecting the set of mobile devices from among connected mode mobile devices in the radio access network for which user plane traffic is handled by the first SGSN.
In Example 20, the congestion mitigation method of any one of Examples 18 to 19 may optionally comprise selecting as the second SGSN an SGSN for which an interface connection to the radio access network is uncongested.
In Example 21, the interface of any one of Examples 18 to 20 may optionally comprise an Iu-PS interface, the radio access network may optionally comprise a universal mobile telecommunications system (UMTS) terrestrial radio access network (UTRAN), and the set of mobile devices may optionally comprise a set of user equipment (UEs) selected from among
UEs served by a radio network controller (RNC) of the UTRAN.
In Example 22, the interface of any one of Examples 18 to 20 may optionally comprise a Gb interface, the radio access network may optionally comprise a global system for mobile communications (GSM)/enhanced data rates for GSM evolution (EDGE) radio access network (GERAN), and the set of mobile devices may optionally comprise a set of mobile stations (MSs) selected from among MSs served by a base station controller (BSC) of the GERAN.
In Example 23, the UPCON mitigation of any one of Examples 18 to 22 may optionally comprise reallocating the user plane traffic of the set of mobile devices from the first SGSN to the second SGSN, while maintaining the current S-GW and a current packet data network (PDN) gateway (P-GW) to handle the user plane traffic of the set of mobile devices.
In Example 24, the UPCON mitigation of any one of Examples 18 to 23 may optionally comprise: when UPCON is detected with respect to only the uplink direction, reallocating uplink user plane traffic of the set of mobile devices from the first SGSN to the second SGSN, while maintaining the first SGSN to handle downlink user plane traffic of the set of mobile devices; and when UPCON is detected with respect to only the downlink direction, reallocating downlink user plane traffic of the set of mobile devices from the first SGSN to the second SGSN, while maintaining the first SGSN to handle uplink user plane traffic of the set of mobile devices.
In Example 25, the trigger message of any one of Examples 18 to 24 may optionally comprise an Iu Switch Request or a Gb Switch Request.
Example 26 is at least one machine-readable medium comprising a set of instructions that, in response to being executed on a computing device, cause the computing device to perform a congestion mitigation method according to any one of Examples 18 to 25.
Example 27 is an apparatus, comprising means for performing a congestion mitigation method according to any one of Examples 18 to 25.
Example 28 is a system, comprising: an apparatus according to Example 27; and one or more radio frequency (RF) transceivers.
Example 29 is a communications device arranged to perform a congestion mitigation method according to any one of Examples 18 to 25.
Example 30 is a congestion mitigation method, comprising: identifying, by an evolved node B (eNB), S1-U interface congestion with respect to an interface between a source serving gateway (S-GW) and an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN) of the eNB; selecting a target S-GW for which an S1-U interface to the E-UTRAN is uncongested; selecting, from among user equipment (UEs) served by the eNB, a set of UEs for which the source S-GW provides data plane connectivity to a packet data network (PDN) gateway (P-GW); and initiating congestion mitigation comprising reassigning the set of UEs to the target S-GW for data plane connectivity to the P-GW with respect to at least one of a downlink direction and an uplink direction, while maintaining the P-GW for the set of UEs.
In Example 31, the congestion mitigation method of Example 30 may optionally comprise: when S1-U interface congestion is identified with respect to only the downlink direction, initiating congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to only the downlink direction while maintaining the source S-GW with respect to the uplink direction; when S1-U interface congestion is identified with respect to only the uplink direction, initiating congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to only the uplink direction while maintaining the source S-GW with respect to the downlink direction; and when S1-U interface congestion is identified with respect to both the downlink direction and the uplink direction, initiating congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to both the uplink direction and the downlink direction.
In Example 32, the congestion mitigation method of any one of Examples 30 to 31 may optionally comprise identifying the S1-U interface congestion with respect to the interface between the source S-GW and the E-UTRAN based on one or both of a comparison of a downlink traffic level of the interface with a downlink capacity of the interface and a comparison of an uplink traffic level of the interface with an uplink capacity of the interface.
In Example 33, the set of UEs of any one of Examples 30 to 32 may optionally be selected from among connected mode UEs served by the eNB.
In Example 34, the congestion mitigation method of any one of Examples 30 to 33 may optionally comprise initiating the congestion mitigation by sending a Path Switch Request message.
In Example 35, the Path Switch Request message of Example 34 may optionally comprise an information element indicating that user plane congestion (UPCON) mitigation is to be performed for the interface between the S-GW and the E-UTRAN.
In Example 36, the congestion mitigation method of any one of Examples 30 to 35 may optionally comprise receiving traffic information for the target S-GW and determining that the S1-U interface from the target S-GW to the E-UTRAN is uncongested based on the traffic information.
In Example 37, the congestion mitigation of any one of Examples 30 to 36 may optionally comprise maintaining the source S-GW for at least one UE served by the eNB.
Example 38 is at least one machine-readable medium comprising a set of instructions that, in response to being executed on a computing device, cause the computing device to perform a congestion mitigation method according to any one of Examples 30 to 37.
Example 39 is an apparatus, comprising means for performing a congestion mitigation method according to any one of Examples 30 to 37.
Example 40 is a system, comprising: an apparatus according to Example 39; and one or more radio frequency (RF) transceivers.
Example 41 is a communications device arranged to perform a congestion mitigation method according to any one of Examples 30 to 37.
Example 42 is a user plane congestion mitigation method, comprising: detecting, by a mobility management entity (MME), user plane congestion between an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN) and a serving gateway (S-GW) of an evolved packet core (EPC); selecting a set of user equipment (UEs) served by the E-UTRAN and the S-GW; and sending a request to utilize an alternate S-GW of the EPC to serve the set of UEs while maintaining a current packet data network (PDN) gateway (P-GW) for the set of UEs.
In Example 43, the user plane congestion mitigation method of Example 42 may optionally comprise detecting the user plane congestion in an S1-U interface between the E-UTRAN and the S-GW.
In Example 44, the user plane congestion mitigation method of any one of Examples 42 to 43 may optionally comprise selecting the set of UEs from among a plurality of UEs that are in a connected mode.
In Example 45, the user plane congestion mitigation method of any one of Examples 42 to 44 may optionally comprise selecting the set of UEs from among a plurality of UEs served by an evolved node B (eNB) of the E-UTRAN.
In Example 46, the request of any one of Examples 42 to 45 may optionally comprise a request to utilize the alternate S-GW to serve the set of UEs in both an uplink direction and a downlink direction when user plane congestion is detected in both the uplink direction and the downlink direction.
In Example 47, the request of any one of Examples 42 to 46 may optionally comprise a request to utilize the alternate S-GW to serve the set of UEs in only an uplink direction or only a downlink direction when user plane congestion is detected in only the uplink direction or only the downlink direction.
In Example 48, the request of any one of Examples 42 to 47 may optionally comprise a Create Session Request message including an information element indicating that user plane congestion mitigation is to be performed for an S1-U interface between the E-UTRAN and the S-GW.
In Example 49, the request of any one of Examples 42 to 47 may optionally comprise an E-UTRAN radio access bearer (E-RAB) message including an information element indicating that user plane congestion mitigation is to be performed for an S1-U interface between the E-UTRAN and the S-GW.
Example 50 is at least one machine-readable medium comprising a set of instructions that, in response to being executed on a computing device, cause the computing device to perform a user plane congestion mitigation method according to any one of Examples 42 to 49.
Example 51 is an apparatus, comprising means for performing a user plane congestion mitigation method according to any one of Examples 42 to 49.
Example 52 is a system, comprising: an apparatus according to Example 51; and one or more radio frequency (RF) transceivers.
Example 53 is a communications device arranged to perform a user plane congestion mitigation method according to any one of Examples 42 to 49.
Example 54 is a radio network controller (RNC), comprising: processing circuitry; a detection component for execution by the processing circuitry to detect user plane congestion between a universal mobile telecommunications system (UMTS) terrestrial radio access network (UTRAN) and a serving general packet radio service support node (SGSN); and a configuration component for execution by the processing circuitry to select a set of user equipment (UEs) served by the UTRAN and the SGSN and send a request to utilize an alternate SGSN to serve the set of UEs while maintaining a current serving gateway (S-GW) for the set of UEs.
In Example 55, the detection component of Example 54 may optionally be for execution by the processing circuitry to detect the user plane congestion in an Iu-PS interface between the UTRAN and the SGSN.
In Example 56, the configuration component of any one of Examples 54 to 55 may optionally be for execution by the processing circuitry to select the set of UEs from among a plurality of UEs that are in a connected mode.
In Example 57, the configuration component of any one of Examples 54 to 56 may optionally be for execution by the processing circuitry to select the set of UEs from among a plurality of UEs served by the RNC.
In Example 58, the request of any one of Examples 54 to 57 may optionally comprise a request to utilize the alternate SGSN to serve the set of UEs in both an uplink direction and a downlink direction when the detection component detects the user plane congestion in both the uplink direction and the downlink direction.
In Example 59, the request of any one of Examples 54 to 58 may optionally comprise a request to utilize the alternate SGSN to serve the set of UEs in only an uplink direction or only a downlink direction when the detection component detects the user plane congestion in only the uplink direction or only the downlink direction.
In Example 60, the request of any one of Examples 54 to 59 may optionally comprise an Iu Switch Request message including an information element indicating that user plane congestion (UPCON) mitigation is to be performed for an Iu-PS interface between the UTRAN and the SGSN.
Example 61 is a system, comprising: the RNC of any one of Examples 54 to 60; and one or more radio frequency (RF) transceivers.
Example 62 is a base station controller (BSC), comprising: a processor circuit; a detection component for execution by the processor circuit to identify Gb interface congestion with respect to an interface between a source serving general packet radio service support node (SGSN) and a global system for mobile communications (GSM)/enhanced data rates for GSM evolution (EDGE) radio access network (GERAN); and a configuration component for execution by the processor circuit to select a target SGSN for which a Gb interface to the GERAN is uncongested, select, from among mobile stations (MSs) served by the BSC, a set of MSs for which the source SGSN provides data plane connectivity to a serving gateway (S-GW), and initiate congestion mitigation comprising reassigning the set of MSs to the target SGSN for data plane connectivity to the S-GW with respect to at least one of a downlink direction and an uplink direction, while maintaining the S-GW for the set of MSs.
In Example 63, the configuration component of Example 62 may optionally be for execution by the processor circuit to: when Gb interface congestion is identified with respect to only the downlink direction, initiate congestion mitigation comprising reassigning the set of MSs to the target SGSN with respect to only the downlink direction while maintaining the source
SGSN with respect to the uplink direction; when Gb interface congestion is identified with respect to only the uplink direction, initiate congestion mitigation comprising reassigning the set of MSs to the target SGSN with respect to only the uplink direction while maintaining the source SGSN with respect to the downlink direction; and when Gb interface congestion is identified with respect to both the downlink direction and the uplink direction, initiate congestion mitigation comprising reassigning the set of MSs to the target SGSN with respect to both the uplink direction and the downlink direction.
In Example 64, the detection component of any one of Examples 62 to 63 may optionally be for execution by the processor circuit to identify the Gb interface congestion with respect to the interface between the source SGSN and the GERAN based on one or both of a comparison of a downlink traffic level of the interface with a downlink capacity of the interface and a comparison of an uplink traffic level of the interface with an uplink capacity of the interface.
In Example 65, the set of MSs of any one of Examples 62 to 64 may optionally be selected from among connected mode MSs served by the BSC.
In Example 66, the configuration component of any one of Examples 62 to 65 may optionally be for execution by the processor circuit to initiate the congestion mitigation by sending a Gb Switch Request message.
In Example 67, the detection component of any one of Examples 62 to 66 may optionally be for execution by the processor circuit to receive traffic information for the target SGSN and determine that the Gb interface from the target SGSN to the GERAN is uncongested based on the traffic information.
In Example 68, the congestion mitigation of any one of Examples 62 to 67 may optionally comprise maintaining the source SGSN for at least one MS served by the BSC.
Example 69 is a system, comprising: the BSC of any one of Examples 62 to 68; and one or more radio frequency (RF) transceivers.
Example 70 is a system, comprising: the BSC of any one of Examples 62 to 68; and one or more radio frequency (RF) antennas.
Numerous specific details have been set forth herein to provide a thorough understanding of the embodiments. It will be understood by those skilled in the art, however, that the embodiments may be practiced without these specific details. In other instances, well-known operations, components, and circuits have not been described in detail so as not to obscure the embodiments. It can be appreciated that the specific structural and functional details disclosed herein may be representative and do not necessarily limit the scope of the embodiments.
Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. These terms are not intended as synonyms for each other. For example, some embodiments may be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
Unless specifically stated otherwise, it may be appreciated that terms such as “processing,” “computing,” “calculating,” “determining,” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulates and/or transforms data represented as physical quantities (e.g., electronic) within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices. The embodiments are not limited in this context.
It should be noted that the methods described herein do not have to be executed in the order described, or in any particular order. Moreover, various activities described with respect to the methods identified herein can be executed in serial or parallel fashion.
Although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. It is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one. Combinations of the above embodiments, and other embodiments not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. Thus, the scope of various embodiments includes any other applications in which the above compositions, structures, and methods are used.
It is emphasized that the Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate preferred embodiment. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein,” respectively. Moreover, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Claims
1. An evolved node B (eNB), comprising:
- a processor circuit;
- a detection component for execution by the processor circuit to detect user plane congestion between an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN) and a serving gateway (S-GW) of an evolved packet core (EPC); and
- a configuration component for execution by the processor circuit to select a set of user equipment (UEs) served by the E-UTRAN and the S-GW and send a request to utilize an alternate S-GW of the EPC to serve the set of UEs while maintaining a current packet data network (PDN) gateway (P-GW) for the set of UEs.
2. The eNB of claim 1, the detection component for execution by the processor circuit to detect the user plane congestion in an S1-U interface between the E-UTRAN and the S-GW.
3. The eNB of claim 1, the configuration component for execution by the processor circuit to select the set of UEs from among a plurality of UEs that are in a connected mode.
4. The eNB of claim 1, the configuration component for execution by the processor circuit to select the set of UEs from among a plurality of UEs served by the eNB.
5. The eNB of claim 1, the request comprising a request to utilize the alternate S-GW to serve the set of UEs in both an uplink direction and a downlink direction when the detection component detects the user plane congestion in both the uplink direction and the downlink direction.
6. The eNB of claim 1, the request comprising a request to utilize the alternate S-GW to serve the set of UEs in only an uplink direction or only a downlink direction when the detection component detects the user plane congestion in only the uplink direction or only the downlink direction.
7. The eNB of claim 1, the request comprising a Path Switch Request message including an information element indicating that user plane congestion (UPCON) mitigation is to be performed for an S1-U interface between the E-UTRAN and the S-GW.
8. The eNB of claim 1, comprising one or more radio frequency (RF) antennas.
9. A mobility management entity (MME), comprising:
- processing circuitry; a detection component for execution by the processing circuitry to identify S1-U interface congestion with respect to an interface between a source serving gateway (S-GW) and an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN); and a configuration component for execution by the processing circuitry to select a target S-GW for which an S1-U interface to the E-UTRAN is uncongested, select, from among user equipment (UEs) served by an evolved node B (eNB) of the E-UTRAN, a set of UEs for which the source S-GW provides data plane connectivity to a packet data network (PDN) gateway (P-GW), and initiate congestion mitigation comprising reassigning the set of UEs to the target S-GW for data plane connectivity to the P-GW with respect to at least one of a downlink direction and an uplink direction, while maintaining the P-GW for the set of UEs.
10. The MME of claim 9, the configuration component for execution by the processing circuitry to:
- when S1-U interface congestion is identified with respect to only the downlink direction, initiate congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to only the downlink direction while maintaining the source S-GW with respect to the uplink direction;
- when S1-U interface congestion is identified with respect to only the uplink direction, initiate congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to only the uplink direction while maintaining the source S-GW with respect to the downlink direction; and
- when S1-U interface congestion is identified with respect to both the downlink direction and the uplink direction, initiate congestion mitigation comprising reassigning the set of UEs to the target S-GW with respect to both the uplink direction and the downlink direction.
11. The MME of claim 9, the detection component for execution by the processing circuitry to identify the S1-U interface congestion with respect to the interface between the source S-GW and the E-UTRAN based on one or both of a comparison of a downlink traffic level of the interface with a downlink capacity of the interface and a comparison of an uplink traffic level of the interface with an uplink capacity of the interface.
12. The MME of claim 9, the set of UEs selected from among connected mode UEs served by the eNB.
13. The MME of claim 9, the configuration component for execution by the processing circuitry to initiate the congestion mitigation by sending a Create Session Request message.
14. The MME of claim 9, the configuration component for execution by the processing circuitry to initiate the congestion mitigation by sending an E-UTRAN radio access bearer (E-RAB) message.
15. The MME of claim 9, the detection component for execution by the processing circuitry to receive traffic information for the target S-GW and determine that the S1-U interface from the target S-GW to the E-UTRAN is uncongested based on the traffic information.
16. The MME of claim 9, the congestion mitigation comprising maintaining the source S-GW for at least one UE served by the eNB.
17. The MME of claim 9, comprising a radio frequency (RF) transceiver and one or more RF antennas.
18. A method, comprising:
- detecting, by processing circuitry at a first serving general packet radio service support node (SGSN), user plane congestion (UPCON) with respect to one or both of an uplink direction and a downlink direction in an interface between a radio access network and the first SGSN;
- selecting a second SGSN; and
- sending a trigger message to initiate UPCON mitigation comprising reallocating user plane traffic of a set of mobile devices from the first SGSN to the second SGSN, while maintaining a current serving gateway (S-GW) to handle the user plane traffic of the set of mobile devices.
19. The method of claim 18, comprising selecting the set of mobile devices from among connected mode mobile devices in the radio access network for which user plane traffic is handled by the first SGSN.
20. The method of claim 18, comprising selecting as the second SGSN an SGSN for which an interface connection to the radio access network is uncongested.
21. The method of claim 18, the interface comprising an Iu-PS interface, the radio access network comprising a universal mobile telecommunications system (UMTS) terrestrial radio access network (UTRAN), the set of mobile devices comprising a set of user equipment (UEs) selected from among UEs served by a radio network controller (RNC) of the UTRAN.
22. The method of claim 18, the interface comprising a Gb interface, the radio access network comprising a global system for mobile communications (GSM)/enhanced data rates for GSM evolution (EDGE) radio access network (GERAN), the set of mobile devices comprising a set of mobile stations (MSs) selected from among MSs served by a base station controller (BSC) of the GERAN.
23. The method of claim 18, the UPCON mitigation comprising reallocating the user plane traffic of the set of mobile devices from the first SGSN to the second SGSN, while maintaining the current S-GW and a current packet data network (PDN) gateway (P-GW) to handle the user plane traffic of the set of mobile devices.
24. The method of claim 18, the UPCON mitigation comprising:
- when UPCON is detected with respect to only the uplink direction, reallocating uplink user plane traffic of the set of mobile devices from the first SGSN to the second SGSN, while maintaining the first SGSN to handle downlink user plane traffic of the set of mobile devices; and
- when UPCON is detected with respect to only the downlink direction, reallocating downlink user plane traffic of the set of mobile devices from the first SGSN to the second SGSN, while maintaining the first SGSN to handle uplink user plane traffic of the set of mobile devices.
25. The method of claim 18, the trigger message comprising an Iu Switch Request or a Gb Switch Request.
Type: Application
Filed: Feb 6, 2017
Publication Date: Jun 28, 2018
Applicant: Intel Corporation (Santa Clara, CA)
Inventors: Chang H SHAN (Shanghai), Muthaiah VENKATACHLAM (Beaverton, OR), Eric SIOW (Beaverton, OR), Puneet K. JAIN (Hillsboro, OR)
Application Number: 15/425,811
