Showing posts with label Signalling. Show all posts
Showing posts with label Signalling. Show all posts

Monday 21 May 2012

RoHC & RoHCv2

Its been a while since I blogged about Robust Header Compression (RoHC). You can see the old posts here and here. Here is an example message showing the header compression information.


RoHCv2 is also available as specified in RFC 5225.

Saturday 19 May 2012

SPS and TTI Bundling Example

I have blogged about Semi-Persistent Scheduling (SPS) and Transmit Time Interval (TTI) Bundling feature before. They are both very important for VoIP and VoLTE to reduce the signalling overhead.



It should be noted that as per RRC Specs, SPS and TTI Bundling is mutually exclusive. The following from RRC specs:

TTI bundling can be enabled for FDD and for TDD only for configurations 0, 1 and 6. For TDD, E-UTRAN does not simultaneously enable TTI bundling and semi-persistent scheduling in this release of specification. Furthermore, E-UTRAN does not simultaneously configure TTI bundling and SCells with configured uplink.

Wednesday 25 April 2012

Signalling Load per device and OS

From the presentation by Martin Prosek, Telefonica, Czech Republic in 3G Optimization Conference 2012, Prague.




Signalling can cause many issues:

In the mobile device, Frequent PDP-context establishment is known to drain the battery. Battery life can be improved by supporting fast dormancy in network.

In the network, Signalling flood can create situations reminding DoS attacks. Increased signalling in RAN can cause impacts in core network:

  • Radius/Diameter interface overload of AAA servers
  • DHCP IP address pools exhaustion


Thursday 19 April 2012

The concept of 'PDP Context Parking'




Access Point Name (APN) identifies a packet data network (PDN) that is configured on and accessible from the packet core (eg. GGSN). APNs are similar to a DNS name of the packet core and its composed of 2 parts.

• The APN Network Identifier which defines the external network or service that the user wishes to connect to via the packet core.
• The APN Operator Identifier which defines in which mobile network the packet core is located.

The APN that a mobile user is allowed to use is either programmed in the phone, or it could be sent over the air (OTA) via SMS. If an invalid APN is used then the PDP context request would be rejected with Invalid APN cause.

The networks of today are capable of handling any APN name and in fact recently I read some operator will allow any APN name to be used (PS: I cant remember details so please feel free to add link in the comment if you know). The reason for any APNs is that users use mobiles that were used on other networks which would have their APN settings, so the operator allows them to use any APN and then send OTA message to provide new settings.

The problem starts on these devices of today, even though you may say that you dont want to use operator data (especially while roaming), it still uses data and if the user does not have a good data plan then he may end up running a huge bill. See a discussion on this topic here and here.

From operators point of view, once they have sent setting OTA then they dont send it again. The users have come up with a workaround that they can use an invalid APN name and that would not connect to the operators network and incur data costs. The problem is that since the PDP Context request was now rejected, the device retries it when the device tries to use data again (mostly when there is no WiFi due to user being out and background apps are still running). This can cause loads of unnecessary signalling (for establishing PDP context).

In a situation like this, Martin Prosek from Telefonica, Czech Republic, mentioned that they have introduced 'PDP Context Parking'. They accept the PDP context request even though the APN is invalid but redirect the user to a default page where the user has many options like name of correct APN for someone using wrong APN by mistake, possiblity to buy 'bolt-ons' so they can use data over the mobile network and in some cases simply some free data allowance so that the users can get a feel of mobile data usage. This helped Telefonica O2, Czech Republic, reduce signaling and improve pdp connection success rate

I think this is a great idea and if someone has more information on this or personal experience, please feel free to add.

Friday 24 February 2012

'Mapped Security' Concept in LTE


When a UE registers on a network in 2G/3G or LTE, it has to perform Authentication. The Authentication Vectors are located in the USIM for the device and in Authentication Center (AuC) in the network. Once the Authentication is performed successfully, then the Keys for Ciphering and Integrity are derived and used during the call.

As I showed in my earlier post here, It is possible that the same AuC is used for 2G/3G and LTE networks. In this case if the UE has recently performed Authentication in one network then unless the keys are old, there is no need to perform the Authentication again in the other radio access technology (RAT). The Security keys (Ciphering and Integrity key) would be derived based on the keys in the previous RAT. 3GPP TS 33.102 and 3GPP TS 33.401 gives the details on how to derive the key from the previous RAT while in the new RAT using this mapped security concept.

Monday 13 February 2012

Fast Dormancy Timings

Nearly a year and half back, I posted a blog about Fast Dormancy here. This issue has surely been fixed in most of the devices and the networks are able to handle the issue even if the handsets have not been fixed. I found an interesting table in a Huawei journal that shows the timings used by different devices that are being reproduced for people who may be interested.

Wednesday 30 November 2011

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

Tuesday 1 November 2011

RRC Signalling in Rel-10 for MDT

Last year I wrote about Minimization of Drive Testing (MDT) and mentioned about the possibility of enhancements. Now looking at the new RRC specs I can see a new message LoggedMeasurementsConfiguration has been added,
When the UE is in RRC_CONNECTED mode, this message can be sent and the UE be informed about the measurements to be performed. The message contents are as follows:

LoggedMeasurementConfiguration-r10 ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE {
loggedMeasurementConfiguration-r10 LoggedMeasurementConfiguration-r10-IEs,
spare3 NULL, spare2 NULL, spare1 NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}


LoggedMeasurementConfiguration-r10-IEs ::= SEQUENCE {
traceReference-r10 TraceReference-r10,
traceRecordingSessionRef-r10 OCTET STRING (SIZE (2)),
tce-Id-r10 OCTET STRING (SIZE (1)),
absoluteTimeInfo-r10 AbsoluteTimeInfo-r10,
areaConfiguration-r10 AreaConfiguration-r10 OPTIONAL, -- Need OR
loggingDuration-r10 LoggingDuration-r10,
loggingInterval-r10 LoggingInterval-r10,
nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP
}


