Access Class Barring in LTE using System Information Block Type 2

As per 3GPP TS 22.011 (Service accessibility):

All UEs are members of one out of ten randomly allocated mobile populations, defined as Access Classes (AC) 0 to 9. The population number is stored in the SIM/USIM. In addition, UEs may be members of one or more out of 5 special categories (Access Classes 11 to 15), also held in the SIM/USIM. These are allocated to specific high priority users as follows. (The enumeration is not meant as a priority sequence):
Class 15 - PLMN Staff;
 -"-  14 - Emergency Services;
 -"-  13 - Public Utilities (e.g. water/gas suppliers);
 -"-  12 - Security Services;
 -"-  11 - For PLMN Use.

Now, in case of an overload situation like emergency or congestion, the network may want to reduce the access overload in the cell. To reduce the access from the UE, the network modifies the SIB2 (SystemInformationBlockType2) that contains access barring related parameters as shown below:

For regular users with AC 0 – 9, their access is controlled by ac-BarringFactor and ac-BarringTime. The UE generates a random number
– “Rand” generated by the UE has to pass the “persistent” test in order for the UE to access. By setting ac-BarringFactor to a lower value, the access from regular user is restricted (UE must generate a “rand” that is lower than the threshold in order to access) while priority users with AC 11 – 15 can access without any restriction

For users initiating emergency calls (AC 10) their access is controlled by ac-BarringForEmergency – boolean value: barring or not

For UEs with AC 11- 15, their access is controlled by ac-BarringForSpecialAC - boolean value: barring or not.

The network (E-UTRAN) shall be able to support access control based on the type of access attempt (i.e. mobile originating data or mobile originating signalling), in which indications to the UEs are broadcasted to guide the behaviour of UE. E-UTRAN shall be able to form combinations of access control based on the type of access attempt e.g. mobile originating and mobile terminating, mobile originating, or location registration.  The ‘mean duration of access control’ and the barring rate are broadcasted for each type of access attempt (i.e. mobile originating data or mobile originating signalling).

Another type of Access Control is the Service Specific Access Control (SSAC) that we have seen here before. SSAC is used to apply independent access control for telephony services (MMTEL) for mobile originating session requests from idle-mode.

Access control for CSFB provides a mechanism to prohibit UEs to access E-UTRAN to perform CSFB. It minimizes service availability degradation (i.e. radio resource shortage, congestion of fallback network) caused by mass simultaneous mobile originating requests for CSFB and increases the availability of the E-UTRAN resources for UEs accessing other services.  When an operator determines that it is appropriate to apply access control for CSFB, the network may broadcast necessary information to provide access control for CSFB for each class to UEs in a specific area. The network shall be able to separately apply access control for CSFB, SSAC and enhanced Access control on E-UTRAN.

Finally, we have the Extended Access Barring (EAB) that I have already described here before.

CSFB Performance

Here is another presentation from Qualcomm from the '4G World'.

CSFB Performance from Zahid Ghadialy

With regards to SI Tunneling mentioned in the presentation, I found the following in another Qualcomm whitepapers:


With Release 9 Enhanced Release with Redirection—SI Tunneling, the device follows 3GPP release 9, where SIB information can be tunneled from the target Radio Access Network (RAN) via the core network to the source RAN and be included in the redirection message sent to the device. This can avoid reading any SIBs on the target cell. 

The predominant solutions deployed today are based on Release 8 Release with Redirection — SIB Skipping, in order to achieve good call setup times, good reliability, and simplify deployments. It is anticipated that Release 9 Enhanced Release with Redirection will be deployed in the near future. At this time, there is not as much push for handover-based CSFB since both Release 8 Release with Redirection—SIB Skipping and Release 9 Enhanced Release with Redirection—SI Tunneling have largely addressed any call setup time issues that may have existed with the Basic Release with Redirection solution.

I have blogged on this topic before, here.

More on Dual Radio here and SVLTE here.

Reducing CSFB Timing with RRC R9 Optimisations

