LTE Control Plane on Intel Architecture

(1)

LTE Control Plane

on Intel

®

Architecture

– Using EEMBC CoreMark*

to optimize control plane

performance

January, 2013 White Paper

Soo Jin Tan Platform Solution Architect

Siew See Ang

Performance Benchmark Engineer

(2)

Executive Summary

The Long Term Evolution (LTE) control plane is responsible for control

operations such as network attaches, security control, authentication,

setting up of bearers, and mobility management. It corresponds to the

information flow and signaling between User Equipment (UE), Evolved-

UMTS Terrestrial Radio Access Network (E-UTRAN) and Evolved Packet

Core (EPC), which includes all the Radio Resource Control (RRC),

E-UTRAN signaling and Non-Access-Stratum (NAS) signaling. In other

words, the LTE control plane is a string of sequential operations that

are very compute centric. Intel

®

_{Architecture processors are}

competitive in terms of performance/watt, and are an excellent choice

for control plane applications.

This paper provides an overview of the LTE control plane architecture

and the nature of the computing power required to optimize control

plane system performance. To help select an IA processor that

provides the needed power/performance, you can use the EEMBC

CoreMark* benchmarking tool. Examples of how to do this are

provided, along with current platform options from Intel.

LTE Control Plane is a string of sequential operations which are very

compute centric.

IA processors are competitive in terms of

performance/watt, and are an excellent choice for control plane

applications.

(3)

Disclaimers

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark and MobileMark, are

measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause the results to vary. You should consult other

information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products.

For more complete information about performance and benchmark results, visit:

http://www.intel.com/benchmarks and http://www.intel.com/performance

Intel processor numbers are not a measure of performance. Processor numbers differentiate features within each processor family, not across different processor families: Go to:

Learn About Intel® Processor Numbers

Intel does not control or audit the design or implementation of third party benchmark data or Web sites referenced in this document. Intel encourages all of its customers to visit the referenced Web sites or others where similar performance benchmark data are reported and confirm whether the referenced benchmark data are accurate and reflect performance of systems available for purchase.

Configurations:

Three processors were used: Intel®_Xeon®_{Processor L5638, Intel}®_Xeon®_{Processor E3-1125C,}

and Intel®_Xeon®_{Processor E3-1275v2}

Tested using Red Hat* Enterprise Linux Server 6.1 Beta 32-bit OS, kernel version 2.6.32-131.0.15.el6.i686.

EEMBC CoreMark* was used to obtain benchmarking results shown. EEMBC CoreMark* binaries built with Intel®_{C++ Composer XE 2011 sp1.6.233. The compiler flags used are –O3 and}

processor specific flags. Tests conducted December 2012. LMBench* results obtained in December 2012.

(4)

LTE Control Plane Architecture

The control plane manages the information flow and signaling between E-UTRAN and EPC. Figure 1 describes a simplified view of the EPS architecture, which focuses on E-UTRAN/EPC interactions, user signaling and data

connectivity [1]. The S1 interface defines the forwarding packets between eNodeB and MME/Serving gateway. The MME is a main control element for the LTE access-network. It covers all the UE tracking and paging procedures including retransmissions. It also plays a key role in the bearer

activation/deactivation process and is responsible for choosing the right Serving GW for a UE at the initial attach and at the time of intra-LTE

handover involving Core Network (CN) node relocation. The S1 interface can be split into two parts [2]:

• S1-U (for User plane) – which carries user data between eNodeB and the Serving GW.

• S1-C/S1-MME (for Control plane) – which is a signaling-only interface between the eNodeB and the MME.

Figure 1. Simplified LTE Network Architecture

LTE Control Plane Protocol Stack

From the protocol stack perspective, as shown in Figure 2 [3], the control plane uses the same PHY, MAC, RLC, and PDCP to transport both RRC and Core Network NAS signaling. The RLC, MAC and PHY layers support the same functions for both the user and control planes. This does not mean that the user and control plane information is transmitted the same way. Several Radio Bearers can be established between the terminal and the network, each of them corresponding to a specific transmission scheme, radio protection method and priority handling. Additional control plane layers include the RRC,

(5)

E-UTRAN signaling (supporting functions such as Radio Bearer management, radio mobility, user paging), and NAS signaling (functions and services that are independent from the access technology).

Figure 2. LTE Control Plane Protocol Stack

The Radio Resource Control (RRC) protocol belongs to the UMTS WCDMA protocol stack and handles the control plane signaling of Layer 3 between the UEs (User Equipment) and the UTRAN [4]. It includes:

• RRC connection management

• Establishment and release of radio resources • Broadcast of system information

• Paging

• Transmission of signaling messages to and from the EPC

The RRC also supports a set of functions related to end-user mobility for terminals in RRC Connected state. This includes:

