Broadband Internet via 2-way Astra Satellite

Every now and then I get an eMail from someone asking me for advice on how to best hook up to the Internet from that little cottage they have bought in a remote place in Italy. Not quite sure why it’s always Italy, seems to be a nice place for a cottage. If 3G is not available their best chance so far was to buy a prepaid SIM card from TIM and use their nationwide EDGE network. But it seems there is no an affordable alternative available.

SES Astra has started their broadband Internet satellite service that does not require a phone line for the return path. The receiver/transmitter requires a satellite dish or, in case a satellite dish is already installed for reception of TV programs from the Astra satellite, the receiver/transmitter can be installed alongside the TV receiver module.

It seems the service is not sold directly by Astra but via national resellers. In Germany, Filiago is the reseller. A flatrate with 1 MBit/s downlink and 128 kbit/s uplink is available for around 40 euros a month.

According to Astra the service is available throughout Europe. Very nice!

Why The Mobile Web Had Such A Terrible Start

I’ve been thinking a bit about the recent history of mobile Internet access lately because I was wondering why it had such a teribble start. In the mobile world, the web had a much more difficult start compared to the fixed line world for a number of reasons. First attempts by mobile phone manufacturers to mobilize the web were a big disappointment for quite a number of reasons. In the fixed line world the web got an incubation time of at least a decade to grow, to be refined and to be fostered by researchers and students at universities before being used by the public who already had sufficiently capable notebooks, PCs and a reasonably priced connection to the Internet. In the mobile world, things were a lot different when first web browsers appeared on mobile phones around the year 2001:

  • Mobile Internet access was intended straight for the public instead of first attracting researchers and students to use and refine the services. Unlike at universities where the web was free for users, companies wanted to monetize the service from day one.
  • Few if any appealing content for the targeted audience was available in an adapted version for mobile phones.
  • Mobile access to the Internet was very expensive so only few were willing to use it.
  • Circuit switched bearers were used at the beginning which were slow and not suitable for packet switched traffic.
  • The mobile phone hardware was not yet powerful enough for mobile web browsers. Display sizes were small, screen resolutions not suited for graphics, no color, not enough processing power and not enough memory for rendering pages.
  • Use of a dedicated protocol stack (the Wireless Application Protocol, WAP) instead of HTML required special tools for web page creation and at the same time limited the possibilities to design mobile and user friendly web pages.

Each of the points mentioned above would have been enough on its own to stop the mobile web in its tracks. Consequently many roadblocks needed to be overcome before the Internet on mobile devices started to become interesting to a wider audience. This fortunately coincided with the emergence of the web 2.0 and its evolution into the mobile domain. But that’s another story.

As always, comments are welcome!

TDD UL and DL Ratios and Uplink Speeds

An interesting technical detail came to my attention today concerning Time Division Duplex (TDD) wireless systems such as WiMAX: Since uplink and downlink transmission is done in the same frequency band, uplink and downlink capacity can be adjusted based on demand. In theory this is an advantage over FDD (Frquency Division Duplex), used by most cellular 2G and 3G systems today. Here, uplink transmissions use a seperate frequency band which is just as large as the downlink frequency band (e.g. 5 MHz for UMTS). This means that FDD systems always have a 1:1 ratio between uplink and downlink. With TDD systems, this ratio can be changed, for example to 2:1, 3:1, etc. to give more capacity to the downlink. But there is one important thing to remember: The efficiency of uplink transmissions is much lower than in the downlink due to the lower transmission power and small antennas of the mobile device. Thus, even with a 1:1 ratio, uplink data rates are far lower than data rates in the downlink despite the using the same amount of bandwidth. I estimate that the maximum overall speed achieved in uplink direction is only 1/3 or 1/4 of the downlink. With rising uplink requirements of web 2.0 applications (picture, video uploads for example) I wonder if it will even make sense in practice to configure a 2:1 or 3:1 ratio in TDD systems as the uplink capacity would then be only a tenth of that of the downlink!? Opinions, anyone?

NokiaWorld: Chris Anderson and What Happens When Things Become Almost Free

Not much news from NokiaWorld which took place this week in Amsterdam concerning the hardware side. No cool N95 successor announced, no mind blowing N93+++ in the pipe. I am a bit disappointed. But the presentations of the guest speakers made up for it a bit. A lot of videos of what happened can be found here. I’ll surely take a look at most of them in the next couple of days. I’ve watched Chris Anderson’s presentation today on the impact of things that almost become free. For a minute he speculated what would happen if Nokia gave away the phone for free and charged for services. Well, I would "buy" a new phone instantly 🙂