While in the initial testing CSFB timing used to be between 6-8 seconds, most Rel-8 phones can complete the CSFB procedure between 4-4.5 seconds. Unfortunately this is still a lot in terms of signalling. To reduce this in Rel-9 there is a simple optimisation that has been done.

In the RRC Connection Release message, there is a possibility to add UTRAN/GERAN System Information messages. In the picture above, I have only shown UTRA System Information but a similar picture can be drawn for GERAN.

Once all the Mandatory SIB's are sent to the UE then it can immediately camp on without the need to read any other additional system info. This will reduce the CSFB time between 1-2 seconds.

The lesser the CSFB time, the better the Quality of end user experience

Dual-Mode and Multi-Mode Femtocells

Came across this slide in one of the presentations from MWC.

The Dual-Mode and maybe Multi-Mode solution (in future) may be very useful, not only from the point of view that it can serve LTE as well as 3G mobile devices but in case of a LTE mobile where for voice calls the UE may have to fall back on 3G network, if there is no 3G coverage then there would be no voice communication possible.

One of the ways to do have a voice communication in the initial phases of LTE is CS Fallback (CSFB). CSFB is possible by the UE establishing the call on UMTS or GSM network. If for some reason the coverage on those networks is non-existent then having a dual-mode femtocell can be really helpful as it would seamlessly transfer the voice call on the 3G.

Hopefully in the future when VoLTE is here these problems would be solved automatically.

The main problem that I can see with this Dual-mode or Multi-mode solution is that the operator would have to be supporting both Small Cells solution across both the networks and I guess they would be slightly expensive.

Dual Radio Solution for Voice in LTE

I did mention in the Twitter conversations post from LTE World Summit 2011 that there are now certain analysts and players in the market who think that it should be possible to have two radios. Here is a slide from ZTE that shows that they are thinking in this direction as well.

Click on the pic to enlarge.

Tri-SIM phones have been available for quite a while but now there are Quad-Sim Shanzhai phones that are available in China. I am sure there is a market for these kind of phones.

With the battery life and the mobile technology improving, these are no longer the concerns when talking about dual radio possibility in the devices. Another common argument is that there may be additional interference due to multiple radios simultaneously receiving/transmitting. I am sure these can be managed without much problem.

Another problem mentioned is we may need multiple SIM cards but the SIM cards used is actually a UICC. There can be multiple SIM applications and IMSI's on it. The network may need some very minor modifications but they should be able to manage this with no problems. In the good old days, we used to have mobiles with built in Fax. The mobile number used to be different from the Fax number. It was a similar kind of problem but managed without problem.

So there may still be time to keep LTE simple by standardising the dual-radio solution rather than having CSFB, VoLTE, SRVCC, VoLGA, etc.

Any thoughts?

Circuit Switched Fallback (CSFB): A Quick Primer

I have explained CSFB with basic signalling here and there is a very interesting Ericsson whitepaper explaining all Voice issues in LTE here.

The following CSFB details have been taken from NTT Docomo Technical Journal:

The basic concept of CS Fallback is shown in Figure 1. Given a mobile terminal camping on LTE, a mobile terminating voice call arrives at the terminal from the existing CS domain via EPC. On receiving a paging message, the mobile terminal recognises that the network is calling the mobile terminal for CS-based voice and therefore switches to 3G. The response confirming the acceptance of a call request is then sent from the mobile terminal to the 3G-CS system, and from that point on, all call control for the voice service is performed on the 3G side.

The CS Fallback consists of a function to notify a mobile terminal of a call request from the CS domain and combined mobility management functions between CS domain and EPC for that

purpose. The network architecture of CS Fallback is shown in Figure 2.

One of the remarkable characteristics of the EPC supporting CS Fallback is that it connects the Mobile Switching Center (MSC) and Visited Location Register (VLR) in the 3G CS domain

with the Mobility Management Entity (MME), which provides EPC mobility management functionality. The interface connecting MSC/VLR and MME is called an SGs reference point. This

