WO2016114773A1

WO2016114773A1 - Dedicated core network formation for cellular networks

Info

Publication number: WO2016114773A1
Application number: PCT/US2015/011399
Authority: WO
Inventors: Joydeep Acharya; Salam Akoum
Original assignee: Hitachi, Ltd.
Priority date: 2015-01-14
Filing date: 2015-01-14
Publication date: 2016-07-21

Abstract

Example implementations of the present disclosure are directed to an Evolved Packet Core (EPC) Control Module by which a cellular operator decides how and when to form new core networks, each dedicated to a specific type(s) of User Equipment (UEs). Example implementations can divide the mobility management entity (MME) of the original EPC into potentially two MMEs, one each for Human to Human (H2H) and Machine Type (MTC) UEs, based on the signal load reduction for MTC UEs. Example implementations can also divide the core network user plane bandwidth into separate user planes, based on the number of UEs in different access class for H2H and MTC UEs.

Description

DEDICATED CORE NETWORK FORMATION FOR CELLULAR NETWORKS

[0001] The present disclosure is generally directed to wireless networks, and more specifically, to dedicated core network formation for cellular networks.

Related art

[0002] In the related art, the core network (CM) of a Long Term Evolution (LTE) system are initially designed for a moderately large number of human- to-human (H2H) User Equipment (UEs) with fairly similar control and user plane characteristics and also received quality of service from the operator. The advent of the LTE machine type (MTC) communications introduces a very large number of UEs performing machine to machine (M2.M) communications connecting to the core network. These UEs have very different control and data plane characteristics than human-to-human UEs and thus bring a heterogeneity which the core network may be ill-equipped to handle. Another degree of heterogeneity occurs as UEs can obtain premium quality of service for a higher payment. Such implementations are being increasingly facilitated by service providers looking to boosSt their revenues. The UEs with different access class (premium vs non-premium UEs) may have different policies for their user plane transmissions.

[0003] One solution to these problems in the related art is to design separate core networks for UEs whose control and data plane characteristics are very dissimilar.

SUMMARY

[0004] In the present disclosure, example implementations are directed to solutions by which a service provider can decide when and how to split the original cellular core network resources into new smaller core networks, each dedicated to a specific type(s) of UEs. The example implementations facilitate when and how cellular operators can form dedicated core networks to serve the human and machine subscribers and thus may improve overall efficiency and reliability of the network.

\ [0005] Aspects of the present disclosure include a management computer configured to control an evolved packet core (EPC). The management computer may include a memory configured to store user equipment (UE) information regarding one or more UEs associated with the EPC, the UE information including a status indicating each of the one or more UEs as an Long Term Evolution (LTE) machine type (MTC) or a human to human (H2H) UE, where a 1ί21ί UE involves a human who is transmitting or receiving an LTE signal on the LTE enabled device, and a service class level for each of the one or more UE classified as an H2H UE, and a processor, configured to allocate one or more mobility management entities (MMEs) to the EPC based on the stored UE information. The allocation of the one or more MMEs may involve at least one of allocating an MME of the one or more MMEs to serve MIC and H2H UEs; and allocating a first MME of the one or more MMEs to serve the MTC UEs, and a second MME of the one or more MMEs to serve the H2H UEs, the second MME being separate from the first MME.

