How to perform 2.5G/3G core network testing

This article introduces some key procedures required to establish a session in the packet-switched 2.5G/3G core network and service layer. This article will first use IMS sessions as a specific example to highlight the related test challenges and how to solve these challenges through the Tektronix G35 protocol test platform; finally, the impact of new services such as cellular-based push-to-talk (PoC) and multimedia broadcast multicast service (MBMS) on the 2.5G/3G core network infrastructure is discussed.

Introduction

The latest standardized UMTS R5 and R6 features such as HSDPA and HSUPA are transforming mobile networks into true broadband communication systems. The continuous decline in voice revenues requires operators to seek sources of revenue growth by developing new services for customers.

The arrival of an alternative mobile broadband technology, the IEEE 802.16e standard (commonly referred to as Mobile WiMAX), will reinforce this trend. With this new technology, competing service providers will emerge, allowing more and more end users to adopt IP-based services in their daily lives. IMS and other packet data platforms give service providers the ability to deploy multiple services with higher QoE at a lower overall cost. A wide variety of applications such as ringtone downloads, SMS, e-mail, picture messaging and information services are also popular. The costs associated with migrating these types of services to a common platform to optimize operating expenses are a strong driving force for mobile (and fixed) operators to adopt IMS-based systems.

Primary/Secondary PDP Environment

One thing all these different applications have in common is that their availability requires a specific access point. An access point is an IP router that provides connectivity between a mobile station (MS) and the selected application. The MS must know the access point name (APN) in order to contact the required access point through the GPRS subsystem. This is achieved through the PDP context activation procedure shown in Figure 1.

Figure 1: PDP environment activation procedure (MS enablement).

The MS sends an Activate PDP Environment Request message containing the PDP type, PDP address, access point name, required quality of service (QoS) and protocol configuration options to the SGSN. The SGSN uses the APN (APN has a "fully qualified domain name" format) to select a reference point (GGSN) for an external network. The APN is a logical name pointing to the external packet data network (PDN) that the user wants to connect to. The function of the domain name service provider is to convert the logical APN name to an IP address. According to RFC 1034, this function is a standard Internet function. In this way, the SGSN finds the GGSN connected to the required external network. Next, the SGSN initiates the "Create PDP Environment Procedure" to the GGSN.

The QoS required indicates the desired QoS specification. The protocol configuration options can be used to request optional PDP parameters from the GGSN. The protocol configuration options are then sent transparently by the SGSN.

After sending the PDP environment activation request, a timer is started in the MS while waiting for the PDP environment activation acceptance or rejection message.

The SGSN verifies the Activate PDP Context Request. If the address of the GGSN cannot be derived, or if the APN cannot be converted, or if the SGSN determines that the Activate PDP Context Request is invalid, the SGSN shall reject the Activate PDP Context Request.

If the PDP context activation procedure is successful, a user plane tunnel will be established between the MS and the external packet data network (PDP). It is important to note that this is only the user plane tunnel from the GPRS point of view, from the external PDN point of view, it may also carry control plane information such as SIP messages.

As mentioned above, the access point is the first point of contact with external service platforms. Examples of these service platforms are: Short Message Service Center (SMSC); Multimedia Messaging Service Center (MMSC); Wireless Application Protocol (WAP); IP Multimedia Subsystem (IMS); Internet.

A GGSN can provide access to different services through different APNs. From the external PDN point of view, a distinction must be made between primary and secondary PDP contexts (Figure 2). The primary PDP context is always established for the first connection between an MS and a specific APN. If further connections to the same APN are required, up to 10 secondary PDP contexts can be established. Typically, each IMS media stream will be routed independently through a separate tunnel, mainly because the GPRS charging function in Release 5 cannot generate multiple charging records for one data stream. In addition, different IMS user plane sessions may have different QoS requirements.

Figure 2: PDP context types.

Therefore, PDP contexts can be divided into the following two categories. 1. Primary PDP context: provides connectivity to different APNs. The SGSN assigns a unique IP address to the MS for each primary PDP context. 2. Secondary PDP context: provides connectivity to the same APN, but with different QoS. A secondary PDP context is always associated with a primary PDP context. Both IP addresses and access points are reused from the primary PDP context.