interface is based on the concept of the Gs reference point that exchanges signalling with MSC, which connects to the Serving General Packet Radio Service Support Node (SGSN), a 3G

packet switch. The SGs provides nearly all the functions provided by the existing Gs.

The CS Fallback function uses this SGs reference point to transfer the mobile terminating call requests from the CS domain to LTE. It also provides combined mobility management

between the 3G CS domain and the EPC to enable this transfer to take place.

Combined Mobility Management between CS Domain and EPC Network:

A mobile communications network must always know where a mobile terminal is located to deliver mobile terminating service requests to the mobile user on the mobile terminating side. The procedure for determining terminal location is called “mobility management". As a basic function of mobile communications, 3G and LTE each provide a mobility management function.

To complete a call using the CS Fallback function, the CS domain needs to know which LTE location registration area the mobile terminal is currently camping on. To this end, the MME must correlate mobility management control of the CS domain with that of EPC and inform MSC/VLR that the mobile terminal is present in an LTE location registration area.

The 3G core network already incorporates a function for linking mobility management of the CS domain with that of the Packet Switched (PS) domain providing packet-switching functions. As described above, the CS domain and PS domain functions are provided via separate switches. Thus, if combined mobility management can be used, the mobility management procedure for the terminal only needs to be performed once, which has the effect of reducing signal traffic in the network. This concept of combined mobility management is appropriated by the CS Fallback function. Specifically, MSC/VLR uses the same logic for receiving a location registration request from SGSN as that for receiving a location registration request from MME. This achieves a more efficient combined mobility management between the CS domain and EPC while reducing the development impact on MSC.

As described above, a mobile terminal using LTE cannot use 3G at the same time. This implies that the MME, which contains the LTE location registration area (Tracking Area (TA)), is unable to identify which MSC/VLR it should send the mobility management messages to from the TA alone. To solve this problem, the mapping of TAs and 3G Location Areas (LA) within MME has been adopted. The concept behind TA/LA mapping is shown in Figure 3. Here, MME stores a database that manages the correspondence between physically overlapping TAs and LAs. This information is used to determine which MSC/VLR to target for location registration.

The combined TA/LA update procedure for CS fallback is shown in detail in Figure 4. First, the mobile terminal sends to the MME a Tracking Area Update (TAU) request message indicating a combined TAU and the current TA in which the mobile terminal is currently present (Fig. 4 (1)). The MME then performs a location update procedure towards Home Subscriber Server (HSS), which is a database used for managing subscriber profiles (Fig. 4 (2)). Next, the MME uses the TA/LA correspondence database to identify the corresponding LA and the MSC/VLR that is managing that area, and uses the SGs reference point to send a Location Area Update (LAU) request message to the MSC/VLR together with the LA so identified (Fig. 4 (3)). The MSC/VLR that receives the LAU request message stores the correspondence between the ID of the MME originating the request and an ID such as the International Mobile Subscriber Identity (IMSI) that identifies the subscriber (Fig. 4 (4)). This enables the MSC/VLR to know which MME the mobile terminal is currently connected to and that the mobile terminal is camping on LTE. Following this, the MSC/VLR performs a location registration procedure with the HSS (Fig. 4 (5)). Finally, the MSC/VLR informs the MME of temporary user identity (Temporary Mobile Subscriber Identity (TMSI)), which is used at the time of a mobile terminating call in the CS domain, and indicates that location registration has been completed. The MME then informs the mobile terminal of the TMSI and of the LA that the mobile terminal has been registered with thereby completing combined location registration (Fig. 4 (6) (7)).

CS Fallback Call Control Procedures - Mobile Originating Call:

To originate a voice call using the CS Fallback function, a mobile terminal in the LTE location registration area must first switch (fall back) to 3G. The mobile-originating voice call procedure is shown in Figure 5. To originate a call, the mobile terminal begins by sending a CS fallback service request message to the MME (Fig. 5 (1)). Since a packet-communications transmission path (bearer) must always exist in EPC for the purpose of providing an always-on connection, the bearer also has to be handed over to 3G. To accomplish this, the MME issues a handover command to the mobile terminal in LTE and initiates a handover procedure (Fig. 5 (2)). The mobile terminal changes its radio from LTE to 3G during this procedure (Fig. 5 (3)). On completion of handover, the mobile terminal issues an originating request for voice service to the MSC/VLR. A voice-call connection is then established using an existing calloriginating procedure on 3G and the CS Fallback procedure is completed (Fig. 5(4)).