IMS and the TISPAN secrets – Part 2

IMS and TISPAN, a bit of a mystery combination. In part one I’ve taken a look at what TISPAN is and how it uses IMS in it’s architecture. This part focuses on the PSTN/ISDN Emulation Sub-System and how the IMS can be used to simulate an analogue telephony switching center.

Besides the IMS subsystem the PSTN/ISDN (Public Switched Telephone
Network / Integrated Services Digital Network) Emulation Sub-System
(PES) is another important element of TISPAN. Its aim is to enable
legacy analog and ISDN telephones to be connected to an IP based next
generation network (NGN) via a media gateway which is either part of
the access modem or a standalone device. An IMS independent
implementation for PES is described in ETSI ES 282 002 while ETSI TS
182 012 defines how a PES can be implemented with IMS. Both standards documents are available via ETSI’s web site for free but one must register first.

As legacy devices can not be
modified a gateway has to be deployed on the user’s location. On the
one side of the gateway the analog or digital telephone is connected to
a legacy connector. In case of a standalone device the other side of
the device usually features an Ethernet connector with which the device
can be connected to the DSL or cable modem. The PES specification in
ETSI TS 182 012 knows two types of devices. Voice Gateways (VGWs)
emulate a SIP User Agent on the behalf of the legacy device and
communicate with SIP commands with the P-CSCF of the IMS. The second
approach is to deploy a media gateway (GW) which communicates via the
H.248 (Media Gateway Protocol, MEGACO) to the Access Gateway Control
Function (AGCF). In this approach the SIP User Agent functionality is
included in the AGCF, i.e. not on the customer device but in the
network itself.  Additionally, the AGCF includes the P-CSCF
functionality. During call establishment, the P-CSCF or the AGCF then
communicate with the RACS to reserve the required transport resources
to ensure the quality of service for a call. In addition, PES requires
an IMS Application Server (AS) to emulate the PSTN or ISDN service
logic when the PES User Agent sends SIP messages with embedded ISUP
messages.

And a final note: The TISPAN standard also aims to standardize non IMS
sub-systems. While out of scope of the current version of the
specification it is likely that TISPAN will specify a standardized IPTV
and Video on Demand (VoD) system in the next version.

Mowser and a Good Mobile Search Experience

I don’t search a lot on the net from my N93 as I don’t really feel the need for discovering new information sources while on the go. Today, however, I had to do a quick search as I had forgotten the exact address of a cafĂ© in Paris I was going to. So I used Mowser for the search since it would also format any pages it would find in a mobile friendly way. To my great surprise it found the address right away and displayed it as part of the search results. Great stuff, so mobile search is useful for me afterall.

A Web 2.0 Story: esyURL Creates Short URLs And Detects Mobile Web Browsers

Sometimes it’s almost unbelievable how well ideas spreed within web 2.0: Exactly two weeks ago, Charlie Schick wrote on his blog that he would like to have services that create short URLs out of long URLs for easy referencing in blogs, instant messengers, social networks, etc. to become mobile savy, i.e. that they should detect that the URL is requested from a mobile device and thus send the page in a mobile friendly way.

Filipe Boldo of esyURL reads Charlie’s blog and gets in contact with Russell Beattie who works on Mowser, a web page mobilizer service that reformats web pages for smaller screens, to see if and how Mowser could be integrated with esyURL. Russ gives a couple of tips and Filipe goes to work.

And today, Bernard Tyres sends on note around on Jaiku, a mobile social networking service, that the task has been accomplished. So when people now send interesting links around via esyURL on Jaiku or other web services that I use on my N93 I no longer have to remember to check it out when I get back to the PC but I can take a look immediately with my mobile web browser.

And the best: Based on the browser type given to the web server of esyURL with the request, it is either redirected to the full version of the web page or piped into Mowser for mobile optimization.

Great! Now everybody who sends short URLs around please go over to esyURL and check them out!

IMS and the TISPAN secrets

No this is not a Harry P. sequel but just about as mysterious. For a long time I was aware that besides IMS there is a group called TISPAN that deals with Next Generation Networks (NGNs) in the fixed line world. Lots of articles note that TISPAN is based on IMS but give no further details. Recently I did some research in this area and here is my summary of how TISPAN and IMS are related. A word of caution, though: For the text below I assume that you are familiar in general with how IMS works, i.e. what is a P-CSCF, S-CSCF, etc.

