\subsection{How to synchronize the GSM TDMA multiplex}
As part of the BCCH, the BTS not only sends the FCCH but also the
Synchronization CHannel (SCH). The Synchronization channel indicates the
current GSM time / frame number (skipping the 3 least significant bits).
By using this received GSM time and incrementing it every time the GSM bit-clock
timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized.
Understanding the multiple layers of time multiplex such as the 26/51
multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all
the logical channels of GSM.
\section{Miscellaneous Topics}
\subsection{GPRS}
GPRS was the first packet switched extension to GSM. In fact, it is much more
its entirely own mobile network, independent of GSM. The only parts shared are
the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful
coexistence between them.
The L1 and L2 protocols are very different (and much more complex) than GSM.
So while the phone baseband hardware did not need any modifications for a basic
GPRS enabled phone, the software needed to be extended quite a lot.
\subsection{EDGE}
EDGE is a very small incremental step to GPRS. It reuses all of the time
multiplex and protocol stack, but introduces a new modulation: 8PSK instead
of GMSK to increase the bandwidth that can be transmitted.
So while the software modifications from GPRS to EDGE are minimal, the 8PSK
modulation scheme has a significant impact on the DSP, ABB and even RF
Frontend (especially the RF Amplifier).
\subsection{UMTS}
UMTS (sometimes called WCDMA) is an entirely separate cellular network
technology. Its physical layer, modulation schemes, encoding, frequency
bands, channel spacing are entirely different, as is the Layer1.
UMTS Layer2 has some resemblance to the GPRS Layer2.
UMTS Layer3 for Mobility Management and Call Control are very similar to GSM.
Given the vast physical layer and L1 differences, a UMTS phone hardware design
significantly differs from what has been described in this document.
Notwithstanding, all known commercial UMTS phone chipsets as of today still
include a full GSM modem in hardware and software to remain
backwards-compatible.
\subsection{Dual-SIM and Triple-SIM phones}
In recent years, a large number of so-called {\em Dual-SIM} or even {\em
Triple-SIM} phones have entered the market, particularly in China and other
parts of East Asia.
Those phones come in various flavours. Some of them simply have a multiplexer
that allows electrical switching between multiple SIM card slots. This is
similar to replacing the SIM card in a phone, just without the manual process
of mechanically removing/inserting the card. As a result, you can only use one
of the two SIMs at any time.
The more sophisticated Dual-SIM phones have two complete phones in one case. Yes,
that's right! They contain two full GSM phoen chipsets, i.e. 2 antennas, 2 rf
frontends, 2 analog basebands, 2 digital basebands, ...
However, they use the same trick as smartphones: One of the two baesbands does
not have keypad or display and is simply a GSM modem connected via serial line
to the other baseband processor.
So if a smartphone (as defined in this document) is a GSM modem connected to a
PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone
in one case.
Triple-SIM phones often combine the two approaches, i.e. they contain two
complete GSM baesband chips, but three SIM slots that can be switched among
the base bands. Only two SIMs can be active at the same time.
\subsection{Powerful feature phones}
Feature phones are becoming more and more powerful. However, their
comparatively lower market price cannot afford a full-blown smartphone design
with its two independent processors and the associated design complexity.
Thus, more and more hardware peripherals are added to the only processor left
in the phone: The baseband processor. Such peripherals include sophisticated
camera interfaces, high-resolution color display controllers, TV output,
touchscreen controllers, audio and video codecs and even interfaces for mobile
TV reception.
However, all of those features are still implemented on a fairly weak ARM7 or
ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They
also lack a real operating system and still run on top of a real-time
microkernel intended for much less complex systems. They almost always lack
any form of memory protection or multiple address spaces. This makes them
more prone to security issues as there is no privilege separation between
the GSM protocol stack and the applications, or between the applications
themselves.
\section{Personal rant on the closedness of the GSM industry}
The GSM industry is one of the most closed areas of computing that I've
encountered so far. It is very hard to get any hard technical
information out of them. All they like to spread is high-level
marketing information, but they're very reluctant when it comes down to
hard technical facts on their products.
If you want to build a phone, you need to buy a GSM chipset for your
product. There are only very few companies that offer such chipsets.
The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI
(now MediaTek) and Freescale.
The GSM handset products they sell are not generally available and
distributed like other electronic component they manufacture. If you
need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth
chip, RFID reader ASIC, you simply approach the respective distributors
and order them. You get your samples directly from Digikey.
This is impossible for GSM (or other cellphone) chipsets. For some
reason those chips are sold only to hand-picked manufacturers. If you
want to qualify, you have to subscribe to at least six-digit annual
purchasing quantities. And in order for them to believe you, you have
to cough up a significant NRE (non-refundable engineering fee). This
has been reported as high as a seven-digit US\$ amount and is to make
sure that even if you end up buying less chips than you indicate, the
chipset maker will still have your upfront NRE money and keep it.
And if you buy your way into that select club of cellphone makers, what
you get from the chipset maker is typically not all too impressive
either. The documentation you get is incomplete, i.e. it alone would
not enable you as a cellphone maker to make any use of the hardware,
unless you license the software (drivers, GSM protocol stack, ...) from
the chipset maker, too.
On the software side, most of the technologically interesting bits (like
the protocol stack) are provided as binary-only libraries, you only get
source code to some parts of the systems, i.e. some hardware drivers
that might need modification for your particular phone electrical
design.
That GSM protocol stack was not written by the chipset maker either.
They simply license a stack from one of the estimated 4 or 5
organizations who have ever implemented a commercial GSM protocol stack.
It is not like the GSM protocols were some kidn of military secret.
They are a published international standard, freely accessible for
anyone. So why does everybody in that industry think that there is
a need to be so secretive?
Having spent a significant part of the last 6 years with reverse
engineering of various aspects of mobile phones in order to understand
them better and do write software tools for security analysis, I still
don't understand this secrecy.
All the various vendors do more or less the same. The fundamental
architecture of a GSM baseband chip is the same, whether you buy it from
TI, Infineon or from MediaTek. {\em They all cook with water}, like we
Germans tend to say. The details like the particular DSP vendor or
whether you use a traditional IF, zero-IF or low-IF analog baseband
differ. But from whom do they want to hide it? If people like myself
with a personal interest in the technical aspects of mobile phones can
figure it out in a relatively short time, then I'm sure the competiton
of those chipset makers can, too. In much less time, if they actually
care.
This closedness of the cellular industry is one of the reasons why there
has been very little innovation in the baseband firmware throughout the
last decades. Innovation can only happen by very few players. Source
code bugs can only be found and fixed by very few developers at even
fever large corporations. No chance for a small start-up to innovate,
like they can in the sphere of the internet.
It is fundamentally also the reason why the traditional phone makers
have been loosing market share to newcomers to the mobile sphere like
Apple with its iPhone or Google with its Android platform.
Those innovations really only happened on the application processor on
high-end smartphones. The closed GSM baseband processor had to be
accompanied by an independent application processor running a real
operating system, with real processes, memory management, shared
libraries, memory protection, virtual memory spaces, user-installable
applications, etc.
They still don't happen on the baseband processor, which is as closed as
it was 15 years ago.
\end{document}
--0ntfKIWw70PvrIHh--
or 6225 CPUs (need to look for documentation):
--- MT6225BA
CECT V8
TianShiDa TS822
--- MT6225/6225A
CECT 388
CECT 98
CECT 2618
CECT N95i
ChangHong 868
ChuangWei T508
DaXian X889
DaXian X769
GaoXinQi D808
Hantai HT622
Hantai HT6868
JingLi H9 (some H9 also have MT6226)
JinPeng A918
JinPeng 858
JinPeng A9
JinPeng S3506
JinPeng 2298
JinPeng L818
JinPeng A608
TianYu D170
TianYu B898
TianYu A930
TianYu B926
TianYu A908
ZTC 6988
ZTC 598
ZTC 1118
ZTE ZTLV900
ZTE ZT688 (note MT6205 versions also exist)
--- MT6223PA
TianYu B5010
CECT D1088
Next steps for me: Scan the schematics stuff and put it online. Find some
6223/6225 based phones that are cheap & suitable for hacking, i.e. ideally
with some nice test points or JTAG.
Other common MTK chips are 6205, 6217, 6218, 6219, 6226, 6228.
One word of caution - the above lists, and documentation we start digging
up, may give a false impression of predictability. In reality the brand
names and model numbers are a total mess in China. Typos everywhere. All
sorts of things are printed on cases & boxes, chips are changed without
anybody noticing or caring. There are endless smaller Chinese brands making
phones with 6223 or 6225 chips, but I think it will be very hard to use
them as a stable source, to get phones with the same chips over time. So
I think it's better to focus on the somewhat bigger Chinese brands as
listed above.
Wolfgang
not always 100% perfect (it depends on the phone and the cable), so
moving the phone during the download may cause the connection to be
interrupted. I have not yet looked at the serial signal with an
oscilloscope to see if there are problems with the signal itself.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
stage. Any ideas?
If I boot the phone and use 57600bps I get some prints and then AT
returns OK, no other AT commands work.
In case it is too broken I have ordered a C121 from germany as well.
/Erik
without having to go through the real layer1 or at least without having<br>
to go through the air.<br>
<br>
But without a clear path to later porting this on a real physical<br>
layer1, there would be little motivation of doing all that work.<br></block=
quote><div><br>I'd like to get involved in that, however these are my p=
roblems:<br>- I have no running system that I could debug and <br>=A0 there=
by learn how GSM works.<br>
-=A0 To=A0 get a running system I would need to implement a software<br>=A0=
=A0 only system, however, I cannot implement that without knowledge <br>=A0=
=A0 of GSM<br>=A0That is kindof a deadlock. <br><br>Therefore I wonder wea=
ther the expert of GSM would share their <br>
knowledge in the obove described way:<br>Having=A0 <br>=A0 - a flow diagram=
<br>=A0 - the etsi standard pages (or simple rewrites of it)<br>=A0 - the h=
tml parsed imlemention of a real TSM30 stack implement.<br>and linking that=
all together to get a way for a newbie to <br>
get started.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"border-=
left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left=
: 1ex;">
<br>
I think what makes OsmocomBB special is the very fact that we do not<br>
have to rely on simulation, but can do the "real thing".<br>
<br>
Nonetheleess, if somebody was interested in implementing what I've<br>
described, I'd be more than happy to help any such project and<br>
include the neccessary support in OpenBSC and/or OsmocomBB.<br>
<div><div></div><div class=3D"h5"><br>
--<br>
- Harald Welte <<a href=3D"mailto:laforge@gnumonks.org">laforge@gnumonks=
.org</a>> =A0 =A0 =A0 =A0 =A0 <a href=3D"http://laforge.gnumonks.org/" t=
arget=3D"_blank">http://laforge.gnumonks.org/</a><br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
"Privacy in residential applications is a desirable marketing option.&=
quot;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0(ETSI EN 300 175-7 Ch. A6)<br>
</div></div></blockquote></div><br>
--0016e65ae6825c4265048170c62d--
without having to go through the real layer1 or at least without having
to go through the air.
But without a clear path to later porting this on a real physical
layer1, there would be little motivation of doing all that work.
I think what makes OsmocomBB special is the very fact that we do not
have to rely on simulation, but can do the "real thing".
Nonetheleess, if somebody was interested in implementing what I've
described, I'd be more than happy to help any such project and
include the neccessary support in OpenBSC and/or OsmocomBB.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
data to the network by using the RSL RLL DATA REQUEST primitive.
Also, while we are tuned to any BCCH/CCCH, the L3 frames are sent from
L2 to L3 in RSL RLL UNIT DATA INDICATION messages.
What is not as simple is the non-RLL part, i.e. sending the first RACH
request, ...
For those, we will have to invent our own new RSLms message types,
possibly reusing as many RSL information elements as possible - meaning
we can share more code/structure with what we already have in
libosmocore/openbsc
> is there a better (simpler) way?
The RSLms approach might not be the simplest one, but I think it would
be a very nice/orthogonal approach. Plus: In this model, we can
eventually move the L2 implementation into the MS firmware, while
talking RSLms over HLDC to L3 on the PC.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
December 10, 2021 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "osmo-dev and running Osmocom TTCN3 tests suites locally" by osmith
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
November 25, 2021 at 20:00 CET (yes, Thursday instead of Friday this time!)
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "Control/User Plane Separation (CUPS) + PFCP" by laforge
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
November 12, 2021 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "E1 / TDM / PDH / SDH basics" by laforge
20:30 presentation "icE1usb in practice" by tnt
later USSE: unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