CS Fallback Call Control Procedures - Mobile Terminating Call:

The mobile terminating voice call procedure using CS Fallback is shown in Figure 6. When the MSC/VLR receives a message indicating the occurrence of a mobile terminating call (Fig. 6 (1)), the MSC/VLR identifies the corresponding MME from the call information received (Fig. 6 (2)). Then, the MSC/VLR sends a paging message (Fig. 6 (3)) towards the MME. Next, the MME sends a paging message to the mobile terminal in LTE (Fig. 6 (4)). This paging message includes an indication that the call is a CS service, and on identifying the call as such, the mobile terminal sends a CS fallback service request signal to the MME (Fig. 6 (5)). Following this, a handover procedure to 3G as described above takes place (Fig. 6 (6), (7)). The mobile terminal that is now switched to 3G sends a paging response message to the MSC/VLR at which it is registered (Fig. 6 (8)). Finally, an existing mobile terminating call procedure on 3G is executed and the CS Fallback procedure is completed (Fig. 6 (9)).

eMPS: Enhanced Multimedia Priority Service in Release-10 and beyond

The response to emergency situations (e.g., floods, hurricanes, earthquakes, terrorist attacks) depends on the communication capabilities of public networks. In most cases, emergency responders use private radio systems to aid in the logistics of providing critically needed restoration services. However, certain government and emergency management officials and other authorised users have to rely on public network services when the communication capability of the serving network may be impaired, for example due to congestion or partial network infrastructure outages, perhaps due to a direct or indirect result of the emergency situation.

Multimedia Priority Service, supported by the 3GPP system set of services and features, is one element creating the ability to deliver calls or complete sessions of a high priority nature from mobile to mobile networks, mobile to fixed networks, and fixed to mobile networks.

Requirements for the Multimedia Priority Service (MPS) have been specified in TS 22.153 for the 3GPP Release-9

The intention of MPS is to enable National Security/Emergency Preparedness (NS/EP) users (herein called Service Users) to make priority calls/sessions using the public networks during network congestion conditions. Service Users are the government-authorized personnel, emergency management officials and/or other authorized users. Effective disaster response and management rely on the Service User’s ability to communicate during congestion conditions. Service Users are expected to receive priority treatment, in support of mission critical multimedia communications.

LTE/EPC Release 9 supports IMS-based voice call origination by a Service User and voice call termination to a Service User with priority. However, mechanisms for completing a call with priority do not exist for call delivery to a regular user for a priority call originated by a Service User. MPS enhancements are needed to support priority treatment for Release 10 and beyond for call termination and for the support of packet data and multimedia services.

MPS will provide broadband IP-based multimedia services (IMS-based and non-IMS-based) over wireless networks in support of voice, video, and data services. Network support for MPS will require end-to-end priority treatment in call/session origination/termination including the Non Access Stratum (NAS) and Access Stratum (AS) signaling establishment procedures at originating/terminating network side as well as resource allocation in the core and radio networks for bearers. The MPS will also require end-to-end priority treatment in case of roaming if supported by the visiting network and if the roaming user is authorized to receive priority service.

MPS requirement is already achieved in the 3G circuit-switched network. Therefore, if the network supports CS Fallback, it is necessary to provide at least the same capability as 3G circuit switched-network in order not to degrade the level of voice service. In CS Fallback, UE initiates the fallback procedures over the LTE as specified in TS 23.272 when UE decides to use the CS voice service for mobile originating and mobile terminating calls. To achieve priority handling of CS Fallback, NAS and AS signaling establishment procedures, common for both IP-based multimedia services and CS Fallback, shall be treated in a prioritized way.