Once the UE has done the measurements, it can inform the network in one of the following messages, RRCConnectionSetupComplete, RRCConnectionReestablishmentComplete, RRCConnectionReconfigurationComplete and UEInformationResponse that it has the required information available. This is done by including the following new Enum:

logMeasAvailable-r10 ENUMERATED {true} OPTIONAL,

Finally, the network can request the logged Measurements information in the UE Information Request Message. The new fields for that are:


UEInformationRequest-v1020-IEs ::= SEQUENCE {
logMeasReportReq-r10 ENUMERATED {true} OPTIONAL,
nonCriticalExtension SEQUENCE {} OPTIONAL
}

The UE would send the following information in the response message:


LogMeasInfo-r10 ::= SEQUENCE {
locationInfo-r10 LocationInfo-r10 OPTIONAL,
relativeTimeStamp-r10 INTEGER (0..7200),
servCellIdentity-r10 CellGlobalIdEUTRA,
measResultServCell-r10 SEQUENCE {
rsrpResult-r10 RSRP-Range,
rsrqResult-r10 RSRQ-Range
},
measResultNeighCells-r10 SEQUENCE {
measResultListEUTRA-r10 MeasResultList2EUTRA-r9 OPTIONAL,
measResultListUTRA-r10 MeasResultList2UTRA-r9 OPTIONAL,
measResultListGERAN-r10 MeasResultList2GERAN-r10 OPTIONAL,
measResultListCDMA2000-r10 MeasResultList2CDMA2000-r9 OPTIONAL
} OPTIONAL,
...
}


MeasResultList2GERAN-r10 ::= SEQUENCE (SIZE (1..maxCellListGERAN)) OF MeasResultListGERAN


LocationInfo-r10 ::= SEQUENCE {
locationCoordinates-r10 CHOICE {
ellipsoid-Point-r10 OCTET STRING,
ellipsoidPointWithAltitude-r10 OCTET STRING,
...
},
horizontalVelocity-r10 OCTET STRING OPTIONAL,
gnss-TOD-msec-r10 OCTET STRING OPTIONAL,
...
}

Tuesday 13 September 2011

CELL_FACH to LTE Mobility

At the moment, transition from RRC states from UMTS to LTE can happen from CELL_DCH to E-UTRA_RRC_CONNECTED state via Handover or from UTRA_IDLE to E-UTRA_RRC_IDLE via Cell Reselection. There is a study ongoing to transition from CELL_FACH to LTE. The state has not been specified but my guess is that it would probably be E-UTRA_RRC_CONNECTED. The following is the reasoning based on RP-111208:

It is our understanding that some of the Cell_FACH enhancement proposals for Release 11 are targeted to make it more attractive to keep UEs longer in the Cell_FACH state than is expected with pre-Rel-11 devices. This expectation that the UEs may stay longer in the Cell_FACH state is in turn motivating the mobility from Cell_FACH state to LTE proposal.

For instance, as the network can already today release the Cell_FACH UE’s RRC Connection with redirection, network may want to redirect UE to the correct RAT and frequency based on the UE measurement. Specifically if the network strategy is to keep the UEs long time in Cell_FACH state, it would make sense to provide the network the tools to manage the UEs’ mobility in that state. In addition, the needs for mobility to LTE are somewhat different from mobility to e.g. GERAN, as the former would be typically priority based while the latter would happen for coverage reasons. Thus, if introduced, the network controlled mobility from UMTS Cell_FACH would be specifically interesting for the UMTS to LTE case.


Will update once I have more info.

Wednesday 3 August 2011

A look at "Idle state Signalling Reduction" (ISR)

The following is from 3GPP TS 23.401, Annex J:

General description of the ISR concept

Idle state Signalling Reduction (or ISR) aims at reducing the frequency of Tracking Area Updates (TAU, in EUtran) and Routing Area Updates (RAU, in UTRAN/GERAN) procedures caused by UEs reselecting between E-UTRAN and GERAN/UTRAN which are operated together. Especially the update signalling between UE and network is reduced. But also network internal signalling is reduced. To some extent the reduction of network internal signalling is also available when ISR is not used or not activated by the network.

UMTS described already RAs containing GERAN and UTRAN cells, which also reduces update signalling between UE and network. The combination of GERAN and UTRAN into the same RAs implies however common scaling, dimensioning and configuration for GERAN and UTRAN (e.g. same RA coverage, same SGSN service area, no GERAN or UTRAN only access control, same physical node for GERAN and UTRAN). As an advantage it does not require special network interface functionality for the purpose of update signalling reduction.

ISR enables signalling reduction with separate SGSN and MME and also with independent TAs and RAs. Thereby the interdependency is drastically minimized compared with the GERAN/UTRAN RAs. This comes however with ISR specific node and interface functionality. SGSN and MME may be implemented together, which reduces some interface functions but results also in some dependencies.

ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for the network. ISR requires special functionality in both the UE and the network (i.e. in the SGSN, MME and Serving GW) to activate ISR for a UE. For this activation, the MME/SGSN detects whether S-GW supports ISR based on the configuration and activates ISR only if the S-GW supports the ISR. The network can decide for ISR activation individually for each UE. Gn/Gp SGSNs do not support ISR functionality. No specific HSS functionality is required to support ISR.

NOTE. A Release 7 HSS needs additional functionality to support the 'dual registration' of MME and SGSN. Without such an upgrade, at least PS domain MT Location Services and MT Short Messages are liable to fail.

It is inherent functionality of the MM procedures to enable ISR activation only when the UE is able to register via E-UTRAN and via GERAN/UTRAN. For example, when there is no E-UTRAN coverage there will be also no ISR activation. Once ISR is activated it remains active until one of the criteria for deactivation in the UE occurs, or until SGSN or MME indicate during an update procedure no more the activated ISR, i.e. the ISR status of the UE has to be refreshed with every update.