• Measurement control – the configuration of measurements performed by the terminal and the method reporting them to the eNodeB

• Support of inter-cell mobility procedures (handover) • User context transfer during handover

Control Plane Protocol Handling

A lot of protocol signal handling happens within the control plane, including system information broadcast, MME configuration update procedure,

contention/non-contention based random access procedure, RRC connection setup, attach/detach procedure, NAS common procedure, and many more. An example of the attach procedure is shown in Figure 3 [5]. A set of complex protocol signaling exchange takes place in the control plane for a single UE attachment. When more UEs become attached, more resources are taken up to process all these procedures. Depending on the coverage and the capacity of the cell size, the attach/detach rate can range from several UEs to several hundred UEs within seconds.

(6)

Figure 3. Example of Attach Procedure

During signalling, the state machine in the RRC changes. Two states are defined in the LTE: RRC_IDLE and RRC_CONNECTED. In the RRC_IDLE state, there is no connection between the terminal and the eNodeB, which means that the terminal is not known by the E-UTRAN Access Network. In the RRC_CONNECTED state, there is an active connection between the terminal and the eNodeB, which implies that a communication context is stored within the eNodeB for this terminal. Both sides can exchange user data and or signaling messages over logical channels.

Figure 4. RRC States

In a real life example, it is very difficult to anticipate how many UEs are going into the cell, how long the UEs are going to stay there and when the UEs are moving away. This results in a string of unpredictable, unscheduled interrupts for the control plane. Intel’s Out-of-Order architecture, Intel® Hyper-Threading Technology and Intel®_{Turbo Boost Technology handles this}

(7)

Embedded Microprocessor

Benchmark Consortium (EEMBC)

CoreMark*

EEMBC CoreMark* [6] is a benchmark released by the non-profit Embedded Microprocessor Benchmark Consortium (EEMBC) that was designed specifically to test the functionality of a processor core. EEMBC CoreMark* can be used to test a processor’s core functionality in terms of pipeline operation, memory sub system access and integer operations. EEMBC CoreMark* is not a real application, but is implemented to perform command workload in embedded applications such as matrix and link list manipulations, state machine

operation, and cyclic redundancy check.

**Interpreting EEMBC CoreMark* Performance Data**

EEMBC CoreMark has established rules for running the benchmark and

reporting the results. It supports both single and multiple instances test execution. At the end of the test CoreMark produces a single-number score. The score is divided by CPU speed in MHz to yield a CoreMark/MHz ratio. A higher ratio means better performance.

In this paper, we used EEMBC CoreMark single instances tests to measure processor core performance improvement between Intel®_processor

generations and run multiple instances tests for multi-core performance analysis. We ran our test using Red Hat* Enterprise Linux Server 6.1 Beta 32bit OS, kernel version 2.6.32-131.0.15.el6.i686, and built the EEMBC CoreMark* binaries with Intel®_{C++ composer XE 2011 sp1.6.233. The}

compiler flags used were –O3 and processor specific flags.

**EEMBC CoreMark* Single Instance Test**

We ran one instance of EEMBC CoreMark* test on Intel®_{processors from}

different generations and measured the CPU speed in MHZ using LMbench*. The EEMBC CoreMark* scores are divided by CPU frequency in MHz to obtain CoreMark/MHz ratio. Processors that we used:

• Previous Generation Intel®_{Xeon Processor 5000 Series : Intel}®_Xeon®

Processor L5638

• 2nd_{Generation Intel}®_{Xeon Processor E3 Series : Intel}®_Xeon®

Processor E3-1125C

• 3nd_{Generation Intel}®_{Xeon Processor E3 Series : Intel}®_Xeon®

(8)

In Figure 5, the EEMBC CoreMark*/MHz ratio shows how CPU core performance improved from one generation to another.

Figure 5. Single Core Performance Between Intel®_{CPU Generations}

EEMBC CoreMark* focuses mainly on testing processor core architecture performance such as pipeline operation, cache access and integer handling. Hence, CPUs from same generation will have same CoreMark/MHz ratio. To illustrate, we run single intense test on a series of 2nd_{Generation Intel}®

Core™ i7/5/3 processors and series of 3nd_{Generation Intel}®_{Core™ i7/5/3}

processors. Figure 6 and Figure 7 shows that the CoreMark/MHz ratios among CPUs from the same generations are identical.

0.00 0.20 0.40 0.60 0.80 1.00 1.20 1.40 Gen1

Intel®Processor Intel®ProcessorGen2 Intel®ProcessorGen3

Rel

at

iv

e Ra

tio

Cross CPU Generation

(9)

Figure 6. 2nd_{Generation Intel}®_{Core™ i7/5/3 Processors}

EEMBC CoreMark*/MHz Ratio

