Patent Application
20130242754
In the Third Generation Partnership Project (3GPP), the fourth generation (4G) cellular network includes a radio access network (e.g., referred to as a long term evolution (LTE) network) and a wireless core network (e.g., referred to as evolved packet core (EPC) network). The LTE network is often called an evolved universal terrestrial radio access network (E-UTRAN). The EPC network is an all-Internet protocol (IP) packet-switched core network that supports high-speed wireless and wireline broadband access technologies. The EPC network allows user equipment (UEs) to access various services by connecting to the LTE network, an evolved high rate packet data (eHRPD) radio access network (RAN), and/or a wireless local area network (WLAN) RAN. The EPC network is a complex system that includes a number of network nodes that communicate with each other when UEs are accessing the EPC network. An evolved packet system (EPS) is defined to include both the LTE and EPC networks. EPS seeks to improve mobile technology through higher bandwidth, better spectrum efficiency, wider coverage, enhanced security, and full interworking with other access networks.
A network outage of the EPC network may be catastrophic to a telecommunications provider. For example, if both active and redundant packet data network (PDN) gateways (PGWs) of the EPC network fail, hundreds of thousands of UEs may be disconnected from the EPC network at the same time. Such a situation may create a tsunami-like event where all of the disconnected UEs attempt to reconnect to the EPC network at the same time and create a message surge that eventually overloads a re-authentication and reauthorization device (e.g., a home subscriber server (HSS)) of the EPC network. Authentication is one of the first steps that is performed when UEs are attempting to connect to the EPC network. The connecting UEs send signaling to mobility management entities (MMEs) of the EPC network, and the MMEs, in turn, send the signaling to the HSS for authentication of the UEs. During a message surge, MMEs may be able to sustain the large amount of UEs sending authentication requests at the same time. The HSS, however, may not be able to handle the large amount of authentication requests and may become overloaded. Once the HSS is overloaded, the connecting UEs may not receive service and connected UEs may lose service.
The 4G version of the EPC network may include network nodes that require significantly less space and power requirements than second generation (2G) circuit switched network nodes. The 4G network nodes may be designed to handle millions of UEs while occupying a small amount of space. However, standardization of the 4G version of the EPC network did not consider failure scenarios, such as the example scenario presented above. Thus, the 4G version of the EPC network remains susceptible to catastrophic network failures.
The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
Systems and/or methods described herein may provide mechanisms to prevent failures in an EPC network. In one example, the systems and/or methods may provide mechanisms (e.g., data structures) that enable network nodes of the EPC network to translate or map error codes into a format that is understandable by a MME of the EPC network and/or by UEs connected to the MME.
The UE may include a radiotelephone, a personal communications system (PCS) terminal, a smart phone, a personal digital assistant (PDA), a laptop computer, a tablet computer, a desktop computer, a workstation computer, a personal computer, a landline telephone, etc. The LTE network may include a communications network that connects subscribers (e.g., the UE) to a service provider. The eNB may enable traffic to be communicated between the UE and the MME and/or the SGW.
The EPC network may include a core network architecture of the 3GPP LTE wireless communication standard. The MME may be responsible for idle mode tracking and paging procedures (e.g., including retransmissions) for the UE. The MME may be involved in a bearer activation/deactivation process (e.g., for the UE) and may choose a SGW for the UE at an initial attach and at a time of intra-LTE handover. The SGW may route and forward traffic, may act as a mobility anchor for a user plane during inter-eNB handovers, and may act as an anchor for mobility between LTE and other 3GPP technologies. The PGW may provide connectivity of the UE to external packet data networks by being a traffic exit/entry point for the UE.
The EIR may store a list of mobile devices (e.g., identified by an international mobile station equipment identity (IMEI)) that are to be monitored and/or banned from a network. The HSS may include a master user database that supports devices of an IP Multimedia Subsystem (IMS) network, that handle calls. The AAA server may perform AAA operations associated with a communication session with the UE.
In one example implementation, one or more the network nodes of the EPC network (e.g., the MME, the SGW, the PGW, the EIR, the HSS, and/or the AAA) may generate an error code that is eventually provided to the UE. For example, during a network outage, the network nodes may generate error codes that may be eventually provided to the MME. For example, the EIR and the HSS may provide error codes directly to the MME. The AAA server may provide an error code to the MME, via the PGW and the SGW. The error codes may attempt to deny connection requests from the UE and other UEs (not shown in
The network nodes interfacing with the UE and the other UEs (e.g., the eNB and the MME) may provide the error codes to the UE and the other UEs. However, due to the variety of interfaces associated with the network nodes, the error codes may not be understood by the MME and/or the UEs. In one example implementation, data structures may be provided that define how the error codes at each network node are translated or mapped so that the error codes may be understood by the MME and/or the UEs. For example, as shown in
The term “traffic,” as used herein, is intended to be broadly construed to include a frame, a datagram, a packet, or a cell; a fragment of a frame, a fragment of a datagram, a fragment of a packet, or a fragment of a cell; or another type, arrangement, or packaging of data.
The term “component,” as used herein, is intended to be broadly construed to include hardware (e.g., a processor, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a chip, a memory device (e.g., a read only memory (ROM), a random access memory (RAM), etc.), etc.) or a combination of hardware and software (e.g., a processor, microprocessor, ASIC, etc. executing software contained in a memory device).
As used herein, the terms “user” and “subscriber” are intended to be broadly interpreted to include a UE, or a user of a UE.
As further shown in
UE 210 may include a radiotelephone; a PCS terminal that may combine, for example, a cellular radiotelephone with data processing and data communications capabilities; a smart phone; a PDA that can include a radiotelephone, a pager, Internet/intranet access, etc.; a laptop computer; a tablet computer; a desktop computer; a workstation computer; a personal computer; a landline telephone; or other types of computation and communication devices. In an example implementation, UE 210 may include a device that is capable of communicating over LTE network 220, EPC network 230, and/or IMS network 240.
LTE network 220 may include a communications network that connects subscribers (e.g., UE 210) to a service provider. In one example, LTE network 220 may include a WiFi network or other access networks (e.g., an E-UTRAN or an enhanced high-rate packet data (eHRPD) network). Alternatively, or additionally, LTE network 220 may include a radio access network capable of supporting high data rate, low latency, packet optimization, large capacity and coverage, etc.
eNB 222 may include one or more computation and communication devices that receive traffic from MME 232 and/or SGW 234 and transmit that traffic to UE 210. eNB 222 may also include one or more devices that receive traffic from UE 210 and transmit that traffic to MME 232 and/or SGW 234 or to other UEs 210. eNB 222 may combine the functionalities of a base station and a radio network controller (RNC) in 2G or 3G radio access networks.
EPC network 230 may include a core network architecture of the 3GPP LTE wireless communication standard. In one example, EPC network 230 may include an all-IP packet-switched core network that supports high-speed wireless and wireline broadband access technologies. In another example, EPC network 230 may provide packet-switched voice services (e.g., which are traditionally circuit-switched) using IMS network 240.
MME 232 may include one or more computation and communication devices that may be responsible for idle mode tracking and paging procedures (e.g., including retransmissions) for UE 210. MME 232 may be involved in a bearer activation/deactivation process (e.g., for UE 210) and may choose a SGW for UE 210 at an initial attach and at a time of intra-LTE handover. MME 232 may authenticate UE 210 (e.g., via interaction with HSS 242). Non-access stratum (NAS) signaling may terminate at MME 232 and MME 232 may generate and allocate temporary identities to UEs (e.g., UE 210). MME 232 may check authorization of UE 210 to camp on a service provider's Public Land Mobile Network (PLMN) and may enforce roaming restrictions for UE 210. MME 232 may be a termination point in EPC network 230 for ciphering/integrity protection for NAS signaling and may handle security key management. MME 232 may provide a control plane function for mobility between LTE and access networks with a S3 interface terminating at MME 232. MME 232 may also terminate a S6a interface towards HSS 242 for roaming UEs.
SGW 234 may include one or more traffic transfer devices (or network devices), such as a gateway, a router, a switch, a firewall, a network interface card (NIC), a hub, a bridge, a proxy server, an optical add-drop multiplexer (OADM), or some other type of device that processes and/or transfers traffic. In one example implementation, SGW 234 may route and forward user data packets, may act as a mobility anchor for a user plane during inter-eNB handovers, and may act as an anchor for mobility between LTE and other 3GPP technologies. For idle state UEs 210, SGW 234 may terminate a downlink (DL) data path and may trigger paging when DL data arrives for UE 210. SGW 234 may manage and store contexts associated with UE 210 (e.g., parameters of an IP bearer service, network internal routing information, etc.).
PCRF 236 may include one or more computation and communication devices that may provide policy control decision and flow based charging control functionalities. PCRF 236 may provide network control regarding service data flow detection, gating, quality of service (QoS) and flow based charging, etc. PCRF 236 may determine how a certain service data flow shall be treated, and may ensure that user plane traffic mapping and treatment is in accordance with a user's subscription profile.
PGW 238 may include one or more traffic transfer devices (or network devices), such as a gateway, a router, a switch, a firewall, a NIC, a hub, a bridge, a proxy server, an OADM, or some other type of device that processes and/or transfers traffic. In one example implementation, PGW 238 may provide connectivity of UE 210 to external packet data networks by being a traffic exit/entry point for UE 210. UE 210 may simultaneously connect to more than one PGW for accessing multiple PDNs. PGW 238 may perform policy enforcement, packet filtering for each user, charging support, lawful intercept, and packet screening. PGW 238 may also act as an anchor for mobility between 3GPP and non-3GPP technologies.
IMS network 240 may include an architectural framework or network (e.g., a telecommunications network) for delivering IP multimedia services.
HSS 242 may include one or more computation and communication devices that gather, process, search, and/or provide information in a manner described herein. In one example implementation, HSS 242 may include a master user database that supports devices of IMS network 240 that handle calls. HSS 242 may include subscription-related information (e.g., subscriber profiles), and may provide information about a subscriber's location and IP information.
EIR 250 may include one or more computation and communication devices that gather, process, search, and/or provide information in a manner described herein. In one example implementation, EIR 250 may store a list of UEs 210 that are to be monitored or banned from EPC network 230. The information stored in EIR 250 may not change in real time, and may include information that prevents calls from stolen, unauthorized, or defective UEs 210. EIR 250 may receive information associated with attempts to access EPC network 230, and may store the information in a log file.
AAA server 260 may include one or more computation and communication devices that gather, process, search, and/or provide information in a manner described herein. In one example implementation, AAA server 260 may provide authentication, authorization, and accounting services for UE 210. With regard to authentication, AAA server 260 may verify an identifier (e.g., a mobile directory number (MDN), a mobile identification number (MIN), a mobile equipment identity (MEID), an IMEI, etc.) and credentials (e.g., passwords, tokens, digital certificates, etc.) associated with UE 210. With regard to authorization, AAA server 260 may grant or refuse privileges to UE 210 for accessing specific services. With regard to accounting, AAA server 260 may track consumption of network resources by UE 210.
Although
Bus 310 may permit communication among the components of device 300. Processing unit 320 may include one or more processors or microprocessors that interpret and execute instructions. In other implementations, processing unit 320 may be implemented as or include one or more ASICs, FPGAs, or the like.
Memory 330 may include a RAM or another type of dynamic storage device that stores information and instructions for execution by processing unit 320, a ROM or another type of static storage device that stores static information and instructions for the processing unit 320, and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.
Input device 340 may include a device that permits an operator to input information to device 300, such as a keyboard, a keypad, a mouse, a pen, a microphone, a touch screen display, one or more biometric mechanisms, and the like. Output device 350 may include a device that outputs information to the operator, such as a display, a speaker, etc.
Communication interface 360 may include any transceiver-like mechanism that enables device 300 to communicate with other devices and/or systems. For example, communication interface 360 may include mechanisms for communicating with other devices, such as other devices of environment 200.
As described herein, device 300 may perform certain operations in response to processing unit 320 executing software instructions contained in a computer-readable medium, such as memory 330. A computer-readable medium may be defined as a non-transitory memory device. A memory device may include memory space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory 330 from another computer-readable medium or from another device via communication interface 360. The software instructions contained in memory 330 may cause processing unit 320 to perform processes described herein. Alternatively, or additionally, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
Although
As further shown in
As shown in Table 1, data structure 420 may include a code class column, a Diameter code column, a code description column, a trigger column, and a variety of entries associated with the columns. The code class column may provide classes for the Diameter codes identified in the Diameter code column. The classes may include, for example, a permanent (P) class, a transient (T) class, a protocol (Pro) class, a success (S) class, an informational (I) class, and/or no class (N/A). The Diameter code column may include Diameter codes generated in accordance with the Diameter protocol. For example, Diameter code “5423” may indicate that a serving node is unknown to HSS 242.
The code description column may include a description associated with a Diameter code listed in the Diameter code column. For example, Diameter code “5001” may indicate (e.g., in the code description column) that a user (e.g., associated with UE 210) is unknown to HSS 242. The trigger column may include information describing why a particular Diameter code is generated. For example, the trigger column may state that HSS 242 sends Diameter code “5004” to indicate that a subscriber (e.g., associated with UE 210) is not allowed to roam within MME 232.
Although Table 1 shows example information that may be included in data structure 420, in other implementations, data structure 420 may include less information, different information, differently arranged information, or more information than depicted in Table 1.
In one example implementation, Table 1 may be replaced with or used in addition to the information provided in Table 2.
Table 2 may include a result code family column, a Diameter code column, a code description column, a trigger column, a MME error behavior column, a retry alternate HSS column, a MME sends NAS error column, and a variety of entries associated with the columns. The result code family column may provide families (e.g., 1XXX, 2XXX, etc.) for the Diameter codes identified in the Diameter code column. The Diameter code column may include Diameter codes generated in accordance with the Diameter protocol. For example, Diameter code “3002” may indicate that a Diameter routing issue has occurred.
The code description column may include a description associated with a Diameter code listed in the Diameter code column. For example, Diameter code “3005” may indicate (e.g., in the code description column) that a Diameter routing loop has been detected by HSS 242. The trigger column may include information describing why a particular Diameter code is generated. For example, the trigger column may state that HSS 242 sends Diameter code “3004” when HSS 242 is temporarily overloaded.
The MME error behavior column may include information describing MME error behavior for the Diameter codes identified in the Diameter code column. For example, MME 232 may indicate a network failure when Diameter error code “5004” is generated. The retry alternate HSS column may include an indication (e.g., Yes (Y), No (Y), etc.) of whether an alternate HSS 242 is to be retried before sending a NAS message to UE 210. The MME sends NAS error column may include information describing NAS errors sent by MME 232 for the Diameter codes identified in the Diameter code column.
Although Table 2 shows example information that may be included in data structure 420, in other implementations, data structure 420 may include less information, different information, differently arranged information, or more information than depicted in Table 2.
As further shown in
MME 232 may provide a translated EPS mobility management (EMM) error code 440 to UE 210. In one example, MME 232 may utilize a data structure 450 to translate error code 410 or error code 430 into translated EMM error code 440. Data structure 450 may include, for example, a table used to define error standards for the interface between MME 232 and UE 210. In one example implementation, data structure 450 may include the information provided in Table 3.
In one example implementation, the rows of Table 1 may align with (e.g., map to) the rows of Table 3. As shown in Table 3, data structure 450 may include a NAS EMM code column, a code description column, a trigger column, EMM message type columns (e.g., an attach reject column, a detach request column, a tracking area update (TAU) reject column, and a service reject column), a UE behavior column, and a variety of entries associated with the columns. The NAS EMM code column may provide identifiers (e.g., numbers) for NAS EMM error codes provided from MME 232 to UE 210. The code description column may include a description associated with a NAS EMM code listed in the NAS EMM code column. For example, NAS EMM code “17” may indicate (e.g., in the code description column) a network failure. The trigger column may include information describing why a particular NAS EMM code is generated. For example, the trigger column may indicate that NAS EMM code “3” is generated when MME 232 is not able to validate UE 210 based on generated keys.
The attach reject column may provide an indication (e.g., Yes, No, or not applicable (N/A)) of whether an attach rejection is associated with a NAS EMM code identified in the NAS EMM code column. The detach request column may provide an indication (e.g., Yes, No, or N/A) of whether a detach rejection is associated with a NAS EMM code identified in the NAS EMM code column. The TAU reject column may provide an indication (e.g., Yes, No, or N/A) of whether a TAU rejection is associated with a NAS EMM code identified in the NAS EMM code column. The service reject column may provide an indication (e.g., Yes, No, or N/A) of whether a service rejection is associated with a NAS EMM code identified in the NAS EMM code column. The UE behavior column may include information describing how UE 210 is behave for each NAS EMM code of the NAS EMM code column.
Although Table 3 shows example information that may be included in data structure 450, in other implementations, data structure 450 may include less information, different information, differently arranged information, or more information than depicted in Table 3.
MME 232 may provide a translated EPS session management (ESM) error code 460 to UE 210. In one example, MME 232 may utilize a data structure 470 to translate error code 410 or error code 430 into translated ESM error code 460. Data structure 470 may include, for example, a table used to define error standards for the interface between MME 232 and UE 210. In one example implementation, data structure 470 may include the information provided in Table 4.
In one example implementation, the rows of Table 4 may align with (e.g., map to) the rows of Tables 1 and/or 3. As shown in Table 4, data structure 470 may include a NAS ESM column, a code description column, a trigger column, ESM message type columns (e.g., a deactivate bearer request column, a PDN connectivity rejection column, a bearer resource allocation rejection column, a bearer resource modification rejection column, a PDN disconnect rejection column, and an ESM status column), a UE behavior column, and a variety of entries associated with the columns. The NAS ESM code column may provide identifiers (e.g., numbers) for NAS ESM error codes provided from MME 232 to UE 210. The code description column may include a description associated with a NAS ESM code listed in the NAS ESM code column. For example, NAS ESM code “33” may indicate (e.g., in the code description column) that requested service option is not subscribed to by UE 210. The trigger column may include information describing why a particular NAS ESM code is generated. For example, the trigger column may indicate that NAS ESM code “38” is generated when a database error or other failure occurs in HSS 242.
The deactivate bearer request column may provide an indication (e.g., Yes, No, or N/A) of whether a deactivate EPS bearer content request is associated with a NAS ESM code identified in the NAS ESM code column. The PDN connectivity rejection column may provide an indication (e.g., Yes, No, or N/A) of whether a PDN connectivity rejection is associated with a NAS ESM code identified in the NAS ESM code column. The bearer resource allocation rejection column may provide an indication (e.g., Yes, No, or N/A) of whether a bearer resource allocation rejection is associated with a NAS ESM code identified in the NAS ESM code column. The bearer resource modification rejection column may provide an indication (e.g., Yes, No, or N/A) of whether a bearer resource modification rejection is associated with a NAS ESM code identified in the NAS ESM code column. The PDN disconnect rejection column may provide an indication (e.g., Yes, No, or N/A) of whether a PDN disconnect rejection is associated with a NAS ESM code identified in the NAS ESM code column. The ESM status column may provide an indication (e.g., Yes, No, N/A) of whether an ESM status is associated with a NAS ESM code identified in the NAS ESM code column. The UE behavior column may include information describing how UE 210 is behave for each NAS ESM code of the NAS ESM code column.
Although Table 4 shows example information that may be included in data structure 470, in other implementations, data structure 470 may include less information, different information, differently arranged information, or more information than depicted in Table 4.
Although
As further shown in
As shown in Table 5, data structure 520 may include a code type column, a general packet radio service (GPRS) tunneling protocol (GTP) code column, a code description column, a trigger column, and a variety of entries associated with the columns. The code type column may provide classes for the GTP codes identified in the GTP code column. The types may include, for example, a permanent (P) type, a transient (T) type, a protocol (Pro) type, a success (S) type, an informational (I) type, and/or no type (N/A). The GTP code column may include GTP codes generated in accordance with the GPRS tunneling protocol. For example, GTP code “69” may indicate that a mandatory information element (IE) is received with an incorrect value.
The code description column may include a description associated with a GTP code listed in the GTP code column. For example, GTP code “83” may indicate (e.g., in the code description column) that a preferred PDN type is not supported. The trigger column may include information describing why a particular GTP code is generated. For example, GTP code “84” may indicate (e.g., in the trigger column) that a temporary resource issue has occurred and an IP address cannot be assigned to UE 210.
Although Table 5 shows example information that may be included in data structure 520, in other implementations, data structure 520 may include less information, different information, differently arranged information, or more information than depicted in Table 5.
MME 232 may provide a translated ESM error code 540 to UE 210. In one example, MME 232 may utilize a data structure 550 to translate error code 510 or error code 530 into translated ESM error code 540. Data structure 550 may include, for example, a table used to define error standards for the interface between MME 232 and UE 210. In one example implementation, data structure 550 may include the information provided in Table 6.
In one example implementation, the rows of Table 6 may align with (e.g., map to) the rows of Table 5. As shown in Table 6, data structure 550 may include a NAS ESM code column, a code description column, a trigger column, ESM message type columns (e.g., a deactivate bearer request column, a PDN connectivity rejection column, a bearer resource allocation rejection column, a bearer resource modification rejection column, a PDN disconnect rejection column, and an ESM status column), a UE behavior column, and a variety of entries associated with the columns. The NAS ESM code column may provide identifiers (e.g., numbers) for NAS ESM error codes provided from MME 232 to UE 210. The code description column may include a description associated with a NAS ESM code listed in the NAS ESM code column. For example, NAS ESM code “26” may indicate (e.g., in the code description column) that there are insufficient resources for UE 210. The trigger column may include information describing why a particular NAS ESM code is generated. For example, the trigger column may indicate that NAS ESM code “44” is generated when there semantic errors in packet filter(s).
The deactivate bearer request column may provide an indication (e.g., Yes, No, or N/A) of whether a deactivate EPS bearer content request is associated with a NAS ESM code identified in the NAS ESM code column. The PDN connectivity rejection column may provide an indication (e.g., Yes, No, or N/A) of whether a PDN connectivity rejection is associated with a NAS ESM code identified in the NAS ESM code column. The bearer resource allocation rejection column may provide an indication (e.g., Yes, No, or N/A) of whether a bearer resource allocation rejection is associated with a NAS ESM code identified in the NAS ESM code column. The bearer resource modification rejection column may provide an indication (e.g., Yes, No, or N/A) of whether a bearer resource modification rejection is associated with a NAS ESM code identified in the NAS ESM code column. The PDN disconnect rejection column may provide an indication (e.g., Yes, No, or N/A) of whether a PDN disconnect rejection is associated with a NAS ESM code identified in the NAS ESM code column. The ESM status column may provide an indication (e.g., Yes, No, N/A) of whether an ESM status is associated with a NAS ESM code identified in the NAS ESM code column. The UE behavior column may include information describing how UE 210 is behave for each NAS ESM code of the NAS ESM code column.
Although Table 6 shows example information that may be included in data structure 550, in other implementations, data structure 550 may include less information, different information, differently arranged information, or more information than depicted in Table 6.
Although
As further shown in
As shown in Table 7, data structure 620 may include a result code family column, a Diameter code column, a code description column, a trigger column, a PGW error behavior column, a PGW retry behavior column, and a variety of entries associated with the columns. The result code family column may provide families (e.g., 1XXX, 2XXX, etc.) for the Diameter codes identified in the Diameter code column. The Diameter code column may include Diameter codes generated in accordance with the Diameter protocol. For example, Diameter code “5002” may indicate that a requested session identifier could not be found in AAA 260.
The code description column may include a description associated with a Diameter code listed in the Diameter code column. For example, Diameter code “5011” may indicate (e.g., in the code description column) that an incorrect Diameter version is being used. The trigger column may include information describing why a particular Diameter code is generated. For example, the trigger column may state that AAA 260 sends Diameter code “5006” when resources associated with AAA 260 are exceeded and a request will not be processed.
The PGW error behavior column may include information describing PGW 238 error behavior for the Diameter codes identified in the Diameter code column. For example, MME 232 may terminate a request when Diameter error code “5004” is generated. The PGW retry behavior column may include an indication (e.g., Retry or No Retry) of whether PGW 238 will retry a request.
Although Table 7 shows example information that may be included in data structure 620, in other implementations, data structure 620 may include less information, different information, differently arranged information, or more information than depicted in Table 7.
Although
As shown in
As further shown in
Process block 730 may include the process blocks depicted in
The attach reject column may provide an indication of whether an attach rejection is associated with a NAS EMM code identified in the NAS EMM code column. The detach request column may provide an indication of whether a detach rejection is associated with a NAS EMM code identified in the NAS EMM code column. The TAU reject column may provide an indication of whether a TAU rejection is associated with a NAS EMM code identified in the NAS EMM code column. The service reject column may provide an indication of whether a service rejection is associated with a NAS EMM code identified in the NAS EMM code column. The UE behavior column may include information describing how UE 210 is behave for each NAS ESM code of the NAS EMM code column.
Systems and/or methods described herein may provide mechanisms to prevent failures in an EPC network. In one example, the systems and/or methods may provide mechanisms (e.g., data structures) that enable network nodes of the EPC network to translate or map error codes into a format that is understandable by a MME of the EPC network and/or by UEs connected to the MME.
The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the implementations.
For example, while series of blocks have been described with regard to
It will be apparent that different aspects of the description provided above may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects is not limiting of the invention. Thus, the operation and behavior of these aspects were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement these aspects based on the description herein.
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one other claim, the disclosure of the invention includes each dependent claim in combination with every other claim in the claim set.
No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items and may be used interchangeably with ‘one or more. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
This application is a continuation-in-part of U.S. patent application Ser. No. 13/432,324, filed Mar. 28, 2012, which claims priority, under 35 U.S.C. §119, to U.S. Provisional Patent Application Ser. No. 61/610,304, filed Mar. 13, 2012. The entire contents of U.S. patent application Ser. No. 13/432,324 and U.S. Provisional Patent Application Ser. No. 61/610,304 are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61610304 | Mar 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13432324 | Mar 2012 | US |
| Child | 13724288 | US |