When ISR is activated this means the UE is registered with both MME and SGSN. Both the SGSN and the MME have a control connection with the Serving GW. MME and SGSN are both registered at HSS. The UE stores MM parameters from SGSN (e.g. P-TMSI and RA) and from MME (e.g. GUTI and TA(s)) and the UE stores session management (bearer) contexts that are common for E-UTRAN and GERAN/UTRAN accesses. In idle state the UE can reselect between E-UTRAN and GERAN/UTRAN (within the registered RA and TAs) without any need to perform TAU or RAU procedures with the network. SGSN and MME store each other's address when ISR is activated.

When ISR is activated and downlink data arrive, the Serving GW initiates paging processes on both SGSN and MME. In response to paging or for uplink data transfer the UE performs normal Service Request procedures on the currently camped-on RAT without any preceding update signalling (there are however existing scenarios that may require to perform a RAU procedure prior to the Service Request even with ISR is activated when GERAN/UTRAN RAs are used together, as specified in clause 6.13.1.3 of TS 23.060 [7]).

The UE and the network run independent periodic update timers for GERAN/UTRAN and for E-UTRAN. When the MME or SGSN do not receive periodic updates MME and SGSN may decide independently for implicit detach, which removes session management (bearer) contexts from the CN node performing the implicit detach and it removes also the related control connection from the Serving GW. Implicit detach by one CN node (either SGSN or MME) deactivates ISR in the network. It is deactivated in the UE when the UE cannot perform periodic updates in time. When ISR is activated and a periodic updating timer expires the UE starts a Deactivate ISR timer. When this timer expires and the UE was not able to perform the required update procedure the UE deactivates ISR.

Part of the ISR functionality is also available when ISR is not activated because the MM contexts are stored in UE, MME and SGSN also when ISR is not active. This results in some reduced network signalling, which is not available for Gn/Gp SGSNs. These SGSNs cannot handle MM and session management contexts separately. Therefore all contexts on Gn/Gp SGSNs are deleted when the UE changes to an MME. The MME can keep their MME contexts in all scenarios.

Note:
Gn = IP Based interface between SGSN and other SGSNs and (internal) GGSNs. DNS also shares this interface. Uses the GTP Protocol.
Gp = IP based interface between internal SGSN and external GGSNs. Between the SGSN and the external GGSN, there is the border gateway (which is essentially a firewall). Also uses the GTP Protocol.


"Temporary Identity used in Next update" (TIN)

The UE may have valid MM parameters both from MME and from SGSN. The "Temporary Identity used in Next update" (TIN) is a parameter of the UE's MM context, which identifies the UE identity to be indicated in the next RAU Request or TAU Request message. The TIN also identifies the status of ISR activation in the UE.

The TIN can take one of the three values, "P-TMSI", "GUTI" or "RAT-related TMSI". The UE sets the TIN when receiving an Attach Accept, a TAU Accept or RAU Accept message as specified in table 4.3.5.6-1.


"ISR Activated" indicated by the RAU/TAU Accept message but the UE not setting the TIN to "RAT-related TMSI" is a special situation. By maintaining the old TIN value the UE remembers to use the RAT TMSI indicated by the TIN when updating with the CN node of the other RAT.

Only if the TIN is set to "RAT-related TMSI" ISR behaviour is enabled for the UE, i.e. the UE can change between all registered areas and RATs without any update signalling and it listens for paging on the RAT it is camped on. If the TIN is set to "RAT-related TMSI", the UE's P-TMSI and RAI as well as its GUTI and TAI(s) remain registered with the network and valid in the UE.

When ISR is not active the TIN is always set to the temporary ID belonging to the currently used RAT. This guarantees that always the most recent context data are used, which means during inter-RAT changes there is always context transfer from the CN node serving the last used RAT. The UE identities, old GUTI IE and additional GUTI IE, indicated in the next TAU Request message, and old P-TMSI IE and additional P-TMSI/RAI IE, indicated in the next RAU Request message depend on the setting of TIN.

The UE indicates also information elements "additional GUTI" or "additional P-TMSI" in the Attach Request, TAU or RAU Request. These information elements permit the MME/SGSN to find the already existing UE contexts in the new MME or SGSN, when the "old GUTI" or "old P-TMSI" indicate values that are mapped from other identities.


ISR activation

The information flow in Figure below shows an example of ISR activation. For explanatory purposes the figure is simplified to show the MM parts only.

The process starts with an ordinary Attach procedure not requiring any special functionality for support of ISR. The Attach however deletes any existing old ISR state information stored in the UE. With the Attach request message, the UE sets its TIN to "GUTI". After attach with MME, the UE may perform any interactions via E-UTRAN without changing the ISR state. ISR remains deactivated. One or more bearer contexts are activated on MME, Serving GW and PDN GW, which is not shown in the figure.

The first time the UE reselects GERAN or UTRAN it initiates a Routing Area Update. This represents an occasion to activate ISR. The TIN indicates "GUTI" so the UE indicates a P-TMSI mapped from a GUTI in the RAU Request. The SGSN gets contexts from MME. When the MME sends the context to the SGSN, the MME includes the ISR supported indication only if the involved S-GW supports the ISR. After the ISR activated, both CN nodes keep these contexts because ISR is being activated. The SGSN establishes a control relation with the Serving GW, which is active in parallel to the control connection between MME and Serving GW (not shown in figure). The RAU Accept indicates ISR activation to the UE. The UE keeps GUTI and P-TMSI as registered, which the UE memorises by setting the TIN to "RAT-related TMSI". The MME and the SGSN are registered in parallel with the HSS.

After ISR activation, the UE may reselect between E-UTRAN and UTRAN/GERAN without any need for updating the network as long as the UE does not move out of the RA/TA(s) registered with the network.

The network is not required to activate ISR during a RAU or TAU. The network may activate ISR at any RAU or TAU that involves the context transfer between an SGSN and an MME. The RAU procedure for this is shown in Figure above. ISR activation for a UE, which is already attached to GERAN/UTRAN, with a TAU procedure from E-UTRAN works in a very similar way.