As the IMS mainly addresses the requirements of wireless operators, the European Standards Institute (ETSI) has decided to define a broader NGN architecture in their TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking) standards project. In the meantime 3GPP and TISPAN are working in close co-operation and it is expected that Release 8 of the 3GPP standard will contain a common architecture. In its core, a TISPAN Next Generation Network (NGN) consists of the following entities:

  • A subset of the IP Multimedia Subsystem (IMS) as defined by 3GPP;
  • A PSTN / ISDN Emulation Subsystem (PES);
  • Other non-SIP subsystems for IPTV, Video on Demand and other services.

As can be seen in the list the IMS is only one of several core subsystems of TISPAN. The reason for this is the fact that many services today are not based on SIP and sessions such as IPTV or Video on Demand (VoD). Many different approaches exist on the market today to deliver such services to the user. TISPAN aims to standardize the way such services are delivered, controlled and billed and how such applications can interact with the transport network to request a certain quality of service level for their data packets.

While the IMS has been defined to be access network agnostic, the 3GPP standards still make a number of assumptions on the kind of access network and subscriber databases to be used. To make IMS usable for DSL and cable operators it is required to fully generalize interaction with the access network and to have a generalized user database in the network. The figure on the left shows a simplified model of how the IMS is enhanced by TISPAN for this purpose as defined in ETSI ES 282 001 and ETSI ES TS 182 006 (available at the ETSI website for free but you have to register).

A main difference between fixed line and wireless networks is how devices connect to the network. In case of fixed line access networks, a DSL or cable modem at the customer’s premises is usually the gateway device that establishes the connection to the network. One or more devices behind this gateway device will then use the established connection to register with the IMS service. This is quite different compared to 3GPP where each device connects both to the transport network (PDP context activation) and to the IMS service (SIP register).

A number of different ways exist today how a DSL or cable modem can attach to the network.  TISPAN has made the step to standardize the functionality required in the network for user management at the network layer with the Network Attachment Subsystem (NASS). When a DSL or cable modem is powered on it first communicates with the NASS to authenticate and to obtain an IP address. Protocols used for this purpose are for example PPPoE (Point to Point Tunneling Protocol over Ethernet) and PPP over ATM.
The NASS is reached during the attachment process via the Resource Control Enforcement Function (RCEF) / Border Gateway Function (BGF) which sits between the access network and the core network of the operator. Their tasks are among others to route IP traffic between an external network and subscribers and to ensure that quality of service requests coming from the IMS or other core systems listed above are enforced on the transport layer.

The TISPAN Resource and Admission Control Subsystem (RACS) performs a similar task as the IMS Policy Decision Function (PDF). When an IMS session is established by a TISPAN device the P-CSCF contacts the RACS subsystem to reserve the required resources for the session and to allow IP packets to flow between the participants of the session. The RACS then communicates with the RCEF/BGF to see if enough resources are available for the session and configures them accordingly.

While in the 3GPP IMS model resources are reserved by the mobile devices and the P-CSCF once codecs have been agreed on, the TISPAN P-CSCF already contacts the RACS for the first time when receiving the INVITE message from the originator. If bandwidth requirements change during the session setup because a different codec has been selected by the devices the P-CSCF contacts the RACS again to modify the policy. This means that unlike a 3GPP IMS mobile device, which requests a certain bandwidth and QoS with a secondary PDP context activation, TISPAN IMS devices are not involved in QoS processes at all since the P-CSCF takes care of the whole process. This is necessary as TISPAN devices, unlike 3GPP mobile devices, are pure IP devices and thus can not influence the quality of service settings of the network themselves.

So much for this blog entry. Stay tuned for part two in which I will discuss the PSTN/ISDN Emulation Sub-System (PES).

As always, comments are welcome!

Viviane Redding Continues Her Mobile Struggle

Viviane Redding, EU Media Commissioner continues to put outrageous 2G/3G data roaming prices in the EU on the table. Heise online quotes her saying that "[data roaming] prices are too high and hamper international communication" at a conference in Budapest.

Good that this topics keeps being discussed as I would like to give up my dozened SIM cards for Internet access rather sooner than later for a single one I can use in all countries I travel to!