[0006] Additional aspects of the present disclosure may further include a method for controlling an evolved packet core (EPC^"), which can include managing user equipment (UE) information regarding one or more UEs associated with the EPC, the UE information including a status indicating each of the one or more UEs as an Long Term Evolution (LTE) machine type (MTC) or a human to human (11211) UE, and a service class level for each of the one or more UE classified as an II2H UE; allocating one or more mobility management entities (MMEs) to the EPC based on the stored UE information. The allocation of the one or more MMEs may include least one of allocating an MME of the one or more MMEs to serve MTC and H2H UEs; and allocating a first MME of the one or more MMEs to serve the MTC UEs, and a second MME of the one or more MMEs to serve the H2H UEs, the second MME being separate from the first MME,

[0007] Additional aspects of the present disclosure may further include a computer program for controlling an evolved packet core (EPC), which can include managing user equipment (UE) information regarding one or more UEs associated with the EPC, the UE information including a status indicating each of the one or more UEs as an Long Term Evolution (LTE) machine type (MTC) or a human to human (H2H) UE, and a service class level for each of the one or more UE classified as an H2H UE; allocating one or more mobility management entities (MMEs) to the EPC based on the stored UE information. The allocation of the one or more MMEs may include least one of allocating an MME of the one or more MMEs to serve MTC and H2H UEs; and allocating a first MME of the one or more MMEs to serve the MTC UEs, and a second MME of the one or more MMEs to serve the H2H UEs, the second MME being separate from the first MME. The computer program may be stored on a medium such as a non- transitory computer readable medium and executed by one or more processors.

BRIEF DESCRIPTION OF DRAWINGS

[0008] FIG. 1 illustrates an LTE network architecture, in accordance with an example impleme ation.

[0009] FIG. 2 illustrates an example of realizing different components of the EPC via network function virtualization (NFV), in accordance with an example implementation.

[0010] FIG. 3 illustrates a high level diagram of an EPC creation module, in accordance with an example implementation.

[0011] FIG. 4 illustrates an example of the EPC controller module, in accordance with an example implementation.

[0012] FIG. 5 illustrates a flow diagram for the MME controller sub-module of the EPC Controller module, in accordance with an example implementation.

[0013] FIG. 6 illustrates a flow diagram for the user plane controller sub-module of the EPC Controller Module, in accordance with an example implementation.

[0014] FIG. 7 illustrates a logical module for a EPC hardware configuration, in accordance with an example implementation.

[0015] FIG, 8 illustrates an example virtualization of one network over the available physical hardware, in accordance with an example implementation/

[0016] FIG. 9 illustrates an example virtuali zation over two logical networks over the available physical hardware, in accordance with an example implementation.

[0017] FIG. 10 illustrates an example apparatus implementation for a core network, in accordance with an example implementation. [0018] FIG. 11 illustrates an example base station upon which example implementations can be implemented.

[0019] FIG. 12 illustrates an example user equipment upon which example implemen ations can be implemented.

[0020] FIG. 13 illustrates an example architecture of the system, in accordance with an example implementation.

DETAILED DESCRIPTION

[0021] The following detailed description provides further details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. The terms enhanced node B (eNodeB), small cell (SC), base station (BS) and pico cell may be utilized interchangeably throughout the example implementations. The terms traffic and data may also be utilized interchangeably throughout the example implementations. The implementations described herein are also not intended to be limiting, and can be implemented in various ways, depending on the desired implementation.

[0022] FIG. 1 illustrates an LTE network architecture, in accordance with an example implementation. The system may include a CN 100, having a mobility management entity (MME) 101, a Home Subscriber Server (HSS) 102, a serving gateway (S-GW) 103, and a Packet Data Network (PDN) Gateway 104. The MME 101 is configured to facilitate bearer/UE attachment procedures. The HSS 102 may contain a database of subscriber UEs including tier information. The S-GW 103 routes and forwards user data packets, and may also function as a mobility anchor for the user plane during handovers. The P-GW 104 is configured to conduct policy enforcement, packet filtering for each user, and packet screening functions. The Radio Access Network (RAN) may include one or more associated base stations 1 10, each having a cell to serve one or more UEs 120. In an exampie configuration, connections between the CN 100 and the external IP network 130 may be facilitate by an external bearer. In an exampie configuration, connections between the CN .100 to the RAN may be facilitated by an SI bearer between the S-GW 103 and the associated base stations 110.

[0023] In the example of FIG. 1 for the core network 100, the MME 101 is the basic logical entity that handles all the control plane functionalities such as session management, authentication and security, mobility management and IDLE to CONNECTED mode transition management. In the user plane, the main nodes that handle the user plane Internet Protocol (IP) data traffic are the P-GW 104 and S-GW 103. These form an interconnected network of routers that link the UEs 120 to the eNodeB 1 10, to the S-GW, to the P-GW and through the P-GW, to the external IP network such as the internet.

[0024] The capacity of the Evolved Packet Core (EPC) (e.g. in terms of number of UEs and UE messages served per unit time) may be limited due to the following factors. For the control plane, there may be a limit on the memory (determines the number of EEs ATTACHED simultaneously, number of evolved packet system bearers) and the central processing unit (CPU) speed (e.g. number of messages that can be processed per second by the MME). For the user plane, there ma be an issue with the bandwidth in the Core Network, i.e. the capacity of the optical fiber lines connecting the routers from the P-GW, to the S-GW to the eNobdeB.

[0025] FIG. 2 illustrates an example of realizing different components of the EPC via network function visualization (NFV), in accordance with an exampie implementation. Such an implementation can allow operators to virtualize different EPC components such as MME and S-GW/P-GW over general purpose physical hardware 200 such as servers, switches and routers. As illustrated in FIG. 2, each virtual network (e.g. Networks A and B) have their individual software logic 203-1, 203-2 (e.g. function as instruction sets of the network software), the network operating software (OS) 202-1, 202-2, and an entity called the hvpervisor 201 that loads a particular network OS to a part of the physical hardware. Resources such as memory and computing power can be dynamically allocated to the different networks via NFV. In example implementations of the present disclosure, NFV can be utilized to implement the dedicated core networks to be formed. [0026] FIG. 3 illustrates a high level diagram of an EPC creation module, in accordance with an example implementation. Initially the cellular operator has a single EPC. At the flow at 310, the original EPC 300 communicates to the EPC Controller Module 301 about information regarding the number and types of UEs already connected to the EPC. Such information can be related to the MTC and H2H UEs (e.g., numbers, numbers of service classes for H-2-H UEs etc.). Based on this information, at the flow of 320, the EPC Controller Module 301 sends instructions to the EPC 300 and subsequently in the flow of 330, the EPC reeonfigurabie module 302 may split the original EPC 300 into separate, component EPCs 303-1, 303-2, each dedicated to serving a specific type(s) of UEs.

[0027] FIG. 4 illustrates an example of the EPC controller module, in accordance with an example implementation. The EPC Controller Module 301 decides about the control and user plane separately. The MME Controller Sub-module 400 of the EPC Controller Module 301 decides on the formation of new MMEs while the User Plane Controller Sub- module 401 of the EPC Controller Module 301 decides on the formation of new S-GWs and P-GWs and divides the original user plane bandwidths between these newly created user plane entities.

[0028] In example implementations, the MME Controller Sub-Module 400 decides either to keep the original single MME for serving both H2H and MTC UEs or decides to split the MME into two individual MMEs (e.g., one each for H2H and MTC UEs). The basic idea is that if the MME only has to serve MTC UEs, then the number of messages for which the MME software has to be designed can be reduced. The MME architecture can be designed with a reduced instruction set and hence simplified. For example the MME. instruction set can omit operations relating to tracking area updates and mobility management that would have to be included for H2H UEs when assuming that most of the MTC UEs are stationary. Further, a more predictable and programmable IDLE to CONNECTED mode transitions may happen which can reduce the MME design complexity. The exact savings in forming a dedicated MME for MTC depends both on the number of operations that can be reduced in the instruction set and also on the number of MTC and H2H UEs.

[0029] Therefore, reduction in MME design complexity may be achieved when it is known apriori that only MTC UEs will be served based upon parameters such as relative number of MTC UEs and the relative size of the instruction set for MTC UEs where both the relative measures are with respect to the H2H UEs in the system.

[0030] FIG. 5 illustrates a flow diagram for the MME Controller Sub-module 400 of the EPC Controller module 301 , in accordance with an example implementation. In more detail, FIG. 5 illustrates the flow for when a MME should be split into two MMEs to achieve a reduction in design complexity.

[0031] First the MME Controller sub-module 400 determines the number of MTC^" and H- 2-H UEs, denoted by n_M and n_H respectively as shown at 500 and 501 . MME Controller sub-module 400 then determines the number of instructions/unit of time (e.g., seconds) needed to be processed for MTC and H2H UEs, denoted by L_M and L_H respectively as illustrated at 502 and 503. In example implementations, it is assumed that L_H > L_M and that the LH instructions for 11211 already co tain all the L_M instructions for MTC.

[0032] At 504, the MME Controller sub-module 400 now has to decide whether to keep a single MME for serving both kinds of UEs or form two MMEs one each for H2H and MTC UEs by performing calculations. If there was a single MME in the system, then its instruction set has to be designed for LH instructions/unit of time and thus the total signaling load would be Ιχ - L_H (n_M + n_H). However, if there were two MMEs formed, one each for MTC and H-2-H UEs, then the total signaling load per unit of time is given by I₂

[00331 At 505, the MME Controller sub -module 400 checks to see if the ratio of over lj is less a threshold Th (which indicates savings in having two MMEs) to decide whether to have a single MME or split it in two. If so (YES) then two MMEs are formed at 506 for the MTC UEs and the human UEs respectively. Otherwise (NO), the flow proceeds to 507 and a single MME is maintained. The threshold Th may be a predetermined value preset by the operator based on the desired implementation and requisite savings desired by the operator.

[0034] FIG. 6 illustrates a flow diagram for the user plane controller sub-module 401 of the EPC Controller Module 301, in accordance with an example implementation. The flow diagram illustrates an example implementation to first separate the MTC UEs and then the H2H UEs based on their service classes. Initially the MTC UEs and the H2H UEs with the lowest service ciass are lumped in one category and the other H-2-H UEs have their own individual categories. The proposed flow diagram also checks if the UEs belonging to a specific category fall below a minimum threshold and if so combines those UEs with the next higher category. User plane bandwidth is partitioned by the user plane controller sub- module 401 over the categories that are formed through the use of the flow diagram.

[0035] At 600, the user plane controller sub-module 401 determines one or more parameters, such as the set of MTC UEs (SM), and the number of MTC UEs nM = I S !· For example, let the set of MTC UEs be SM = {mi, m₂, . . . ,m5o] such that n_M - 50.

[0036] At 601 , the user plane controller sub-module 401 determines the set of H2H UEs belonging to N service classes S_H(0)_;...,S_H( -1), the number of H2H UEs belonging to the N service classes n_H(0),...,n_H(N-l), the total number of H2H UEs belonging to the N service classes n_H(k) - j S_H(k) j , n_H(0) + ... + n_H(N-l)=n_H, and the total number of UEs of all types n_T = r½ + n_H. For example, let there be three service classes for H2H UEs such that N = 3. The classes are numbered class 0, 1, and 2 and correspond to normal, gold and platinum users. Let the set of UEs in service ciass 0 be SH(0) = {¾i, uo.2,-., uo.io} such that nn(0) = 10. Let the set of UEs in service class 1 be SH(1) = {ui.i, u..?,.., j.s } such that n_H(l ) = 5. Let the set of UEs in service class 2 be SH(2) = {u₂,i , u¾2, U2.3 } such that HH(2) = 3.

[0037] At 602, the user plane controller sub-module 401 defines the following UE sets S₀: S_M U S_H(0) and n₀- j S₀ i and S|,_:: S_H(k) and n_k = j S_k j wherein l<k≤N-l. For example, define the set, So = SM U SH(0) = { mi, ηι₂, . . . ,ηΐ5₀, uo,i_» ¾_!ο } such that n₀ = 60. Define the set Si = SH(1) = {ui,i, uu,.., 111,5 } such that m = 5. Define the set 82 = SH(2) = {112,1. u₂,₂, u_2>3 ] such that n2 = 3. The total number of UEs is given by nT = nM + nH = 50 + 10 + 5 + 3 = 68.

[0038] At 603, the user plane controller sub-module 401 sets parameters to define the loop with k=0 and m=0. For example, set the parameters such that k = 0 and p = 0.5. At 604, the user plane controller sub-module 401 makes a determination if n_k/n_T <p. If so (YES), then the flow proceeds to 605 to compare the counter k to the number of service classes N, otherwise (NO), the flow proceeds to 606 to increment the counter M. In the example provided above, initially nO/nT = 60/68 = 0.88 > p and hence no change is made to set So- [0039] At 605, a check is performed to determine if k = N- l . If so (YES) then the flow proceeds to 61 1, otherwise (NO) the flow proceeds to 610.

[0040] At 610, the user plane controller sub-module 401 defines new UE sets S_k = U S^₊i and S_n = S_n+i, k+l≤n≤N-2. The flow proceeds to 607 to decrement N=N-1 and proceeds to 604.

[0041] At 608 a check is performed to determine if k = N-l . If so (YES), then the counter k is incremented and the flow returns to 604. Otherwise (NO), the flow proceeds to 611 .

[0042] At 611 , the user plane controller sub-module allocates the bandwidth for the UE set such that S_m, 0<m<M-l as = (a_mIS_mi/nT)B.

[0043] In the example provided above, now k - 1. At 604, nl/nT - 5/68 = 0.07 < p and proceeds to 605 wherein k≠ N-l = 2. Hence at 610, define new set SI = SI U S2 = {u_¾j , i,2,.., Ui„ u₂,! , u_2i2, U2 } such that new value of nl = 8. Now set N = N - 1 = 2 at 607. In the above example, the value of k - 1 ., n l/nT - 8/68 = 0.11 < p but k = N - 1 = 1. Hence the UE set formation part of the algorithm stops.

[0044] Thus in the above example, there are two partitions of the user plane. One for the set So = { mi, m₂, ... ,11150, U0.1, Uo,?,,.., u₀,!o ] covering the lowest priority H2H UEs and the MTC UEs and another set SI = {ui,i, Uj _i2,.-, uu, ¾,· , u₂,₂, 112,3 } covering all the other UEs. Now the total core network bandwidth B has to be divided between the two sets So and Si . In example implementations, this is done in proportion to the number of UEs in the two sets with a bias factor a. For this example, total number of UEs, n_T = 68, ISo! = 60 and ISii = 8. Thus the bandwidth for set S₀ is α₀*(60/Ί68)*Β and that for set 8, is ai *(6Q/168)*B where value of <¾ can be chosen higher than that of oo to give more bandwidth to the set of UEs in the higher service classes.

[0045] FIG. 7 illustrates a logical module for a EPC hardware configuration, in accordance with an example implementation. In the hardware configuration, there is a storage unit 700 which is utilized for storing various information about all attached UEs and their active connections. This is controlled by microprocessors or a server 701 that runs that various commands in the instruction set of the EPC. There is also an interface module 702 by which the EPC connects to other network components such as the RAN and other EPCs or 3G network nodes. [0046] FIG, 8 illustrates an example virtu alization of one network over the available physical hardware, in accordance with an example implementation. Specifically, FIG, 8 illustrates an example as to how the EPC Controller Module in FIG. 4 with the various submodules (MME Controller Sub-Module of FIG. 5 and User Plane Controller Sub- Module of FIG. 6) can be implemented. In the example of FIG. 8, the networks are virtualized over physical hardware using network function virtualization (NFV) as explained in FIG. 2. In FIG. 8, the example virtualization of one network 800 over all available physical hardware is shown. The MME units can be servers with finite computing and memory and the S-GW/P-GW units can be fiber leased lines. The MME units and S-GW/P-GW units can be incorporated into a pool and allocated either physically or virtually. An example of the physical architecture of the system is provided in FIG. 13.

[0047] FIG. 9 illustrates an example virtualization over two logical networks over the available physical hardware, in accordance with an example implementation. By using NFV, example implementations can virtualize two logical networks (A and B) over the same set of physical hardware. As described in FIG. 8, the MME units and S-GW/P-GW units can be incorporated into a pool and allocated either physically or virtually to each of the networks. In the example of FIG. 9, by using NFV, two logical networks (A and B) are virtualized over the same set of physical hardware.

[0048] FIG. 10 illustrates an example apparatus implementation for a core network, in accordance with an example implementation. The apparatus implementation may be in the form of a MME, or a device configured to perform the functions of the core network 100, or a combination of devices thereof, and implemented in the form of a server or computer depending on the desired implementation. The apparatus 1000 may include a CPU 1001, a memory 1002 and a RAN interface 1003. The CPU 1001 may invoke one or more functions that facilitate the apparatus to perform the functions of the core network as illustrated in FIG I. The memory 1002 may be configured to store information to manage functionality as a target support node apparatus and a source support node apparatus.

[0049] CPU 1001 may include one or more functions such as UE ID manager 1001-1,

Mobility Management 1001-2 and Offload Function 1001 -3. UE ID manager 1001-1 may be configured to refer to Subscriber Database 1002-3 in the memory 1002 to manage UEs that are associated with the apparatus 1000. Mobility Management 1001-2 may utilize RAN interface 1003 to communicate with the RAN and associated base station to process the receiving or transferring of UEs. Offload function 1001-3 may be configured to adjust the apparatus 1000 to handle MTC UEs, H2H UEs or both for the RAN and can refer to subscriber database 1002-3 to determine UEs to be handled, wherein UE Management 1002-2 is updated with the UEs to be associated with the apparatus 1000. Subscriber database 1002-3 may also include information such as service class level of the UEs, and the status indicating associated UEs as an MTC UE or a H2H UE.

[0050] Memory 1002 may manage information such as RAN management 1002-1 , UE Management 1002-2, and subscriber database 1002-3. RAN management may indicate a list of RANs that is managed by the apparatus 1000. UE Management 1002-2 can include information for the UEs managed by the apparatus 1000, such as the status indicating associated UEs as an MTC or a H2H UE, and a service class level for the associated UEs classified as an H2H UE. Subscriber database 1002-3 may include UE service class information.

[0051 ] FIG. 11 illustrates an example base station upon which example implementations can be implemented. The block diagram of a base station 1100 in the RAN of the example implementations is shown in FIG. 11, which could be a macro base station, a pico base station, an eNodeB and so forth. The base station 1100 may include the following modules: the Central Processing Unit (CPU) 1101 , the baseband processor 1102, the transmission/receiving (Tx/ x) array 1103, the X2/Xn interface 1104, and the memory 1105. The CPU 1101 is configured to process information regarding changes to the EPC and networks from the apparatus 1000, and adjust communications accordingly. Further, CPU 1 101 may receive such information regarding other base stations from other base stations through the X2/Xn interface 1104, or may receive it from apparatus 1000. The baseband processor 1102 generates baseband signaling including the reference signal and the system information such as the cell-ID information. The Tx/Rx array 1 103 contains an array of antennas which are configured to facilitate communications with associated UEs. The antennas may be grouped arbitrarily to form one or more active antenna ports. Associated UEs may communicate with the Tx/Rx array to transmit signals containing congestion information, flow traffic information, and so forth. The X2/Xn interface 1104 is used to exchange traffic and interference information between one or more base stations and/or the apparatus of FIG. 10 via a backhaul to transmit instructions for processing changes to the EPC as described above. The memory 1105 can be configured to store and manage traffic information, traffic load, and so forth. Memory 1105 may take the form of a computer readable storage medium or can be replaced with a computer readable signal medium as described below. Memory 1105 may also store information indicative of a resource requirement for each UE associated with the base station.

[0052] FIG. 12 illustrates an example user equipment upon which example implementations can be implemented. The UE 1200 may involve the following modules: the CPU module 1201 , the Tx/Rx array 1202, the baseband processor 1203, and the memory 1204. The CPU module 1201 can be configured to provide information regarding the service class level and/or the status as a MT'C UE or a H2H UE to the RAN or to the EPC. The Tx/RX array 1202 may be implemented as an array of one or more antennas to communicate with the one or more base stations. The memory 1204 can be configured to store the service class level information or the status as a MT CUE or a H2H UE. The baseband digital signal processing (DSP) module 1203 can be configured to perform one or more functions, such as to conduct measurements to generate the position reference signal for the serving base station to estimate the location of the UE.

[0053] FIG. 13 illustrates an example ai'chitecture of the system, in accordance with an example impleme ation. As illustrated in FIG. 13, a management computer 1300 may manage a pool of apparatuses 1000 from FIG. 10, which may have associated storage systems 1301 depending on the desired implementation as shown in FIG. 7. The pool may be represented physically to implement the MMEs, P-GW and S-GWs of the EPC, or can be represented as a virtual pool depending on the desired implementation. The management computer 1300, storage systems 1301 and apparatuses 1000 may communicate with each other over network 1302.

[0054] Management computer 1300 may include a memory 1300-1, a central processing unit (CPU) 1300-2, storage 1300-3 and Network interface (I/F) 1300-4. Storage 1300-3 may be utilized to manage one or more computer programs, which can be loaded into memory 1300-1 and executed by CPU 1300-2 to manage and control the EPC. For example, the CPU 1300-2 may perform performs the functions of EPC Controller Module

301 as described in FIG. 3 and create EPCs through performing the functions of EPC

Reconfigurable Module 302. CPU 1300-2 may execute computer programs to facilitate the functionality of the flow diagrams as described herein, for example, in FIG. 5 and FIG. 6. [0055] Memory 1300-1 may also be configured to store UE information regarding one or more IJEs associated with the EPC, which can include the a status indicating each of the UEs as an MTC UE or a H2H UE, along with the corresponding service class levels for the H2H UEs, along with predetermined thresholds to facilitate the functionalities of the flow diagrams described herein to determine the MME allocation. CPU 1300-2 may allocate MMEs to the EPC based on the stored information in memory 1300-1 , and can allocate an MME of the one or more MMEs provided by the pool of appai'atuses 1000 to serve MTC and H2H UEs; and/or allocate a MME of the one or more MMEs provided by the pool of apparatuses 1000 to serve the MTC UEs, and a separate MME to serve the H2H UEs. Management computer 1300 may manage the pool for the functionalities of MMEs, S-GWs, and P-GWs virtually or physically, depending on the desired implementation. CPU 1300-2 may also be configured to perform calculations as needed to facilitate the estimation of the instructions per unit of time utilized to serve MTC UEs and II2II UEs as described in the flow diagrams herein.

[0056] CPU 1300-2 may also group UEs into partitions and allocate user plane bandwidth to each of the partitions formed based on service class level as illustrated in the flow diagram of FIG. 6. This can include determining one or more sets of the H2H UEs for each of the MMEs allocated in the system, and allocate user plane bandwidth to each of the one or more sets based on the service class level for each of the one or more sets of the H2H UEs.

[0057] One or more storage systems 1301 may be associated with one or more appai'atuses 1000 to facilitate the functionality of the MME, S-GW, and/or the P-GW depending on the desired implementation and are provided as a physical or virtual pool depending on the desired implementation. Storage system 1301 may include memory 1301 - 1, CPU 1301-2, network I/F 1301-3, a cache memory 1301-5, and one or more storage devices 1301-4 (disks). The memory 1301 -1 , the CPU 1301-2, and the cache memory 1301 -5 can be included in a storage controller. The memory 1301-1 may store programs of storage function, and the CPU 1301-2 performs operations or instructions associated with the programs stored in the memory to utilize the storage function. The Netw301k I F 110-3 is configured to interact with the network 1302 to interact with one or more apparatuses 1000 and/or other storage systems to facilitate the functionality for the apparatuses 1000 to function as a MMF,, P-GW and/or S-GW as needed. [0058] Finally, some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

[0059] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing," "computing," "calculating,'^'' "determining," "displaying," or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.

[00601 Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readabie signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0061] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps, in addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0062] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine -readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

[0063] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.

Claims

CLAIMS What is claimed is:

1. A management computer configured to control an evolved packet core (EPC), the management computer comprising: a memory configured to store user equipment (UE) information regarding one or more UEs associated with the EPC, the UE information comprising a status indicating each of the one or more UEs as an Long Term Evolution (LTE) machine type (MTC) or a human to human (Ή2ΤΙ) UE, and a service class level for each of the one or more UE classified as an H2H UE, and a processor, configured to: allocate one or more mobility management entities (MMEs) to the EPC based on the stored UE information, the allocation of the one or more MMEs comprising at least one of: allocating an MME of the one or more MMEs to serve MTC and H2H UEs; and allocating a first MME of the one or more MMEs to serve the MTC UEs, and a second MME of the one or more MMEs to serve the H2H UEs, the second MME being separate from the first MME.

2. The management computer of claim 1, wherein the processor is further configured to determine one or more sets of the H2H UEs for each of the allocated one or more MMEs, and allocate user plane bandwidth to each of the one or more sets based on the service class level for each of the one or more sets of the H2H UEs.

3. The management computer of claim 1, wherein the processor is further configured to determine whether to allocate the first MME of the one or more MMEs to serve the MTC UEs, and the second MME of the one or more MMEs to serve the H2H UEs based on a comparison of instructions per unit of time utilized to serve the MTC UEs and the H2H UEs.

4. The management computer of claim 1, wherein the processor is further configured to change from the allocation of the MME of the one or more MMEs to serve the MTC UEs and H2H UEs to the allocation of the first MME of the one or more MMEs to serve the MTC UEs, and the second MME of the one or more MMEs to serve H2H UEs based on a ratio of instructions per unit of time utilized to serve the MTC UEs and the H2H UEs for when the second MME is allocated, falling below a predetermined threshold.

5. The management computer of claim 1, wherein the processor is configured to allocate one or more mobility management entities (MMEs) to the EPC either virtually or physically from a pool of MMEs.

6. A method for controlling an evolved packet core (EPC), comprising: managing user equipment (UE) information regarding one or more UEs associated with the EPC, the LIE information comprising a status indicating each of the one or more UEs as an Long Term Evolution (LTE) machine type (MTC) or a human to human (ΊΙ2ΙΙ) UE, and a service class level for each of the one or more UE classified as an 11211 UE; allocating one or more mobility management entities (MMEs) to the EPC based on the stored LIE information, the allocation of the one or more MMEs comprising at least one of: allocating an MME of the one or more MMEs to serve MTC and H2H UEs; and allocating a first MME of the one or more MMEs to serve the MTC UEs, and a second MME of the one or more MMEs to serve the H2H UEs, the second MME being separate from the first MME.

7. The method of claim 6, further comprising determining one or more sets of the H2H UEs for each of the allocated one or more MMEs, and allocate user plane bandwidth to each of the one or more sets based on the service class level for each of the one or more sets of the H2H UEs.

8. The method of claim 6, further comprising determining whether to aiiocate the first MME of the one or more MMEs to serve the MTC UEs, and the second MME of the one or more MMEs to serve the 11211 UEs based on a comparison of instructions per unit of time utilized to serve the MTC UEs and the H2H UEs.

9. The method of claim 6, further comprising changing from the allocation of the MME of the one or more MMEs to serve the MTC UEs and H2H UEs to the allocation of the first MME of the one or more MMEs to serve the MTC UEs, and the second MME of the one or more MMEs to serve H2H UEs for a ratio of instructions per unit of time utilized to serve the MTC UEs and the H2H UEs for when the second MME is allocated, falling below a predetermined threshold.

10. The method of claim 6, wherein the allocating one or more mobility management entities (MMEs) to the EPC is conducted either virtually or physically from a pool of MMEs.

1 1. A computer program storing instructions for controlling an evolved packet core (EPC), the instructions comprising: managing user equipment (UE) information regarding one or more UEs associated with the EPC, the UE information comprising a status indicating each of the one or more UEs as an Long Term Evolution (LTE) machine type (MTC) or a human to human (H2H) UE, and a service class level for each of the one or more UE classified as an H2H UE; allocating one or more mobility management entities (MMEs) to the EPC based on the stored UE information, the allocation of the one or more MMEs comprising at least one of: allocating an MME of the one or more MMEs to serve MTC and H2H UEs; and allocating a first MME of the one or more MMEs to serve the MTC UEs, and a second MME of the one or more MMEs to serve the H2H UEs, the second MME being separate from the first MME.

12. The computer program of claim 11, further comprising determining one or more sets of the H2H UEs for each of the allocated one or more MMEs, and allocate user plane bandwidth to each of the one or more sets based on the service class level for each of the one or more sets of the H2H UEs.

13. The computer program of claim 11, further comprising determining whether to allocate the first MME of the one or more MMEs to serve the MTC UEs, and the second MME of the one or more MMEs to serve the H2H UEs based on a comparison of instructions per unit of time utilized to serve the MTC UEs and the H2H UEs.

14. The computer program of claim 1 1 , further comprising changing from the allocation of the MME of the one or more MMEs to serve the MTC UEs and H2H UEs to the allocation of the first MME of the one or more MMEs to serve the MTC UEs, and the second MME of the one or more MMEs to serve H2H UEs for a ratio of instructions per unit of time utilized to serve the MTC UEs and the H2H UEs for when the second MME is allocated, failing below a predetermined threshold.

15. The computer program of claim 11, wherein the allocating one or more mobility management entities (MMEs) to the EPC is conducted either virtually or physically from a pool of MMEs.