Reference: 3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

Wednesday 27 July 2011

MRO: Handover failures signalling

Continuing on the Self-organising Network (SON) feature of Mobility Robust Optimisation, Handover failures.


Click on image to enlarge

One of the discussions I had with a colleague is how would the signalling happen in case of Handover failures I mentioned earlier.

After the handover failure, when the connection is successfully established again either as a normal Setup or Re-Establishment or RRC Reconfiguration then a new optional field is available:

rlf-InfoAvailable-r10 ENUMERATED {true} OPTIONAL,

This is used to indicate to the network that the UE has some information relating to the RL Failure that occurred.

The network will then use the UE Information Request I blogged about earlier to ask for this information. The UE will send the information back in the response.

It should be noted that this UEInformationRequest and Response messages were introduced part of Release-9 but there has been since some updates in Release-10. The Response message now looks as follows:

RLF-Report-r9 ::= SEQUENCE {
measResultLastServCell-r9 SEQUENCE {
rsrpResult-r9 RSRP-Range,
rsrqResult-r9 RSRQ-Range OPTIONAL
},
measResultNeighCells-r9 SEQUENCE {
measResultListEUTRA-r9 MeasResultList2EUTRA-r9 OPTIONAL,
measResultListUTRA-r9 MeasResultList2UTRA-r9 OPTIONAL,
measResultListGERAN-r9 MeasResultListGERAN OPTIONAL,
measResultsCDMA2000-r9 MeasResultList2CDMA2000-r9 OPTIONAL
} OPTIONAL,
...,
[[ locationInfo-r10 LocationInfo-r10 OPTIONAL,
failedPCellId-r10 CHOICE {
cellGlobalId-r10 CellGlobalIdEUTRA,
pci-arfcn-r10 SEQUENCE {
physCellId-r10 PhysCellId,
carrierFreq-r10 ARFCN-ValueEUTRA
}
} OPTIONAL,
reestablishmentCellId-r10 CellGlobalIdEUTRA OPTIONAL,
timeConnFailure-r10 INTEGER (0..1023) OPTIONAL,
connectionFailureType-r10 ENUMERATED {rlf, hof} OPTIONAL,
previousPCellId-r10 CellGlobalIdEUTRA OPTIONAL
]]
}

Everything after the extension marker ellipses (...) is added in release 10. More information in Release-10 RRC specs (36.331)

Monday 25 July 2011

Femto Hacking in UMTS and LTE

Couple of weeks back, The Hacker’s Choice (THC) made available some documents about how the Vodafone's (UK) Femtocell (a.k.a. SureSignal) is unsecure and can be hacked. Everyone seemed to jump on this bandwagon with some news articles even sounding like the whole Vodafone network has been hacked and hackers may be sending messages and making calls via your phone number.

In the end it came to light that the problem was fixed over a year back when Vodafone was made aware of this problem. THC is still arguing that there is an architecture fault and the Femto can be compromised.

As a result I decided to think about what could happen if the Femtocell is hacked.

Lets take case of UMTS Femtocell. A simple network architecture with femtocell (oficially known as Home NodeB) is as follows:

As you can see, the signalling over the air interface is encrypted and integrity protected. If a hacker is able to get into the Femto and able to listen to all the packets using some tool like WireShark, he would be able to get hold of the Ciphering and Integrity Keys as they come in cleartext in the RANAP Security Mode Command message.

It wouldnt be difficult to have a device that can listen to the conversations once provided with this keys. In fact if the hacker is able to listen to the messages, there is no reason he cannot stick his own messages at the right interval (when a voice call is ongoing) to send SMS and would appear that the message actually went from the phone number. Note that this message would be inserted in the Home NodeB and would be a NAS message. The end user would generally never find out that a message has been sent on behalf of his phone.

One thing that should be remembered though is that the phone would have to be in the range of the Femtocell and connected successfully to the network (via the Femto). One question someone may have is that can I not reverse engineer the key so that I can clone the SIM card. Fortunately for us, this is not easily possible. There are multiple levels of protection and generally it would be difficult to get the algorithms for generating the key. Also it should be noted that the authentication algorithms are confidential and only the operators know the algorithm.


Now lets look at the LTE Femtocell (a.k.a. Home eNodeB) as shown below:

One of the differences you may notice is that the signalling from Femto to the Core Network over S1 is encrypted and Integrity Protected. In case of the LTE Femto, there are multiple keys and only the required key (Kenb) is provided to the Femto. See the key hierarchy below:

Source: RedYoda

This would sound like an ideal protection from the end user perspective but some of the problems still remain. If the hacker can get hold of the Kenb which is sent in cleartext over the S1 interface via Initial Context Setup Request message then he could easily use it to listen to the packets. Since there is no voice support as of yet in LTE, it would only be the packets that the hacker can listen to.

As you may notice, there is now an Integrity and Ciphering on the S1 interface for the UE messages, the hacker cannot get hold of the Kasme or the master keys K, CK and IK. This means that he cannot insert rouge messages that would for example send unsolicited SMS on behalf of the user as he would be able to do in case of UMTS.

There is a small caveat though. There are multiple Ciphering and Integrity algorithms defined in the standard. No ciphering is defined as eea0 algorithm. In Release-8 of LTE, there was no possibility to have Integrity switched off as there was no eia0 algorithm defined. In Release-9 though, the new eia0 has been defined which means that the network can set the Integrity to NULL. I am sure that the network would not want to do so as it makes absolutely no sense but the hacker can force it to do so.

When the Network requests the UE to send the capability information, the hacker can force it to say that it only supports eia0 and eea0 which would mean that the integrity and ciphering in the call would be off. To be honest, this is quite a difficult thing to do in real time and also the network would not accept a UE that does not support other Integrity and Ciphering algorithms.