The QoS of any valid primary or secondary PDP context can be changed by the MS or the network using the PDP context change procedure. Figure 3 depicts the negotiated QoS parameters simulated by the G35 protocol tester.

Figure 3: Quality of Business IE (G35 protocol simulator screenshot).

The maximum number of supported PDP environments depends on the capacity of the MS. Typical test mobile platforms support up to 6 PDP environments. SGSN/GGSN nodes can support up to 11 PDP environments per MS. For full stress testing, the G35 simulates up to 6 million mobile users, while each simulated MS can have up to 11 active PDP environments. With a capacity of more than 60 million simultaneously active GPRS tunnels, the G35 can simulate mobile scenarios and user loads from small to rural scale to large urban scale.

GPRS Domain Verification with G35

The G35 GPRS functional and load test platform from Tektronix is ​​a scalable multi-technology system. In its basic configuration, the portable unit is equipped with only one simulation board. For complex load scenarios, the rack system can be equipped with up to 13 simulation boards. Different hardware interfaces can be combined into one cabinet, such as the (GERAN) E1 board for simulating a 2.5G access network, the ATM board for UMTS radio access network simulation (UTRAN), and the Ethernet board for simulating an external PDN.

With its unparalleled flexibility, G35 provides simulation and emulation capabilities for a large number of network elements, so it can test GPRS subsystems under various conditions. A typical application case is shown in Figure 4.

Figure 4: Typical topology for GPRS load testing. [page]

G35 simulates a radio access network consisting of a certain number of mobile users. These users may be distributed in 60 virtual radio cells, but in the simplest scenario, all simulated users are located in the same cell.

Typical parameters used for cell settings include technology (2G, 3G), routing area code (RAC), mobile country code (MCC) and mobile network code (MNC). This approach allows the user to group users accordingly and simulate various mobile behaviors, such as: (1) Moving train - all users are attached to one 3G cell. After a period of time, 3G coverage is lost. All users need to perform an inter-system change and attach to a 2G network cell. (2) Crossing the border - users switch cells with different RAC, MNC or MCC. A routing area update procedure needs to be performed. (3) Urban area - users are more or less evenly distributed in several cells and switch to other cells in a pseudo-random manner. Users need to perform a cell reselection or cell change procedure.

Using the same command will trigger all movement situations. Depending on the unit's configuration, the G35 will automatically detect and initiate the relevant movement management procedure.

Depending on the use case, other network elements can also be simulated, such as Equipment Information Register (EIR), CAMEL, SMS Center, Positioning Center, Home Location Register (HLR), etc. Many operators have a considerable number of prepaid users, so for mixed configurations of prepaid and postpaid users, it is also necessary to simulate the relevant transactions of the Ge interface between the SGSN and the CAMEL center.

Another typical test scenario is functional testing combined with background load. This is particularly important when launching new services. A large number of simulated users perform standard GPRS procedures such as ATTACH, PDP environment activation/deactivation, IP conversion and DETACH. These users form a group that generates background load. Another smaller group consists of a limited number of users (such as 1 to 20) and injects new service (such as IMS) related procedures into the GPRS subsystem.

This testing approach allows the protocol execution to be verified in all relevant aspects. For example: Does the protocol execution meet the standards? Is it robust enough to withstand abnormal behavior/unexpected error conditions? Will memory leaks occur during long-term stability testing?

Such test scenarios can also be combined with error insertion, a deterministic method for simulating abnormal situations. With this feature, test engineers can inject irregular programs into a certain number of user traffic. There are a large number of predefined error conditions for test engineers to choose from. For example, it is possible to reproduce the loss of radio connection, simulate a non-compliant mobile phone (such as repeated messages) or simulate an improperly configured terminal (such as trying to connect to a non-existent APN). For a certain percentage of users, each error will be injected in a pseudo-random manner. Different error conditions can be mixed with other conditions.

The impact of abnormal and error conditions remains unclear, as these conditions often cannot be tested on real network nodes. An example of an abnormal condition is a user-initiated PDP context activation conflicting with a network-initiated DETACH procedure. The expected network behavior in abnormal situations is usually not defined in the standards.

