GSM
The Linux SCSI Target Wiki
 |
This article needs a review and may need a cleanup or additional content. Please help improve this article to meet our quality standards. (12/3/2010) |
GSM (Global System for Mobile Communications: originally from Groupe Spécial Mobile) is the most popular standard for mobile telephony systems in the world. Obviously, iSCSI over GSM therefore is important, because an open method to access GSM radio hardware allows a mobile device to access unlimited amounts of block level storage across iSCSI.
One of the primary benefits of this SAN architecture is that iSCSI storage resources are available transparently to the mobile's applications.
New possible applications include the capability of both saving and retrieving content, including video, audio, images, block and filesystem level bits from remote storage resources, transparently to all existing mobile applications. With GSM/GPRS, these are typically constrained by known network link limitations, cost of service, cost of hardware, and hardware availability. GSM/GPRS allows vendors to take existing mobile hardware and apply software updates to exceed the hardware's physical storage limitiations. Taking advantage of both iSCSI and iSNS software components in a manner that brings value to software offerings on open hardware platforms is the end result.
Contents |
Status
A number of mobile devices already use iSCSI to access remote media assets over GPRS via tri-band GSM IP storage services with a Linux v2.4 kernel, see e.g. Motorola ROKR E2. Multipathing features such as MC/S and ERL=0 are essential to enable reliable iSCSI across WANs and cellular networks.
The main limiting factors that exist for obtaining iSCSI anywhere, anytime and on any mobile for storage resources are:
- Client
- GPRS bandwith availability, system memory for various forms of caching and a read-only/read-write filesystem considerations, and an Initiator on your mobile device.
- Server
- A working iSCSI target with blocks containing a filesystem that the mobile can understand.
FAQ
- Q: I thought that an iSCSI Initiator stack was too large and/or CPU intensive for such a underpowered device as a cell phone?
A: This is not true. A software iSCSI initiator stack can run on a ~70 MHz ARM9 and easily max out even ideal GSM bandwith with single-digit CPU load using single threaded benchmark tools. Modern Smart Phones with cores running at 1 GHz or higher have more than enough processing power for iSCSI.
- Q: I thought that iSCSI was too 'heavy duty' a protocol for my mobile?
A: The question really becomes how useable this type of infastructure is on a communication network that runs at ISDN (~10 kb/s) speeds. For accessing a large audio library, the right pieces of software and tuning allow to have those TBs of audio assets in your pocket usable by existing media players.
- Q: How does iSCSI allow me to access storage resources on my cell phone?
A: Once your mobile (if supported) reaches 802.11 infrastructure, another communication path can be automatically and transparently opened for each connected iSCSI target node to take advantage of the increased bandwith while being within reach of the 802.11 access points. Once no longer within range of the access points, the communication path fails waiting for 802.11 PHY to come back online. At this point iSCSI traffic can resume flowing across the GSM communication path without need of breaking nexus between the multiple IP storage target nodes and your mobile.
- Q: I don't care what Linux or iSCSI is, I just want to load network playlists remotely - anywhere and anytime - from my PlayStation 3, Wii or XBox/360.
A: The important piece from the application's perspective using iSCSI storage is that this is done transparently to the SCSI subsystem and higher layers of the operating system's storage stack. To that end, internexus connection recovery on iSCSI (with MC/S and ERL=0) is essential in networks where multiple communication paths exist and are expected to fail and recover on a regular basis.
- Q: Why can't I just use NFS on my cell phone?
A: NFS lacks support for multiple communication paths and active-active recovery on communication path failure for starters. Also the lack of world wide unique naming (WWN) and a scalable discovery infrastructure makes scaling to millions of nodes basically impossible.
- Q: What about dealing with data coherency and cluster filesystems?
Q: Cluster filesystems across GSM/GPRS speeds is pretty undoable, after all these filesystems are typically designed for database loads with transports on the order of multiple Gb/s datarates. A good piece of research for this problem would be how much iSCSI traffic is generated using read-only mounts using existing cluster filesystems in Linux v2.6.
- Q: Can I run Multiple Connections per Session (MC/S) concurrently across both GSM/GPRS and 802.11b/g infrastructures?
Absolutely. In fact, this is the preferred method, so that you can take automatically advantage of the higher bandwidth in hotspots (the additional iSCSI connection just comes up on the wireless PHY). Having connection recovery (MC/S and ERL=2) is crucial here, so that the device can move from access point to access point as well as gracefully handling typical GSM communication failures that otherwise would cause TCP connections to reset.
See also
- Initiators: Motorola ROKR E2 and OpenMoko
- LinuxIO: PlayStation 2, PlayStation 3
- Other platforms
External links
- GSM Wikipedia entry
- Comparison of mobile phone standards