3GPP has already forseen these kind of threats that could be affecting the networks in the future when they roll out the Femtocells. As a result they have produced 3GPP TR 33.820 that lists all the possible threats and the best practices that can help to minimise the chances of the network being compromised. If that document is too big and technical, you can go though this presentation as it summarises some of the problems.

Feel free to comment or correct any mistakes that you think I have made.

Friday 22 July 2011

Mobility Robustness Optimization to avoid Handover failures

The following is from 4G Americas Whitepaper on SON:


Mobility Robustness Optimization (MRO) encompasses the automated optimization of parameters affecting active mode and idle mode handovers to ensure good end-user quality and performance, while considering possible competing interactions with other SON features such as, automatic neighbor relation and load balancing.

There is also some potential for interaction with Cell Outage Compensation and Energy Savings as these could also potentially adjust the handover boundaries in a way that conflicts with MRO. While the goal of MRO is the same regardless of radio technology namely, the optimization of end-user performance and system capacity, the specific algorithms and parameters vary with technology.

The objective of MRO is to dynamically improve the network performance of HO (Handovers) in order to provide improved end-user experience as well as increased network capacity. This is done by automatically adapting cell parameters to adjust handover boundaries based on feedback of performance indicators. Typically, the objective is to eliminate Radio Link Failures and reduce unnecessary handovers. Automation of MRO minimizes human intervention in the network management and optimization tasks.

The scope of mobility robustness optimization as described here assumes a well-designed network with overlapping RF coverage of neighboring sites. The optimization of handover parameters by system operators typically involves either focused drive-testing, detailed system log collection and postprocessing, or a combination of these manual and intensive tasks. Incorrect HO parameter settings can negatively affect user experience and waste network resources by causing HO ping-pongs, HO failures and Radio Link Failures (RLF). While HO failures that do not lead to RLFs are often recoverable and invisible to the user, RLFs caused by incorrect HO parameter settings have a combined impact on user experience and network resources. Therefore, the main objective of mobility robustness optimization should be the reduction of the number of HO-related radio link failures. Additionally, sub-optimal configuration of HO parameters may lead to degradation of service performance, even if it does not result in RLFs. One example is the incorrect setting of HO hysteresis, which may results in ping-pongs or excessively delayed handovers to a target cell. Therefore, the secondary objective of MRO is the reduction of the inefficient use of network resources due to unnecessary or missed handovers.

Most problems associated with HO failures or sub-optimal system performance can ultimately be categorized, as either too-early or too-late triggering of the handover, provided that the required fundamental network RF coverage exists. Thus, poor HO-related performance can generally be categorized by the following events:

* Intra-RAT late HO triggering
* Intra-RAT early HO triggering
* Intra-RAT HO to an incorrect cell
* Inter-RAT too late HO
* Inter RAT unnecessary HO

Up to Release 9, a UE is required to send RLF report only in case of successful RRC re-establishment after a connection failure. Release 10 allows support for RLF reports to be sent even when the RRC reestablishment does not succeed. The UE is required to report additional information to assist the eNB in determining if the problem is coverage related (no strong neighbors) or handover problems (too early, too late or wrong cell). Furthermore, Release 10 allows for precise detection of too early / wrong cell HO.

Sunday 17 July 2011

Network Mode of Operation (NMO)

Picture Source: Tektronix

The Network Mode of Operation (NMO) is also sometimes referred to as Network Operation Mode (NOM). The Network Modes have different values and interpretation in UTRAN and GERAN

In both the cases the Operation modes is decided based on the Gs interface between the CS CN (core network) a.k.a. MSC and the PS CN a.k.a. SGSN

In UTRAN:

Network Operation Mode I (NMO-I) is used when the Gs interface is present. In this case during the registration a Combined Attach (includes GPRS Attach & IMSI Attach procedures) procedure can be performed. A GMM Attach Request message with the attach type set to Combined Attach is used. Upon completion of this procedure, MM Status is IMSI Attached and GMM State is Attached.

In Network Operation Mode II (NMO-II) the GS Interface is not present. So the GMM attach procedure and the IMSI Attach (via Location Update) has to be performed seperately. This causes additional signalling.

Basic air interface signalling in case of NMO2 is shown here.


In GERAN:

Network operation mode 1. A network which has the Gs interface implemented is referred to as being in network operation mode 1. CS and PS paging is coordinated in this mode of operation on either the GPRS or the GSM paging channel. If the mobile device has been assigned a data traffic channel then CS paging will take place over this data channel rather than the paging channel (CS or PS).

Network operation mode 2. The Gs interface is not present and there is no GPRS paging channel present. In this case, paging for CS and PS devices will be transferred over the standard GSM common control channel (CCCH) paging channel. Even if the mobile device has been assigned a packet data channel, CS paging will continue to take place over the CCCH paging channel and thus monitoring of this channel is still required.

Network operation mode 3. The Gs interface is not present. CS paging will be transferred over the CCCH paging channel. PS paging will be transferred over the packet CCCH (PCCCH) paging channel, if it exists in the cell. In this case the mobile device needs to monitor both the paging channels.

The GERAN part above is extract from the book Convergence Technologies for 3G Networks.


The Gs interface, has a number of subtle but important advantages:

During an ongoing GPRS / EDGE data transfer (TBF established), mobiles can't detect incoming voice calls and SMS messages as they are focused on receiving packets and thus can not observe the paging channel. In NMO-1, the circuit switched part of the network forwards the paging message to the packet switched side of the network which then forwards the paging message between the user data blocks while a data transfer is ongoing. Mobiles can thus receive the paging message despite the ongoing data transfer, interrupt the session and accept the voice call or SMS.

Location/Routing area updates when moving to a cell in a different location/routing area are performed much faster as the mobile only communicates with the packet switched part of the network. The packet switched network (the SGSN) then forwards the location update to the circuit switched part of the network (to the MSC) which spares the mobile from doing it itself. This is especially important for ongoing data transfers as these are interrupted for a shorter period of time.