The combination of load testing and functional testing is a new testing paradigm that eliminates the inherent drawbacks of isolated load/functional testing.

The G35 is designed to support simulation of realistic load and stress test scenarios. A key factor is the ability to generate control and user plane traffic. Each PDP context can be individually associated with a specific user plane load profile. With the G35, each MS can activate up to 11 PDP contexts, each associated with another load profile.

The simulator can generate user plane content internally, and it is also possible to inject external content (such as web browsing, video streams of external video service devices) into the user plane tunnel.

In a complex ecosystem, symptoms and their root causes are often far apart. A single miscalculated or corrupted five-piece set distributed from HLR to SGSN (Gr interface) may cause an integrity check error between SGSN and RNC (IuPS interface). To completely solve the problem, G35 combines monitoring and active testing capabilities.

Assume that an operator wants to simulate an access network with 100,000 mobile users and wants to monitor the traffic in the core network (to network nodes such as HLR, CAMEL center, etc.), and further assume that the complete network is based on IP. In this case, the investment in test and measurement tools will be much lower than in the past, because the operator only needs to invest in a G35 with an Ethernet board. The Ethernet board can be used for both active testing (generating load) and passive testing (monitoring) at the same time, without the need for a separate protocol monitoring device.

G35 provides a large number of statistics and counters to support analysis tasks. Test results can be imported into Excel files or databases to support the generation of detailed reports.

Push services (push service)

Typical Internet services such as telecommunications and web browsing are generally considered to be pull services (pull service). The end user initiates transactions and requests content, such as a specific web page. Push services refer to communication methods in which transactions are initiated by the central office (such as PoC service or broadcast/multicast service). Push transactions are often based on a subscription model, and users need to tell the central office in advance "send specific information (such as sports news, weather forecast) once there is new content."

Two push services have been introduced using 3GPP Release 6. We will take a closer look at them and examine how these services affect the GPRS subsystem.

Push-to-talk over cellular networks

Push-to-Talk over Cellular (PoC) is a new standard that provides efficient and simple voice communication between groups of users. The standard presupposes that the user has subscribed to one or more user groups. The user equipment provides the possibility to manage PoC service settings and compile group lists. The corresponding protocols are called XCAP (XML Configuration Access Protocol) and XDM (XML Document Management).

After all group members exchange SIP signals, the voice stream is sent from the initiator to the PoC server. The server then distributes the voice stream to all user terminals in the user group. Only one user can have the "right to speak" and send voice data to the PoC server at a time, which makes the service similar to a "walkie-talkie". The Voice Stream Control Protocol (TBCP) is used to control the "right to speak" assigned to PoC participants, including sending notifications that the user has been granted the right to speak and that his voice will be heard by other participants.

Resource efficiency is the advantage of PoC services. The user's voice information is segmented and transmitted through the packet-based GPRS subsystem. Unlike typical two-way communication services, PoC only requires a one-way user plane channel. Although packet-oriented technology may lead to quality degradation, such as introducing a delay of about 2 seconds in the voice frame, the achieved voice quality is usually good enough for this type of application.

Mobile broadcast/multicast services

Mobile Broadcast/Multicast Service (MBMS) is an IP data broadcast service, i.e. a method of transmitting content such as video and audio clips to a large number of recipients. MBMS is therefore a point-to-multipoint unidirectional bearer service, where data is transmitted from a single source to multiple recipients. 3GPP has defined two modes of operation: broadcast mode and multicast mode.

Broadcast mode is an efficient way to send information to all users within a broadcast service area (such as thunderstorm warnings). Multicast mode is based on the subscription model. There are some high-level requirements for multimedia broadcast/multicast services: MBMS notification procedures are used to indicate the start of MBMS data transmission; a clear mechanism to activate the network when there is at least one user in a cell, starting MBMS data transmission for a multicast session in the cell; a clear mechanism to stop MBMS data transmission for a given multicast session in a cell that no longer contains any active users.

The RANAP procedure between the RNC and the SGSN for MBMS service activation and session initiation is shown in FIG5 .

