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.

Tuesday, 17 April 2012

Release-12 Study on Integration of Single Sign-On (SSO) frameworks with 3GPP networks



This Work Item aims to provide service requirements for interworking of the operator-centric identity management with the user-centric Web services provided outside of an operator’s domain. Specifically, it addresses integration of SSO and the 3GPP services, which is essential for operators to leverage their assets and their customers’ trust, while introducing new identity services. Such integration will allow operators to become SSO providers by re-using the existing authentication mechanisms in which an end-user’s device effectively authenticates the end user.

For the operator to become the preferred SSO Identity Provider might require integration of the operator core with existing application service / content providers to allow the usage of credentials on the UE for SSO services. The 3GPP operator may leverage its trust framework and its reliable and robust secure credential handling infrastructure to provide SSO service based on operator-controlled credentials. Such SSO integration has to work with varied operator authentication configurations.

The Objective is to provide a comprehensive set of service requirements for the integration of SSO frameworks with 3GPP network by building upon the work done in the related feasibility study FS_SSO_Int (published in TR 22.895) as well as previously published related technical reports. This Work Item covers the following:

Service requirements for integration of Identity Management and SSO frameworks, e.g. OpenID;
Service requirements for Operators to enable users to access 3rd party  services using Operator controlled user credentials;
Service requirements associated with ensuring that the intended user is making use of the associated SSO capability (including the case when the UE has been stolen or lost).

3GPP TR 22.895 V12.0.0 - Study on Service aspects of integration of Single Sign-On (SSO) frameworks with 3GPP operator-controlled resources and mechanisms (Release 12) is an interesting read that provides use cases for SSO

The diagram above is from an interesting paper titled "Multi-domain authentication for IMS" that describes SSO and other authentication procedures and introduces the advantage of SSO.



Monday, 16 April 2012

LTE - THE Mobile Broadband Standard


Saw this logo in one of the 3GPP presentations. Does anyone know if this is an official logo?

Saturday, 14 April 2012

Evolution of 3GPP Security



A look at how an iPad is made

I found this interesting, how everything is nearly automated in making of these phones and tablets

Source Credit - American Public Media's 'Marketplace'.
Reporter Credit - Rob Schmitz, Shanghai Bureau Chief

It may just be a matter of time till some of the functionality that people are doing would be replaced by arm robots, like the ones in the video below that show Toyota Camry being made mostly by robots

Thursday, 12 April 2012

Whitespaces Standards


Continuing on the same topic of whitespaces from yesterday, we try and see who is working on the standardisation of whitespaces

IETF Protocol to Access White Space database (PAWS)

The charter for this WG was established 14 June 2011. Generally, the IETF strives to utilise established protocols rather than develop new ones. The objecives of this WG are:
  • Standardise a mechanism for discovering a white space database
  • Standardise a mechanism for accessing a white space database
  • Standardise query and response formats to be carried over the database access method
  • Ensure that the discovery mechanism, database access method and query response formats have appropriate security levels in place.
The WG goals are:
  • April 2012 Submit ‘Use-cases and Requirements for Accessing a Radio White Space Database’ to the IESG for publication as Informational. The current draft of this document is here: http://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/
  • December 2012, Submit ‘Accessing a Radio White Space Database’ to the IESG for publication as a Proposed Standard.

ETSI Reconfigurable Radio Systems (RRS)


The ETSI Technical Committee (TC) on Reconfigurable Radio Systems (RRS) has the responsibility for standardization activities related to Reconfigurable Radio Systems encompassing system solutions related to Software Defined Radio (SDR) and Cognitive Radio (CR), to collect and define the related Reconfigurable Radio Systems requirements from relevant stakeholders and to identify gaps, where existing ETSI standards do not fulfil the requirements, and suggest further standardization activities to fill those gaps.

IEEE Dynamic Spectrum Access Networks Standards Committee (DySPAN-SC)


The scope of the IEEE Dynamic Spectrum Access Networks Standards Committee (DySPAN-SC), which was formerly IEEE SCC41 until 2010, includes the following [1]:
  • dynamic spectrum access radio systems and networks with the focus on improved use of spectrum,
  • new techniques and methods of dynamic spectrum access including the management of radio transmission interference, and
  • coordination of wireless technologies including network management and information sharing amongst networks deploying different wireless technologies.
In December 2010 the IEEE SCC41 was re-organized as IEEE DySPAN-SC and its sponsor was changed from the IEEE Standards Coordinating Committee (SCC) to the IEEE Communications Society Standards Development Board (CSDB).
Included in the IEEE DySPAN SC are following working groups[1]:
  • 1900.1 Working Group on Definitions and Concepts for Dynamic Spectrum Access: Terminology Relating to Emerging Wireless Networks, System Functionality, and Spectrum Management
  • 1900.2 Working Group on Recommended Practice for Interference and Coexistence Analysis of In-Band and Adjacent Band Interference and Coexistence Between Radio Systems
  • 1900.4 Working Group on Architectural Building Blocks Enabling Network-Device Distributed Decision Making for Optimized Radio Resource Usage in Heterogeneous Wireless Access Networks
  • 1900.5 Working Group on Policy Language and Policy Architectures for Managing Cognitive Radio for Dynamic Spectrum Access Applications
  • 1900.6 Working Group on Spectrum Sensing Interfaces and Data Structures for Dynamic Spectrum Access and other Advanced Radio Communication Systems
  •  P1900.7 White Space Radio Working Group: Radio Interface for White Space Dynamic Spectrum Access Radio Systems Supporting Fixed and Mobile Operation
  • Ad hoc group on Dynamic Spectrum Access in Vehicular Environments (DSA-VE)
DySPAN SC is currently one of the most active standardization bodies for dynamic spectrum access radio systems and networks. 