Cell reselections from UMTS to GPRS can be executed much faster due to the same effect as described in the previous bullet. Whithout NOM-1 an Inter RAT (Radio Access Technology) cell reselection with Location and Routing Area update requires around 10 to 12 seconds. With NOM-1 the time is reduced to around 5 to 6 seconds. An important difference as this reduces the chance to miss an incoming call during the change of the radio network. Also, ongoing data transfers are interrupted for a shorter time,an additional benefit that should not be underestimated.


Wednesday 9 March 2011

ETWS detailed in LTE and UMTS

Its been couple of years since the introductory post on 3GPP Earthquake and Tsunami Warning service (ETWS). The following is more detailed post on ETWS from the NTT Docomo technical journal.

3GPP Release 8 accepted the standard technical specification for warning message distribution platform such as Area Mail, which adopts pioneering technology for faster distribution, in order to fulfil the requirements concerning the distribution of emergency information e.g. earthquakes, tsunamis and so on in LTE/EPC. The standard specifies the delivery of emergency information in two levels. The Primary Notification contains the minimum, most urgently required information such as “An earthquake occurred”; the Secondary Notification includes supplementary information not contained in the Primary Notification, such as seismic intensity, epicentre, and so on. This separation allows implementation of excellent information distribution platforms that can achieve the theoretically fastest speed of the warning distribution.

The purpose of the ETWS is to broadcast emergency information such as earthquake warnings provided by a local or national governments to many mobile terminals as quickly as possible by making use of the characteristic of the widespread mobile communication networks.

The ETWS, in the same way as Area Mail, detects the initial slight tremor of an earthquake, the Primary Wave (P wave - The first tremor of an earthquake to arrive at a location), and sends a warning message that an earthquake is about to happen to the mobile terminals in the affected area. ETWS can deliver the first notification to mobile terminals in the shortest theoretical time possible in a mobile communication system (about four seconds after receiving the emergency information from the local or national government), which is specified as a requirement by 3GPP.

The biggest difference between Area Mail and the ETWS is the disaster notification method (Figure 1). Earthquake warnings in Area Mail have a fixed-length message configuration that notifies of an earthquake. ETWS, on the other hand, achieves distribution of the highest priority information in the shortest time by separating out the minimum information that is needed with the most urgency, such as “Earthquake about to happen,” for the fastest possible distribution as a Primary Notification; other supplementary information (seismic intensity, epicentre, etc.) is then distributed in a Secondary Notification. This distinction thus implements a flexible information distribution platform that prioritizes information distribution according to urgency.

The Primary Notification contains only simple patterned disaster information, such as “Earthquake.” When a mobile terminal receives a Primary Notification, it produces a pre-set alert sound and displays pre-determined text on the screen according to the message content to notify users of the danger. The types of disaster that a Primary Notification can inform about are specified as “Earthquake,” “Tsunami,” “Tsunami + Earthquake,” “Test” and “Other,” regardless of the type of radio access.

The Secondary Notification contains the same kind of message as does the existing Area Mail service, which is, for example, textual information distributed from the network to the mobile terminal to inform of the epicentre, seismic intensity and other such information. That message also contains, in addition to text, a Message Identifier and Serial Number that identifies the type of disaster.

A major feature of the ETWS is compatibility with international roaming. Through standardization, mobile terminals that can receive ETWS can receive local emergency information when in other countries if the local network provides the ETWS service. These services are provided in a manner that is common to all types of radio access (3G, LTE, etc.).

Network Architecture

The ETWS platform is designed based on the Cell Broadcast Service (CBS). The ETWS network architecture is shown in Figure 2. Fig. 2 also shows the architecture for 3G network to highlight the features differences between LTE and 3G.

In the ETWS architecture for 3G, a Cell Broadcast Centre (CBC), which is the information distribution server, is directly connected to the 3G Radio Network Controller (RNC). The CBC is also connected to the Cell Broadcast Entity (CBE), which distributes information from the Meteorological Agency and other such sources.

In an LTE radio access network, however, the eNodeB (eNB) is directly connected to the core network, and eNB does not have a centralized radio control function as the one provided by the RNC of 3G. Accordingly, if the same network configuration as used for 3G were to be adopted, the number of eNB connected to the CBC would increase and add to the load on the CBC. To overcome that issue, ETWS for LTE adopts a hierarchical architecture in which the CBC is connected to a Mobility Management Entity (MME).

The MME, which acts as a concentrator node, is connected to a number of eNBs. This architecture gives advantages to the network, such as reducing the load in the CBC and reducing the processing time, and, thus preventing delay in distribution.

Message Distribution Area

In the 3G ETWS and Area Mail systems, the distribution area can be specified only in cell units, which creates the issue of huge distribution area database in CBC. In LTE ETWS, however, the distribution area is specified in three different granularities (Figure 3). This allows the operator to perform area planning according to the characteristic of the warning/emergency occasions, e.g. notice of an earthquake with a certain magnitude needs to be distributed in a certain width of area, thus allowing efficient and more flexible broadcast of the warning message.

1) Cell Level Distribution Area: The CBC designates the cell-level distribution areas by sending a list of cell IDs. The emergency information is broadcasted only to the designated cells. Although this area designation has the advantage of being able to pinpoint broadcast distribution to particular areas, it necessitates a large processing load in the network node (CBC, MME and eNB) especially when the list is long.

2) TA Level Distribution Area: In this case, the distribution area is designated as a list of Tracking Area Identities (TAIs). TAI is an identifier of a Tracking Area (TA), which is an LTE mobility management area. The warning message broadcast goes out to all of the cells in the TAIs. This area designation has the advantage of less processing load when the warning message has to be broadcast to relatively wide areas.

3) EA Level Distribution Area: The Emergency Area (EA) can be freely defined by the operator. An EA ID can be assigned to each cell, and the warning message can be broadcasted to the relevant EA only. The EA can be larger than a cell and is independent of the TA. EA is a unit of mobility management. EA thus allows flexible design for optimization of the distribution area for the affected area according to the type of disaster.