Figure 5: MBMS service activation and session start.

[page]

The SGSN initiates the MBMS MS connection procedure by sending a RANAP MBMS UE connection request, the purpose of which is to provide the RNC with a list of MBMS services activated for this MS. The right screen shot of Figure 5 shows the structure of this message, which is created using the G35 Message Building System (MBS). The message consists of four sequences, each containing a PLMN identity (pLMNidentity) and a service identity (serviceID). In this example, the RNC is informed that this particular user has activated four different services. pLMNidentity and serviceID are represented as variables because these parameters are also required in other information describing the traffic (such as MBMS session start).

Then, the RNC confirms with an MBMS UE Connection Response. Since the RNC does not provide an MBMS environment for this service (because this is the first time the MS has activated the service), it does not know the IP multicast address or APN for the service. The RNC uses an MBMS Information Request message to request this information from the SGSN. The SGSN responds with an MBMS Information Response message (parameters: IP multicast address, APN). After the service environment is created, the RNC sends an MBMS Registration Request message and notifies the core network that the RNC is ready to receive an MBMS Session Start message. After the MBMS Registration Response, MBMS Session Start and MBMS Session Response, downlink data transmission is established.

How will these services affect the GPRS subsystem? It is obvious that these services will lead to a significant increase in user plane traffic. This causes the traffic pattern to become more unpredictable, because there is an increasing degree of uncertainty about which cells will receive the service. Various data broadcast services will compete for bandwidth. Therefore, the meaning of QoS is as follows: (1) Traffic reception in the broadcast area cannot be guaranteed and receivers may experience data loss; (2) MBMS does not support individual retransmission; (3) To reduce traffic, it must be possible for network operators to send multicast information only to cells in a specified multicast area that contain members of the multicast group; (4) Network operators must be able to set QoS for each broadcast service individually; (5) It should be possible to adapt MBMS data transmission to different RANs or currently available radio resources; (6) If there are network resource constraints, operators should be able to define rules for supporting or not supporting broadcast services.

Outlook

GPRS standardization was initiated by ETSI's SMG (Special Action Group) in 1994, and the main GPRS specification was approved by SMG #25 in 1997 and completed in 1999. The original conceptual design of GPRS was a packet switching subsystem - a vertical extension of the circuit-switched GSM core network.

GPRS will completely surpass the circuit switching subsystem in the next few years. Many network equipment manufacturers are working hard to develop and standardize new access technologies (such as UMA and FemtoCells) in the GPRS packet switching domain, thus promoting the development of this trend.

The future mobile network architecture will be horizontal, as shown in Figure 6, which is a comprehensive network architecture based on 4G IP. SGSN and GGSN constitute the core elements of the transmission network. With the advent of LTE, these two elements will evolve into two new elements indicated by MME (mobile management entity) and SAE Gateway (system architecture evolution).

Figure 6: 4G IP-based integrated network.

SGSN and GGSN play a key role in ensuring smooth operations today and seamless integration of future services into the mobile ecosystem.

The purpose of every communication system is not the technology itself, but to provide reliable support for the applications and the associated QoE as perceived by the end user.

For network operators and equipment manufacturers, it is critical to understand how a heavily loaded GPRS subsystem works and how the GPRS network is affected by the introduction of new services and various performance requirements.

Many new services, such as PoC and MBMS, will not be deployed in early 2009. Although the first terminals will appear in 2008, it will take several years for these services to become mass market services.

Understanding the performance characteristics of these and other services delivered under full load is fundamental to the test methodology for GPRS. As the Yankee Group points out, "test providers must be able to emulate the complexity and scale of the network before they can confidently deliver services." The Tektronix G35 has the ability to complete all the tests required using a single platform. Its unique features, such as emulation of all surrounding network elements, error insertion, high performance and a large number of mobile protocols, are the basis for comprehensive functional load and stress testing, not only exclusive but also specific to GPRS. The Tektronix G35 and its predecessor, the K1297-G20, are widely used by all major network operators and network equipment manufacturers around the world. Judging from user feedback, we can safely say that the G35 has been a proven and reliable test and measurement tool.