TED talk: Wireless data from every light bulb

What if every light bulb in the world could also transmit data? At TEDGlobal, Harald Haas demonstrates, for the first time, a device that could do exactly that. By flickering the light from a single LED, a change too quick for the human eye to detect, he can transmit far more data than a cellular tower -- and do it in a way that's more efficient, secure and widespread.

See also :

LED-Fi: Replacement for WiFi Hotspots

Electromagnetic Radiation Spectrum charts.

Detailed presentation on Femtocell Security from Black Hat 2011

Femtocells: a Poisonous Needle in the Operator's Hay Stack

View more presentations from Zahid Ghadialy

Presentation available to download from here.

Detailed write-up on: Exploiting the Ubiquisys/SFR femtocell webserver here.

My earlier blogpost 'Femto Hacking in UMTS and LTE' here.

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

Cellphone radiation and Cancer

There is an interesting graph in Scientific American (Via Bill Gross on Google+) showing the radiation spectrum of Cell phones and other devices. Click on the image to view full size.

Thing to note: As the graphic above shows, the radiation emitted in this region is nonionizing: it may heat molecules in the body but does not ionize them (that is, set electrons free). Ionizing radiation, which can tear molecules apart and therefore potentially damage DNA—is the greater worry.

In the comments of the discussion, someone pointed out this hand drawn Electromagnetic Spectrum which is very handy.

Click to enlarge

Finally, it is worthwhile checking out the total radiation that we can encounter in different events and their relative values.

Click to enlarge.

Wi-Fi in Public Transport over LTE

Another interesting presentation from the LTE World Summit 2011 on how LTE can be used as a backhaul in the trains to provide passenger WiFi and other services.

Uses for LTE in the Transport Vertical Market

View more presentations from Zahid Ghadialy

Human Activity Recognition for Personalised services

Human Activity Recognition for Personalised Services

View more documents from Zahid Ghadialy

Interesting article from the NTT Docomo Technical journal.

How many radios are there in my phone?

Click to enlarge

From a presentation by John Haine of Cognovo in the Future of Wireless International Conference 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)

Outline of GCF Certification Process

Click on Image to enlarge

From a presentation by Colin Hamling, Vice Chair, GCF Steering Group in LTE World Summit, Amsterdam, 18 May 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.