Message Distribution

The method of distributing emergency information to LTE radio networks is shown in Figure 4. When the CBC receives a request for emergency information distribution from CBE, it creates the text to be sent to the terminals and specifies the distribution area from the information in the request message (Fig. 4 (1) (2)).

Next, the CBC sends a Write-Replace Warning Request message to the MME of the specified area. This message contains information such as disaster type, warning message text, message distribution area, Primary Notification information, etc. (Fig. 4 (3)). When the MME receives this message, it sends a response message to the CBC to notify that the message was correctly received. The CBC then notifies the CBE that the distribution request was received and the processing has begun (Fig. 4 (4) (5)). At the same time, the MME checks the distribution area information in the received message (Fig. 4 (6)) and, if a TAI list is included, it sends the Write-Replace Warning Request message only to the eNB that belong to the TAI in the list (Fig. 4 (7)). If the TAI list is not included, the message is sent to all of the eNB to which the MME is connected.

When the eNB receives the Write-Replace Warning Request message from the MME, it determines the message distribution area based on the information included in the Write-Replace Warning Request message (Fig. 4 (8)) and starts the broadcast (Fig. 4 (9) (10)). The following describes how the eNB processes each of the specified information elements.

1) Disaster Type Information (Message Identifier/Serial Number): If an on-going broadcast of a warning message exists, this information is used by the eNB to decide whether it shall discard the newly received message or overwrite the ongoing warning message broadcast with the newly received one. Specifically, if the received request message has the same type as the message currently being broadcasted, the received request message is discarded. If the type is different from the message currently being broadcast, the received request message shall overwrite the ongoing broadcast message and the new warning message is immediately broadcasted.

2) Message Distribution Area (Warning Area List): When a list of cells has been specified as the distribution area, the eNB scans the list for cells that it serves and starts warning message broadcast to those cells. If the message distribution area is a list of TAIs, the eNB scans the list for TAIs that it serves and starts the broadcast to the cells included in those TAIs. In the same way, if the distribution area is specified as an EA (or list of EAs), the eNB scans the EA ID list for EA IDs that it serves and starts the broadcast to the cells included in the EA ID.

If the received Write-Replace Warning Request message does not contain distribution area information, the eNB broadcasts the warning message to all of the cells it serves.

3) Primary Notification Information: If Primary Notification information indication exists, that information is mapped to a radio channel that is defined for the broadcast of Primary Notification.

4) Message Text: The eNB determines whether or not there is message text and thus whether or not a Secondary Notification needs to be broadcasted. If message text exists, that text is mapped to a radio channel that is defined for the broadcast of Secondary Notification. The Secondary Notification is broadcast according to the transmission intervals and number of transmissions specified by the CBC. Upon the completion of a broadcast, the eNB returns the result to the MME (Fig. 4 (11)).


Radio Function Specifications

Overview : In the previous Area Mail service, only mobile terminals in the standby state (RRC_IDLE) could receive emergency information, but in ETWS, emergency information can be received also by mobile terminals in the connected state (RRC_CONNECTED), and hence the information can be delivered to a broader range of users. In LTE, when delivering emergency information to mobile terminals, the eNB sends a bit in the paging message to notify that emergency information is to be sent (ETWS indication), and sends the emergency information itself as system information broadcast. In 3G, on the other hand, the emergency information is sent through the paging message and CBS messages.

Message Distribution method for LTE: When the eNB begins transmission of the emergency information, a paging message in which the ETWS indication is set is sent to the mobile terminal. ETWS-compatible terminals, whether in standby or connected, try to receive a paging message at least once per default paging cycle, whose value is specified by the system information broadcast and can be set to 320 ms, 640 ms, 1.28 s or 2.56 s according to the 3GPP specifications. If a paging message that contains an ETWS indication is received, the terminal begins receiving the system information broadcast that contains the emergency information. The paging message that has the ETWS indication set is sent out repeatedly at every paging opportunity, thus increasing the reception probability at the mobile terminal.

The ETWS message itself is sent as system information broadcast. Specifically, the Primary Notification is sent as the Warning Type in System Information Block Type 10 (SIB10) and the Secondary Notification is sent as a Warning Message in SIB11. By repeated sending of SIB10 and SIB11 (at an interval that can be set to 80 ms, 160 ms, 320 ms, 640 ms, 1.28 s, 2.56 s, or 5.12 s according to the 3GPP specifications), the probability of the information being received at the residing mobile terminal can be increased. In addition, the SIB10 and SIB11 scheduling information is included in SIB1 issued at 80-ms intervals, so mobile terminals that receive the ETWS indication try to receive SIB10 and SIB11 after first having received the SIB1. By checking the disaster type information (Message Identifier and Serial Number) contained in SIB10 and SIB11, the mobile terminal can prevent the receiving of multiple messages that contain the same emergency information.

3G Message Distribution Method: For faster information delivery and increased range of target uers in 3G also, the CBS message distribution control used in Area Mail was enhanced. An overview of the 3G radio system is shown in Figure 5.

In the Area Mail system, a Common Traffic Channel (CTCH) logical channel is set up in the radio link, and emergency information distribution is implemented by sending CBS messages over that channel. To inform the mobile terminals that the CTCH logical channel has been set up, the RNC orders the base station (BTS) to set the CTCH Indicator information element in the system information broadcast to TRUE, and transmits the paging message indicating a change in the system information broadcast to the mobile terminals. When the mobile terminal receives the CTCH Indicator, it begins monitoring the CTCH logical channel and can receive CBS messages.