CEPT/ECC WG Spectrum Engineering (SE), project team SE43

The ECC WGSE (Spectrum Engineering) has set up a special project dealing with cognitive radio matters. The SE43 was set up in May 2009 and finished its work in January 2011 by completing the ECC Report “Technical and Operational Requirements for the Possible Operation of Cognitive Radio Systems in the ‘White Spaces’ of the Frequency Band 470-790 MHz”The WG SE adopted the ECC Report 159 on white space devices for publication, in January 2011. This report can be downloaded from the undefinedCEPT/ECC website.

The main focus of the report is, as the title suggest, on coexistence with incumbent or primary systems. It contains definitions of “White Space”, cognitive radio and introduces the term “White Space Device” – WSD. The latter being the term used for the cognitive radio unit. The definition of “White Space” is taken from CEPT Report 24 “Technical considerations regarding harmonisation options for the Digital Dividend “ The report defines different scenarios for CR operation in terms of WSD types (personal/portable, home/office and public access points) and also discusses the three well known types of cognitive techniques: spectrum sensing, geo-location and beacons.
The report is focussed on protection of four possible incumbent systems: broadcast systems (BS), Program making and special events (PMSE), radio astronomy (RAS) and aeronautical radio navigation systems (ARNS). Comprehensive data on possible sensing and separation distances are given, and ends in operational and technical characteristics for white spaces devices to operate in the band. An estimate of available white space is also included.


Wightless


Weightless operates in an 8MHz-wide channel, to fit into the slots used for broadcast TV (and will thus have to squeeze into 6MHz if used across the pond where TV is smaller). Weightless is a Time Division Duplex (TDD) protocol, so access point and clients take turns to transmit.

When the hub device checks with the national database, it supplies a location and receives a list of 8MHz slots which aren't being used to transmit TV in that location. Weightless will hop between available slots every second or so, skipping any which turn out to be too cluttered (though periodically checking back in case they've cleared).

Showing its M2M roots, a Weightless access point only pages connected devices every 15 minutes, so those devices only need power up the radio four times an hour. Neul reckons that running the radio for two seconds at such intervals results in power consumption roughly equal to the decay rate of an idle battery, so being connected (and idle) has no perceivable impact on battery life.

That means a single Weightless hub can run connections to hundreds devices, across a network spanning 10km or so. Those devices could easily have a battery life measured in years, and be capable of responding with megabytes of data within 15 minutes.

A device which wants to connect to the network won't want to wait that long, and neither will one with something to report. In such circumstances the client can pick up a transmitted frame, which comes every second or two, and register an interest in sending some data upstream.

The security side of Weightless has yet to be worked out, with mutual authentication being considered more important than encrypting the content. Having someone listening in to a meter reading isn't that important, having someone faking a reading is, and content can always be encrypted at a higher level (Weightless will happily carry IPv4 and IPv6 packets).

Once on the network, a device has to wait for the hub to say when it can talk, though it has the chance to request communication slots. The speed of transmission is dependent on the quality of the signal. Each frame is addressed in a basically encoded header; all other devices can switch off their radios once they know the frame isn't addressed to them, and if the receiving device is nearby (as established by the signal strength) then the rest of the frame can be tightly encoded in the knowledge that little will be lost en route.

That means a Weightless hub can speak to hundreds of devices on the same network, with the speed of connection varying between devices. A receiver near the hub might therefore get 10Mb/sec or better, but one operating on the same network, from the same hub, could be running at a few hundred Kb in the same timeframe.


Wednesday, 11 April 2012

Whitespace Spectrum Management Issues

BT has been conducting a "White Space" trial in Isle of Bute, UK. Initial report suggests that the results are not very impressive. The following is from ISP Review:


Early feedback from BT’s trial of ‘White Space‘ (IEEE 802.22) wireless broadband technology on the Isle of Bute suggests that the service, which delivers internet access by making use of the unused radio spectrum that exists between Digital TV channels, still has a lot of problems to overcome, not least in terms of its sporadic performance.

In theory the 802.22 specification suggests that download speeds of up to 22Mbps per channel (Megabits per second) could be possible and some UK trials claim to have reached around 16Mbps, which is incidentally a long way off the UK’s chosen definition for superfast broadband (24Mbps+).
But separate reports from both PC Pro and the BBC today found that the service, which is complicated to deliver due to the ever changing spectrum and the risk of causing interference to DTV services, could struggle to deliver its top speeds.

At present BT’s implementation claims to be offering speeds of up to 10Mbps per channel, which will soon be upgraded to 15Mbps, but this reduces down to a maximum of just 4Mbps when 6km away from the transmitter. New tests at various points on the Isle of Bute showed speeds varying between just 1.5Mbps and 6Mbps (the latter was recorded within sight of BT’s mast).
In fairness White Space solutions are designed to target the last 10% of the UK where the government has so far only committed to a minimum download speed of just 2Mbps for all (Universal Service Commitment), which is a very low target. In addition White Space tech appears to deliver strong upload speed that is, in some cases, symmetrical. That makes it good for video conferencing and other upload dependent tasks.



As Fierce Broadband Wireless suggests, the low speeds could also be due to pre-standard gear that will just improve as time goes on.

The main reason for using this shared whitespace spectrum is due to the fact that the total amount of spectrum is limited and we want to make use of every available free spectrum to increase capacity of the overloaded networks.

Michael Fitch from BT recently spoke in our Cambridge Wireless Small Cells SIG event. The slide from his presentations neatly lays out the vision for shared spectrum.


In theory, even though this looks simple, in practice managing the database is a challenge by itself. The embedded slides below (Page 17 onwards) show the problems and the complexity associated with the database.
Time will tell how efficient and practical using whitespaces is.