In Release-10, for LTE/EPC, the following mechanisms will be specified.

• Mechanisms to allocate resources for signaling and media with priority based on subscribed priority or based on priority indicated by service signaling.
• For a terminating IMS session over LTE, a mechanism for the network to detect priority of the session and treat it with priority.

In Release-10, for CS Fallback, the following mechanism will be specified:

• A mechanism to properly handle the priority terminating voice call and enable the target UE to establish the AS and NAS connection to fall-back to the GERAN/UTRAN/1xRTT.

For more information, see:

3GPP TR 23.854: Enhancements for Multimedia Priority Service (Release 10)

3GPP TS 22.153: Multimedia priority service (Release 10)

Voice over LTE – a step towards future telephony (Ericsson Whitepaper)

The Fact boxes in the Appendix give a very good quick overview of how different technologies work with VoLTE.

Voice over LTE – a step towards future telephony

View more documents from Zahid Ghadialy

LTE CS Fallback Procedure

From a 3GPP presentation by Hannu Hietalahti:

1. CS FallBack from EPS to CS domain

2. CSFB reuses voice and other CS-domain services provided by legacy CS infrastructure

3. EPS redirects the UE to CS Domain for CS services

3a. SMS can be delivered to the UE without redirecting to CS Domain

3b. After CS service the UE returns to LTE, depending on coverage and policy

4. User can decide, based on CLI, whether to accept CSFB request

5. Application of CSFB:

5a. CS capable device camping on LTE cell can establish/receive CS services

5b. Reuse of existing CS infrastructure for voice service until IMS VoIP is deployed

5c. Provide voice roaming support with LTE

5d. Support E911 using existing CS infrastructure

5e. Rel-9 IMS provides full emergency call support

5f. Requires overlapping CS domain coverage

Note: CSFB applies between LTE and GSM, WCDMA and 1xRTT

Solving the LTE voice dilemma

Continuing the discussion from LTE World Summit, this is something that has been discussed in the past by myself and other blogs as well. We know that there is no out of the box solution for voice calls in Release 8 but there are some solutions that are being standardised for this problem. Dr. Howard Benn, Director of Cellular Standards, Motorola Mobile Devices gave an interesting presentation on this topic titled, "Voice –how to talk over LTE". Here is the summary of his presentation along with some more information:
As we know, IMS was introduced in Rel 5 but even till today, there has been no major IMS rollouts. There are some operators working on deploying the IMS solution but in reality its not been as successful as it should have been. If IMS is available then the problem of voice call on LTE goes away. The problem can be solved using Voice Call Continuity or VCC. Infact there is a bunch of specifications on IMS Centralized Services (ICS) and network Centric VCC for solving this and other similar problems.

So with IMS not being available, the first alternative for this problem is Circuit Switched Fallack (CSFB). In this, as can be seen from the MSC above, the user is attached to an LTE network. MSC can send Paging to the UE and if the user accepts the voice call then he is handed over to 2G/3G network. The big problem with this approach is additional time required to establish the voice call and the PS services might get disrupted, depending on how its handled.

The second solution is to have a Generic Access Network (GAN... previously known as UMA) based solution. This is similar solution to the ones used by some Femtocells. This would mean that the UE's would require GAN chipsets and GAN is known to be power hungry so it can impact the battery life significantly.

China Mobile's, Bill Huang in a recent interview mentioned that “We could carry voice over UMA” and “We will have an LTE network that supports voice…”. He was referring to this approach mentioned above.

Finally there are always proprietary options like Skype that can be used along with the data services to solve the voice problem.

Infact a service like Vonage, modified for mobiles, can solve this problem easily. You can connect a VoIP client from your phone or device to Vonage and you are given a landline number that you can pass to others. When calls are received on this number, the client in the mobile rings and you answer the call normally.

Nick Yamasaki from KDDI mentioned that KDDI will roll out LTE with CS fallback option for voice initially but then SRVCC (Single Radio VCC) solution will be adopted in future.