In ETWS, by including the Warning Type in the paging message indicating a change in the system information broadcast, processing for a pop-up display and alert sound processing (Primary Notification) at the mobile terminals according to the Warning Type can be executed in parallel to the processing at the mobile terminals to start receiving the CBS messages. This enhancement allows users whose terminals are in the connected state (RRC_CONNECTED) to also receive emergency information. In the previous system, it was not possible for these users to receive emergency information. Also including disaster type information (Message Identifier and Serial Number) in this paging message makes it possible to prevent receiving multiple messages containing the same emergency information at the mobile terminal.

More detailed information (Secondary Notification) is provided in CBS messages in the same way as in the conventional Area Mail system, thus achieving an architecture that is common to ETWS users and Area Mail users.

Thursday 3 March 2011

LTE to 3G Handover Procedure and Signalling

It may be worthwhile brushing up the LTE/SAE Interfaces and Architecture before proceeding.

1) Overview of Handover Operation

With EPC, continuous communication is possible, even while the terminal switches from one type of radio access system to another.

Specifically, in order to achieve the internal network path switching required to change radio access systems, the S-GW provides a mobility management anchor function for handover between 3GPP radio access systems, and the P-GW provides the function for handover between 3GPP and non-3GPP radio access systems. In this way, the IP address does not change when the terminal switches radio access systems, and communications can continue after handover.



In handover between the 3GPP radio access systems, LTE and 3G, handover preparation is done before changing systems, including tasks such as securing resources on the target radio access system, through cooperation between the radio access systems (Figure 3 (a)(A)). Then, when the actual switch occurs, only the network path needs to be switched, reducing handover processing time (Fig.3 (a)(B)). Also, loss of data packets that arrive at the pre-switch access point during handover can be avoided using a data forwarding function (Fig.3 (b)).

In this way, through interaction between radio access systems, fast handover without packet loss is possible, even between radio access systems such as LTE and 3G which cannot be used simultaneously.

2) Handover Preparation Procedure (Fig.3 (a)(A))

The handover preparation procedure for switching radio access from LTE to 3G is shown in Figure 4.


Step (1):The terminal sends a radio quality report containing the handover candidate base-stations and other information to the eNodeB. The eNodeB decides whether handover shall be performed based on the information in the report, identifies the base station and RNC to switch to, and begins handover preparation.

Steps (2) to (3): The eNodeB sends a handover required to the MME, sending the RNC identifier and transmission control information for the target radio access system. The MME identifies the SGSN connected to the target RNC based on the received RNC identifier and sends the communication control and other information it received from the eNodeB to the SGSN in a forward relocation request signal. The information required to configure the communications path between the S-GW and SGSN, which is used for data transmission after the MME has completed the handover, is sent at the same time.

Steps (4) to (5): The SGSN forwards the relocation request to the RNC, notifying it of the communications control information transmitted from the eNodeB. The RNC performs the required radio configuration processing based on the received information and sends a relocation response to the SGSN. Note that through this process, a 3G radio access bearer is prepared between the SGSN and RNC.

Step (6): The SGSN sends a forward relocation response to the MME in order to notify it that relocation procedure has completed. This signal also includes data issued by the SSGN and required to configure a communications path from the S-GW to the SGSN, to be used for data forwarding.

Steps (7) to (8): The MME sends a create indirect data forwarding tunnel request to the S-GW, informing it of the information issued by the SSGN that it just received. From the information that the S-GW receives, it establishes a communications path from the S-GW to the SGSN for data forwarding and sends a create indirect data forwarding tunnel response to the MME.

Through this handover preparation, target 3G radio-access resources are readied, the radio access bearer between the SGSN and RNC is configured, and the data forwarding path from the
S-GW to the SGSN configuration is completed.


3) Handover Procedure for Radio Access System Switching (Fig. 3(a)(B)):

The handover process after switching radio access system is shown in Figure 5.



Steps (1) to (2): When the handover preparation described in Fig.4 is completed, the MME sends a handover command to the eNodeB. When it receives this signal, the eNodeB sends a handover from LTE command for the terminal to switch radio systems. Note that when the eNodeB receives the handover command from the MME, it begins forwarding data packets received from the S-GW. Thereafter, packets for the terminal that arrive at the S-GW are forwarded to the terminal by the path: S-GW, eNodeB, S-GW, SGSN, RNC.

Steps (3) to (6): The terminal switches to 3G and when the radio link configuration is completed, notification that it has connected to the 3G radio access system is sent over each of the links through to the MME: from terminal to RNC, from RNC to SGSN, and from SGSN to MME. This way, the MME can perform Step (10) described below to release the eNodeB resources after a set period of time has elapsed.

Step (7): The MME sends a forward relocation complete acknowledgement to the SGSN. A set period of time after receiving this signal, the SGSN releases the resources related to data forwarding.

Step (8): The SGSN sends a modify bearer request to the S-GW to change from the communications path before the handover, between the S-GW and eNodeB, to one between the S-GW and SGSN. This signal contains information elements required to configure the path from S-GW to SGSN, including those issued by the SGSN. When the S-GW receives this signal, it configures a communications path from the S-GW to the SGSN. In this way, the communications path becomes: S-GW, SGSN, RNC, terminal; and data transmission to the target 3G radio access system begins.

Note that after this point, data forwarding is no longer needed, so the S-GW sends a packet to the eNodeB with an “End Marker” attached, and when the eNodeB receives this packet, it releases its resources related to data forwarding.

Steps (9) to (10): The S-GW sends a modify bearer response to the SGSN, indicating that handover procedure has completed. The MME also releases eNodeB resources that are no longer needed.

Through this handover procedure, data is forwarded during the handover, the switch of radio access bearer is completed, and the communications path from the P-GW to the terminal is updated.

In the examples above, we described the handover procedure between 3GPP radio access systems in which the S-GW did not change, but handovers with S-GW relocation are also possible. In these cases, the P-GW provides the anchor function for path switching, as with switches to non-3GPP access systems.

TERMS

Anchor function: A function which switches the communications path according to the area where the terminal is located, and forwards packets for the terminal to that area.

Relocation: Switching communications equipment such as area switches during communication.