Figure 7. 3nd_{Generation Intel}®_{Core™ i7/5/3 Processors}

EEMBC CoreMark*/MHz Ratio

**EEMBC CoreMark*/MHz Ratio**

It’s obtained by taking EEMBC CoreMark* score, divided by CPU frequency in MHz. It’s worth taking note that the entire CPU family from the same generation will have identical CoreMark*/MHz Ratio.

(10)

**EEMBC CoreMark* Multiple Instances Test**

In LTE segment, typical workload for control plane are flow management, signaling, higher level protocol handing and controlling task while data plane workloads focus on packet processing, packet forwarding. Control plane has more complicated processing requirement and parallelism is important to address the issue. Numbers of cores available on a platform determine parallelism capabilities of a platform. EEMBC Coremark* supports multiple instantiations and yields a single score which is useful for multi-core processor performance analysis.

We run multiple instances of EEMBC CoreMark* on Intel®_Xeon®_Processor

E3-1125C that has 4 cores and 8 threads. We set test to run at 1, 2, 4, 8 and 16 instances. Figure 8 shows EEMBC CoreMark/MHz ratio has improves as number of instances used increased. However, once the number of instances used for testing is equal to or larger than the maximum number of SMT threads supported, adding instances will not give a higher EEMBC CoreMark/MHz ratio. In Figure 8, we observe non-significant ratio improvement from test results of 8 threads compared to 16 threads.

(11)

Conclusion

In the LTE segment, the typical workload for the control plane is flow

management, signaling, higher level protocol handing and controlling tasks. Since the control plane has a complicated processing requirement, parallelism is important to handle the complex processing needs of the control plane. The number of cores available on a platform determines the parallelism

capabilities of the platform. EEMBC CoreMark * benchmark scores obtained from running multiple instantiations or single instances are useful for multi-core processor performance analysis in control plane applications; the benchmark can also measure core performance improvement across CPU generations.

Authors

Soo Jin Tan is a Platform Solution Architect with Datacenter and Connected Systems Group (DCSG) at Intel Corporation.

Siew See Ang is a Performance and Benchmark Engineer with Datacenter and Connected Systems Group (DCSG) at Intel Corporation.

Acronyms

3GPP Third-Generation Partnership Project AP Application Protocol

AS Access Stratum CN Core Network

DNS Domain Name System ECM EPS Connection Management EPC Evolved Packet Core

EPS Evolved Packet System eNodeB Evolved NodeB

E-UTRAN Evolved UTRAN LTE Long Term Evolution

GPRS General Packet Radio Service

GSM Global System for Mobile Communications GTP GPRS Tunneling Protocol

GTP-U GPRS Tunneling Protocol-User plane HSS Home Subscriber Server

IMS IP Multimedia Subsystem IP Internet Protocol

(12)

MME Mobility Management Entity NAS Non Access Stratum

PCRF Policy Control and Charging Rules Function PDCP Packet Data Convergence Protocol

PDN Packet Data Network P-GW PDN Gateway QoS Quality of Service RAN Radio Access Network RLC Radio Link Control RRC Radio Resource Control RRM Radio Resource Management SAE System Architecture Evolution

SCTP Stream Control Transmission Protocol S-GW Serving Gateway

SMT Simultaneous Multi-threading TCP Transmission Control Protocol TNL Transport Network Layer UE User Equipment

UMTS Universal Mobile Telecommunications System UTRAN UMTS Terrestrial Radio Access Network VoIP Voice over IP

References

[1] 3GPP TS 23.002, Network architecture (Release 12), www.3gpp.org

[2] Pierre Lescuyer and Thierry Lucidarme, Evolved Packet System (EPS) The LTE And SAE Evolution Of 3G UMTS, John Wiley & Sons Ltd, 2008.

[3] 3GPP TS 36.300, Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 11), www.3gpp.org.

[4] 3GPP TS 25.331, Radio Resource Control (RRC); Protocol specification (Release 11), www.3gpp.org.

[5] 3GPP TS 23.401, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 11),

www.3gpp.org.

[6] What is CoreMark? http://www.coremark.org/

The Intel®_{Embedded Design Center provides qualified developers with web-based}

access to technical resources. Access Intel Confidential design materials, step-by step guidance, application reference solutions, training, Intel’s tool loaner program, and connect with an e-help desk and the embedded community. Design Fast. Design Smart. Get started today. http://www.intel.com/p/en_US/embedded.

(13)

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL

PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined". Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.

Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or go to:

http://www.intel.com/design/literature.htm%20

Intel, Xeon, Core, and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

CoreMark is a trademark of EEMBC. EEMBC is a registered thread of Embedded Microprocessor Benchmark Consortium. See http://www.eembc.org/home.php for more information.

LTE Control Plane on Intel Architecture