Neue Dienste wie Video-Streaming fordern zunehmend hohe Datenraten. So definiert die Spezifikation 3GPP W-CDMA Release 5 beispielsweise für HSDPA Datenraten bis zu 14,4 Mbit/s. Außer in den Kategorien 11 und 12 erfordert HSDPA neben einem gemeinsamen Downlink-Kanal (HS-DSCH, High Speed Downlink Shared Channel) auch Modulationstechniken höherer Ordnung sowie eine Link-Adaptierung für eine schnelle und spektral effiziente Übertragung.
Auch sendeseitig stellt die HSDPA-Implementierung höhere Anforderungen an die ACLR-Performance und die maximale Ausgangsleistung, die während des Design-Prozesses sorgfältig beachtet werden müssen. Modulationen höherer Ordnung erfordern zudem eine verbesserte Linearität der Empfangskette.
Aus der vorangegangenen Beschreibung einer typischen Entwicklung eines individuellen BSP lassen sich folgende Schlüsse ziehen:
Systemhäuser, die schon viele Projekte erfolgreich abgeschlossen haben, haben folglich auch schon viele individuelle Kundenwünsche umgesetzt. Daraus ergibt sich ein stetig wachsender Fundus an Know-how, der sich in Form von Design-, Hard- und Software-Technologien niederschlägt. Wird dieses Know-how dem Markt zur Verfügung gestellt, führen diese Mehrwerte in Projekten zu deutlichen Vorteilen, die sich in kürzeren Entwicklungszyklen oder in mehr Funktionalität für den Endkunden niederschlagen.
Im Allgemeinen besteht im BSP eine feste, starre Zuordnung zwischen dem Boot-Loader, der Hardware-Anpassungsschicht und dem Betriebssystemkern, der geladen wird. Nach Abschluss des Entwicklungsprozesses sind alle diese Bestandteile aufeinander abgestimmt und repräsentieren eine feste Systemkonfiguration, die letztendlich auch im produktiven Umfeld beim Kunden eingesetzt wird. Diese feste Fixierung der Systemspezifikationen und Funktionalität ist aber in vielen Fällen nicht wünschenswert. Während des Entwicklungsprozesses ist es aufwendig, für verschiedene Systemkonfigurationen jeweils einen eigenen OEM Adaption Layer und einen darauf abgestimmten Betriebssystem-Kern zu erzeugen. Es sollen ja viele verschiedene Konfigurationen entwickelt und getestet werden, ohne dass jedes Mal ein individuelles Betriebssystem-Image erzeugt werden muss. Im produktiven Betrieb kann es wünschenswert sein, für eine ganze Gerätebaureihe mit einem einzigen Betriebssystem-Image verschiedene Systemkonfigurationen zu unterstützen. Das spart sehr viel Kosten in der langfristigen Systempflege, reduziert die Logistik und den Aufwand für den Support. Ein intelligenter Boot-Loader, der mit dem Betriebssystem kommuniziert, kann für diese Anforderungen sehr hilfreich sein.
Der Boot-Vorgang wird dabei in zwei Stufen aufgeteilt. In einem so genannten „Primary Bootstrap“-Vorgang finden die System- und Speicherprüfungen statt, werden die ersten Speichertransfers ausgeführt, wird die CPU initialisiert, werden die SDRAM-Timings eingestellt, wird die MMU vorbereitet und es wird überprüft, aus welchem Systemzustand das Gerät startet (z.B. Wake-up nach Sleep-Modus oder Kaltstart). Zusätzlich kann mit diesem Prozess ein automatisches Memory-Sizing durchgeführt werden. Der Primary-Bootstrap-Vorgang gibt dem Anwender auch die Möglichkeit, initiale Systemtests interaktiv auszuführen noch bevor ein Betriebssystem geladen wird. Im Entwicklungsprozess wird damit wertvolle Testzeit gespart.
Im zweiten Schritt lädt der Boot-Loader das Betriebssystem. Um verschiedene Gerätekonfigurationen möglichst flexibel an das Betriebssystem anzupassen, wird an dieser Stelle eine Parameterdatei eingeführt. In ihr werden Daten hinterlegt, die bestimmte Systemkonfigurationen beschreiben. Diese Datei wird vom Boot-Loader geladen, die Daten werden an das Betriebssystem übergeben und es werden von dort die neuen Geräteeinstellungen konfiguriert. Dieses Verfahren unterstützt ein Design mit verschiedenen Systemvarianten, aber ein und demselben Betriebssystem-Image. Im Entwicklungsprozess können somit schneller neue Konfigurationen erstellt und getestet werden. Es müssen dafür nicht jeweils angepasste Betriebssystem-Images erzeugt, getestet und gepflegt werden. In der Produktion kann man auf diesem Weg eine komplette Gerätefamilie mit verschiedenen Konfigurationen mit nur einem einzigen Betriebssystem-Image ausstatten. Das spart Produktions- und Supportkosten.