1
00:00:00,000 --> 00:00:02,360
SPEAKER: The following content
is provided under a Creative

2
00:00:02,360 --> 00:00:03,640
Commons license.

3
00:00:03,640 --> 00:00:06,540
Your support well help MIT
OpenCourseWare continue to

4
00:00:06,540 --> 00:00:10,030
offer high quality educational
resources for free.

5
00:00:10,030 --> 00:00:13,050
To make a donation or to view
additional materials from

6
00:00:13,050 --> 00:00:16,830
hundreds of MIT courses, visit
MIT OpenCourseWare at

7
00:00:16,830 --> 00:00:19,260
ocw.mit.edu.

8
00:00:19,260 --> 00:00:27,930
PROFESSOR: The CDMA and the
cellular standard, the IS95,

9
00:00:27,930 --> 00:00:31,080
which is a kind of an old
standard by now, but it's

10
00:00:31,080 --> 00:00:32,280
still widely used.

11
00:00:32,280 --> 00:00:36,190
There's still three major
standards that are used for

12
00:00:36,190 --> 00:00:39,920
cellular communication, cellular
voice communication.

13
00:00:39,920 --> 00:00:42,510
This is one of them.

14
00:00:42,510 --> 00:00:46,190
This is the one which is
primarily being used as a

15
00:00:46,190 --> 00:00:50,090
jumping off point for all of the
new standards that people

16
00:00:50,090 --> 00:00:51,820
are trying to think of.

17
00:00:55,520 --> 00:00:58,640
I want to talk about it for that
reason but also because

18
00:00:58,640 --> 00:01:02,850
it really is a nice way of
pulling together almost

19
00:01:02,850 --> 00:01:05,150
everything we talked about
in the course.

20
00:01:05,150 --> 00:01:10,760
All of it comes into this one
particular way of sending

21
00:01:10,760 --> 00:01:13,470
cellular voice.

22
00:01:13,470 --> 00:01:16,030
Let's go through some of
the details of it.

23
00:01:16,030 --> 00:01:18,910
Some things here might sound
more detailed than what you're

24
00:01:18,910 --> 00:01:22,710
interested in but I think it's
good to have the numbers on it

25
00:01:22,710 --> 00:01:28,540
because it gives you some idea
of which things, which factors

26
00:01:28,540 --> 00:01:33,600
are really relevant and which
ones aren't so relevant.

27
00:01:33,600 --> 00:01:38,570
So it uses a frequency ban from
800 to 900 megahertz.

28
00:01:38,570 --> 00:01:41,830
Most of the new standards that
people are thinking up are up

29
00:01:41,830 --> 00:01:44,340
in the gigahertz range
around two gigahertz

30
00:01:44,340 --> 00:01:46,070
or five or six gigahertz.

31
00:01:46,070 --> 00:01:49,080
I don't know the exact
bandwidths.

32
00:01:49,080 --> 00:01:53,330
All of these bandwidths depend
critically on what the FCC

33
00:01:53,330 --> 00:01:59,610
wants to allocate and also
depend critically one which

34
00:01:59,610 --> 00:02:04,240
particular bands are good for
electromagnetic propagation

35
00:02:04,240 --> 00:02:07,790
and which ones tend to absorb
all of the radiation.

36
00:02:07,790 --> 00:02:13,930
Anyway, you use the band 800 to
850 for the reverse channel

37
00:02:13,930 --> 00:02:17,990
for the cell phone to the base
and you use the band 850 to

38
00:02:17,990 --> 00:02:20,130
900 for the forward channel.

39
00:02:20,130 --> 00:02:23,600
Why do you want to separate the
reverse channels and the

40
00:02:23,600 --> 00:02:27,740
forward channels by as
much as you can?

41
00:02:27,740 --> 00:02:32,460
If you think for just a minute
about the power levels at your

42
00:02:32,460 --> 00:02:38,770
sending antenna, either at the
base station or at the cell

43
00:02:38,770 --> 00:02:42,730
phone itself, and then you think
about how much power

44
00:02:42,730 --> 00:02:45,860
you're receiving, he see there's
an enormous difference

45
00:02:45,860 --> 00:02:47,300
between these two.

46
00:02:47,300 --> 00:02:50,590
Because things get attenuated
enormously after they got

47
00:02:50,590 --> 00:02:51,690
transmitted.

48
00:02:51,690 --> 00:02:54,830
So what you're trying to do is
to filter out what you're

49
00:02:54,830 --> 00:02:58,750
sending, which is an enormously
high power and you

50
00:02:58,750 --> 00:03:02,260
have to filter it out by enough
so that it doesn't

51
00:03:02,260 --> 00:03:04,510
clobber what you're
trying to receive.

52
00:03:04,510 --> 00:03:07,250
This means you need
very good filters.

53
00:03:07,250 --> 00:03:08,740
How do you build very
good filters?

54
00:03:08,740 --> 00:03:12,750
It's a lot easier to build good
filters if you're not

55
00:03:12,750 --> 00:03:16,560
trying to make them cut
off immediately.

56
00:03:16,560 --> 00:03:20,610
If you have 50 megahertz, and
you actually have a lot more

57
00:03:20,610 --> 00:03:27,470
than that, you have exactly 50
megahertz because this is all

58
00:03:27,470 --> 00:03:31,280
separated into a bunch of
different channels.

59
00:03:31,280 --> 00:03:35,100
People in wireless, most
practical communicators, when

60
00:03:35,100 --> 00:03:37,970
they talk about a channel, what
they're talking about is

61
00:03:37,970 --> 00:03:39,460
a particular bandwidth.

62
00:03:39,460 --> 00:03:43,690
All along what we've been
talking about is a particular

63
00:03:43,690 --> 00:03:46,350
medium going from transmitter
to receiver.

64
00:03:46,350 --> 00:03:49,450
That's what they're talking
about is these channels, these

65
00:03:49,450 --> 00:03:54,860
channels or sub-bands are 1.25
megahertz wide each.

66
00:03:54,860 --> 00:03:56,360
We'll see what the
significance of

67
00:03:56,360 --> 00:03:58,530
that is in a while.

68
00:03:58,530 --> 00:04:04,550
So you have a transmit and
receive pair which are both

69
00:04:04,550 --> 00:04:09,350
1.25 megahertz wide and which
are separated by 50 megahertz.

70
00:04:09,350 --> 00:04:11,990
So you have one channel then,
at the bottom of the range,

71
00:04:11,990 --> 00:04:14,760
another channel a little bit
higher, another channel, a

72
00:04:14,760 --> 00:04:17,440
little bit higher, and so
forth all the way up.

73
00:04:17,440 --> 00:04:20,460
So you have lots of different
channels and you put lots of

74
00:04:20,460 --> 00:04:24,450
different cell phones in each
channel for each base station.

75
00:04:24,450 --> 00:04:29,110
So that's roughly the overall
architecture of it.

76
00:04:29,110 --> 00:04:31,260
It's the same kind of system
that we've been

77
00:04:31,260 --> 00:04:32,510
talking about all along.

78
00:04:32,510 --> 00:04:35,480
You start out with voice wave
forms, you have voice

79
00:04:35,480 --> 00:04:36,400
compression.

80
00:04:36,400 --> 00:04:40,200
You then have channel coding,
you then have modulation and

81
00:04:40,200 --> 00:04:42,100
then it goes out
on the channel.

82
00:04:42,100 --> 00:04:44,940
Guess what happens when
it comes back?

83
00:04:44,940 --> 00:04:50,090
You have demodulation, channel
decoding, and then you turn it

84
00:04:50,090 --> 00:04:52,310
back into voice.

85
00:04:52,310 --> 00:04:57,330
Those are the three major steps
which we viewed before

86
00:04:57,330 --> 00:04:59,410
primarily as two steps.

87
00:04:59,410 --> 00:05:02,950
All of the channel stuff is much
harder than all of the

88
00:05:02,950 --> 00:05:04,850
source stuff.

89
00:05:04,850 --> 00:05:08,270
Let's talk about the
source stuff first.

90
00:05:08,270 --> 00:05:12,830
The input voice gets segmented
into these

91
00:05:12,830 --> 00:05:14,820
20 millisecond segments.

92
00:05:14,820 --> 00:05:17,300
Why 20 milliseconds?

93
00:05:17,300 --> 00:05:19,610
Well it sort of seems like it's
probably a number that

94
00:05:19,610 --> 00:05:22,470
somebody picked out of a hat.

95
00:05:22,470 --> 00:05:24,710
It's kind of striking that
all of the standards

96
00:05:24,710 --> 00:05:27,110
use the same interval.

97
00:05:30,060 --> 00:05:31,600
If you think about
it awhile --

98
00:05:31,600 --> 00:05:35,340
I'll talk about this more
on the next slide --

99
00:05:35,340 --> 00:05:38,200
the reason for this interval
is that in voice

100
00:05:38,200 --> 00:05:41,810
communication, delay is
enormously important.

101
00:05:41,810 --> 00:05:44,665
You don't want to have much
delay and since you don't want

102
00:05:44,665 --> 00:05:47,940
to have much delay, you
have to do encoding

103
00:05:47,940 --> 00:05:50,400
over very short segments.

104
00:05:50,400 --> 00:05:55,150
Well anyway, what this does is
it takes each 20 millisecond

105
00:05:55,150 --> 00:05:59,410
segment of voice and it
maps it into 172 bits.

106
00:06:02,230 --> 00:06:07,040
What that means is if you
multiply the 172 by the 50

107
00:06:07,040 --> 00:06:12,410
segments that you have per
second, it comes out to be 8.6

108
00:06:12,410 --> 00:06:14,360
kilobits per second.

109
00:06:14,360 --> 00:06:18,400
That might not sound like
much of an achievement.

110
00:06:18,400 --> 00:06:21,470
Think about the old fashioned
way that people used to encode

111
00:06:21,470 --> 00:06:27,730
voice back in a time when they
were first doing digital

112
00:06:27,730 --> 00:06:28,980
communication.

113
00:06:28,980 --> 00:06:33,650
What you would was you would
think of the voice as having a

114
00:06:33,650 --> 00:06:36,710
bandwidth that went from
about 400 hertz up

115
00:06:36,710 --> 00:06:38,940
to about 3,200 hertz.

116
00:06:38,940 --> 00:06:41,960
You would then view it as a base
band wave form zero to

117
00:06:41,960 --> 00:06:43,730
4,000 hertz.

118
00:06:43,730 --> 00:06:47,580
If you were going to try to
sample that wave form you'd

119
00:06:47,580 --> 00:06:51,010
have to sample it 8,000
times per second.

120
00:06:51,010 --> 00:06:54,910
If you want good quality, you
then have to use a large

121
00:06:54,910 --> 00:06:57,030
number bits.

122
00:06:57,030 --> 00:06:59,940
You need a large number of
bits for each sample.

123
00:06:59,940 --> 00:07:02,840
The standard thing was to use
eight bits per sample.

124
00:07:02,840 --> 00:07:08,210
That gave you 64,000 bits per
second in the old fashioned

125
00:07:08,210 --> 00:07:09,160
way of doing it.

126
00:07:09,160 --> 00:07:12,980
People have worked
for many years.

127
00:07:12,980 --> 00:07:18,060
Many engineers at the old Bell
labs spent their whole career

128
00:07:18,060 --> 00:07:21,880
trying to find out how to
compress voice into smaller

129
00:07:21,880 --> 00:07:24,920
and smaller numbers of bits.

130
00:07:24,920 --> 00:07:29,610
You know, 8.6 kilobits
per second is still

131
00:07:29,610 --> 00:07:32,010
sort of a good rate.

132
00:07:32,010 --> 00:07:36,000
It's still a good rate if you
insist that you have to do it

133
00:07:36,000 --> 00:07:38,480
in 20 millisecond segments.

134
00:07:38,480 --> 00:07:42,220
If you can take much longer
segments to encode voice, you

135
00:07:42,220 --> 00:07:44,610
can do much better.

136
00:07:44,610 --> 00:07:48,510
Voice really has a lot of
constraints over relatively

137
00:07:48,510 --> 00:07:50,420
long periods of time.

138
00:07:53,820 --> 00:07:57,990
Well actually, you know this
because if you take a person's

139
00:07:57,990 --> 00:08:02,360
voice and you map it into text
and then you also add a few

140
00:08:02,360 --> 00:08:06,010
things about pitch and things
like that, you can really come

141
00:08:06,010 --> 00:08:08,470
by with a very small
number of bits.

142
00:08:08,470 --> 00:08:10,930
Here you're constraining
yourself to something that

143
00:08:10,930 --> 00:08:15,160
sounds like the actual voice
and also has to be done in

144
00:08:15,160 --> 00:08:18,270
these 20 millisecond segments
because of delay.

145
00:08:18,270 --> 00:08:21,420
So it still is a reasonably
good achievement.

146
00:08:21,420 --> 00:08:24,780
All of the standards have
figures about like this, in

147
00:08:24,780 --> 00:08:26,560
the same order of magnitude.

148
00:08:26,560 --> 00:08:28,300
I expect that all of
the new standards

149
00:08:28,300 --> 00:08:29,920
will do similar things.

150
00:08:29,920 --> 00:08:31,440
They will probably
have slightly

151
00:08:31,440 --> 00:08:33,170
smaller numbers of bits.

152
00:08:33,170 --> 00:08:36,220
They will probably do much
more computation.

153
00:08:36,220 --> 00:08:38,920
They will achieve a little
bit more because

154
00:08:38,920 --> 00:08:39,890
this was already --

155
00:08:39,890 --> 00:08:42,780
I think --

156
00:08:42,780 --> 00:08:46,710
relatively close to how
far you can go.

157
00:08:46,710 --> 00:08:48,700
The next thing they
do is they add 12

158
00:08:48,700 --> 00:08:50,300
parity checks per segment.

159
00:08:50,300 --> 00:08:52,410
They use that for
error detection.

160
00:08:52,410 --> 00:08:55,340
I don't want to talk about that
a lot because it probably

161
00:08:55,340 --> 00:08:57,370
isn't necessary.

162
00:08:57,370 --> 00:09:00,690
All of the standards do
something or other like this.

163
00:09:00,690 --> 00:09:04,700
The reason is, if you take this
20 millisecond segment

164
00:09:04,700 --> 00:09:07,530
and you go through all of this
enormous processing that we're

165
00:09:07,530 --> 00:09:11,070
going to go through: namely
turning it into an encoded

166
00:09:11,070 --> 00:09:15,390
wave form, transmitting it,
receiving it, detecting it,

167
00:09:15,390 --> 00:09:17,720
doing all the stuff we're
going to do to it.

168
00:09:17,720 --> 00:09:21,800
If you get the 20 millisecond
segment confused, and usually

169
00:09:21,800 --> 00:09:25,970
if you make errors you
make a lot of errors.

170
00:09:25,970 --> 00:09:29,260
If at the receiver you wind up
with the wrong thing, it is

171
00:09:29,260 --> 00:09:31,420
really going to sound awful.

172
00:09:31,420 --> 00:09:34,370
They found that it's much better
if you're not quite

173
00:09:34,370 --> 00:09:38,220
sure of what that segment is,
to just send silence for 20

174
00:09:38,220 --> 00:09:39,540
milliseconds.

175
00:09:39,540 --> 00:09:42,160
The silence is hardly detectable
at all; it just

176
00:09:42,160 --> 00:09:45,080
sounds like good voice.

177
00:09:45,080 --> 00:09:47,580
I mean for most of us it really
sound wonderful to have

178
00:09:47,580 --> 00:09:50,310
a little more silence
than we usually do.

179
00:09:50,310 --> 00:09:53,370
Well enough of that.

180
00:09:53,370 --> 00:09:54,350
Then there's another thing.

181
00:09:54,350 --> 00:09:58,120
This is eight zeros per segments
that are added to

182
00:09:58,120 --> 00:10:04,790
this 172 bits as something which
is called a terminator

183
00:10:04,790 --> 00:10:06,660
for the convolutional code.

184
00:10:06,660 --> 00:10:09,290
I might say a little bit about
that but not much.

185
00:10:09,290 --> 00:10:11,890
So what we've done is to
add 12 bits and eight

186
00:10:11,890 --> 00:10:15,460
bits to this 172 bits.

187
00:10:15,460 --> 00:10:21,520
That brings us up to 192 bits,
which brings us up to 9,600

188
00:10:21,520 --> 00:10:24,590
bits per second which
is what we're now

189
00:10:24,590 --> 00:10:26,440
going to try to transmit.

190
00:10:26,440 --> 00:10:30,220
OK so that's the voice
compression part of the thing

191
00:10:30,220 --> 00:10:32,820
and a little bits of
overhead done for

192
00:10:32,820 --> 00:10:34,300
various special functions.

193
00:10:34,300 --> 00:10:39,050
The main reason I want to talk
about these overhead factors

194
00:10:39,050 --> 00:10:46,100
is that every communication
system I know starts out with

195
00:10:46,100 --> 00:10:49,920
very nice principles studying
very carefully what are the

196
00:10:49,920 --> 00:10:51,680
essential things.

197
00:10:51,680 --> 00:10:54,830
By the time you got done with
it, there are all sorts of

198
00:10:54,830 --> 00:10:58,340
little overhead items that got
thrown in to make the thing

199
00:10:58,340 --> 00:11:01,190
work and it's frustrating
to everybody.

200
00:11:01,190 --> 00:11:06,060
It's usually 10% or 20% of the
capacity of the thing, but

201
00:11:06,060 --> 00:11:08,030
it's always there.

202
00:11:08,030 --> 00:11:10,550
That's why I bring up these
two terms because that's

203
00:11:10,550 --> 00:11:13,470
exactly the kind of things
they're doing.

204
00:11:13,470 --> 00:11:16,390
They're just patching
to make things work.

205
00:11:16,390 --> 00:11:20,160
So you have many details that
lose all of the efficiency

206
00:11:20,160 --> 00:11:21,550
that you would like to have.

207
00:11:21,550 --> 00:11:26,270
Those are what makes it hard to
compare different systems.

208
00:11:26,270 --> 00:11:30,150
Each system, architecturally
nice though it might be to

209
00:11:30,150 --> 00:11:33,620
start with, always winds up
with these little things

210
00:11:33,620 --> 00:11:37,000
because of these silly little
constraints that say, since

211
00:11:37,000 --> 00:11:40,250
you have to have small delay,
you have to segment voice into

212
00:11:40,250 --> 00:11:42,920
segments which are not
much more than 20

213
00:11:42,920 --> 00:11:44,640
milliseconds long.

214
00:11:44,640 --> 00:11:47,950
Those things cause you to
do these other things.

215
00:11:47,950 --> 00:11:52,210
That's where all of
this comes in.

216
00:11:52,210 --> 00:11:57,960
OK, all of the timing in this
IS95 cell phone system,

217
00:11:57,960 --> 00:12:02,440
everything is keyed to this
9,600 bits per second and it's

218
00:12:02,440 --> 00:12:06,470
all keyed through this 20
millisecond interval.

219
00:12:06,470 --> 00:12:10,520
Everything is done in terms of
20 millisecond intervals.

220
00:12:10,520 --> 00:12:12,980
It's all a completely
block system.

221
00:12:12,980 --> 00:12:16,610
The source generates 20
milliseconds worth of data.

222
00:12:16,610 --> 00:12:19,580
You encode that into
a 192 bits.

223
00:12:19,580 --> 00:12:22,740
That gets mapped into some code
word, gets turned into

224
00:12:22,740 --> 00:12:25,520
some high frequency wave form.

225
00:12:25,520 --> 00:12:29,180
At the output you look at 20
milliseconds and that gets

226
00:12:29,180 --> 00:12:34,050
turned back into your best hope
of the 172 bits that you

227
00:12:34,050 --> 00:12:38,160
started with and from there
to some wave form.

228
00:12:38,160 --> 00:12:41,450
Every 20 milliseconds is
completely independent of

229
00:12:41,450 --> 00:12:43,380
every other 20 milliseconds.

230
00:12:43,380 --> 00:12:45,550
You don't even save any
knowledge about what the

231
00:12:45,550 --> 00:12:48,610
channel is between those
periods of time.

232
00:12:48,610 --> 00:12:51,060
Everything is independent
from one to the next.

233
00:12:54,300 --> 00:12:58,330
The point is here, we talked
a great deal about all of

234
00:12:58,330 --> 00:13:04,010
digital communication sort of
being generated from people's

235
00:13:04,010 --> 00:13:08,470
realization that they ought to
separate voice coding from

236
00:13:08,470 --> 00:13:09,230
channel coding.

237
00:13:09,230 --> 00:13:12,560
In other words, there's just
binary interface between all

238
00:13:12,560 --> 00:13:15,010
sources and all channels.

239
00:13:15,010 --> 00:13:18,920
This is a violation
of that; all cell

240
00:13:18,920 --> 00:13:21,810
phones have this violation.

241
00:13:21,810 --> 00:13:25,880
They don't have this pure
separation because all of them

242
00:13:25,880 --> 00:13:29,890
face the fact that to do this
small delay -- anytime you

243
00:13:29,890 --> 00:13:33,660
want to get small delay -- you
have to have some mixing of

244
00:13:33,660 --> 00:13:35,460
what you do with the
source and what

245
00:13:35,460 --> 00:13:37,240
you do with the channel.

246
00:13:37,240 --> 00:13:40,600
The delay has to be some
combination of what happens in

247
00:13:40,600 --> 00:13:41,850
both places.

248
00:13:44,530 --> 00:13:47,380
So, we do have that violation
and it's because of

249
00:13:47,380 --> 00:13:50,130
interactive voice.

250
00:13:50,130 --> 00:13:53,210
You probably never thought about
why it is that you need

251
00:13:53,210 --> 00:13:55,910
small delay on voice.

252
00:13:55,910 --> 00:14:00,800
If you try to talk to somebody
with a 50 millisecond delay,

253
00:14:00,800 --> 00:14:03,760
in between what you're saying
and what the other person is

254
00:14:03,760 --> 00:14:07,890
saying, you will find it turns
you into a stutter in about

255
00:14:07,890 --> 00:14:11,380
five minutes, everyone.

256
00:14:11,380 --> 00:14:14,090
The problem is we all have these
social conventions that

257
00:14:14,090 --> 00:14:18,280
we use to tell us when we can
start to talk when we hear

258
00:14:18,280 --> 00:14:20,900
silence from the other person.

259
00:14:20,900 --> 00:14:23,520
If you have a break in that
routine, even at 50

260
00:14:23,520 --> 00:14:27,280
milliseconds, it totally
screws it up.

261
00:14:27,280 --> 00:14:31,620
Both people start to talk at
the same time and it's very

262
00:14:31,620 --> 00:14:33,570
hard to have a conversation.

263
00:14:33,570 --> 00:14:37,540
Back in the early days of
telephony, they found that

264
00:14:37,540 --> 00:14:40,950
about as much delay as they
could tolerate was about 20

265
00:14:40,950 --> 00:14:42,130
milliseconds.

266
00:14:42,130 --> 00:14:44,760
When it got much longer than
that, it gets very

267
00:14:44,760 --> 00:14:46,070
objectionable.

268
00:14:46,070 --> 00:14:49,790
If you talk to somebody on the
phone who is in Japan, you

269
00:14:49,790 --> 00:14:52,370
have a little more
delay than that.

270
00:14:52,370 --> 00:14:54,440
You find it's very hard
to talk to them.

271
00:14:54,440 --> 00:14:56,460
I mean, you have to practice
a little bit, you have

272
00:14:56,460 --> 00:14:57,790
to think about it.

273
00:14:57,790 --> 00:15:01,660
If it's somebody for whom
English is a second language,

274
00:15:01,660 --> 00:15:03,500
or you have Japanese
as a second

275
00:15:03,500 --> 00:15:05,860
language, it's very easy.

276
00:15:05,860 --> 00:15:10,620
Then you both talk very slowly
so you catch up on that delay.

277
00:15:10,620 --> 00:15:10,760
but.

278
00:15:10,760 --> 00:15:14,370
If you're both talking English
very rapidly, or both Japanese

279
00:15:14,370 --> 00:15:17,030
very rapidly, it becomes
hell on wheels.

280
00:15:20,350 --> 00:15:23,450
As far as the channel is
concerned, we could also do

281
00:15:23,450 --> 00:15:27,060
very well by using longer code
words on the channel.

282
00:15:27,060 --> 00:15:29,430
Again, we're stuck by this
20 milliseconds.

283
00:15:29,430 --> 00:15:35,730
Everything has to be blocked
into 20 millisecond periods.

284
00:15:35,730 --> 00:15:40,300
OK, so the first thing as far
as coding is concerned, is

285
00:15:40,300 --> 00:15:43,530
what's called a convolutional
encoder.

286
00:15:43,530 --> 00:15:46,210
We unfortunately, have not
talked about coding at all in

287
00:15:46,210 --> 00:15:48,600
this course; we're not going
to talk about it.

288
00:15:48,600 --> 00:15:54,550
I just want to enough about
convolutional codes so you get

289
00:15:54,550 --> 00:15:57,400
some idea of what they are.

290
00:15:57,400 --> 00:16:02,880
Here's the simplest example of
a convolutional code that I

291
00:16:02,880 --> 00:16:04,530
think you can think of.

292
00:16:04,530 --> 00:16:09,080
You have a stream of input bits
which are coming in one

293
00:16:09,080 --> 00:16:11,500
per second.

294
00:16:11,500 --> 00:16:15,890
Each time an input bit comes
in, that input bit sits at

295
00:16:15,890 --> 00:16:17,710
this dock here.

296
00:16:17,710 --> 00:16:20,260
I guess most people would prefer
to put an extra memory

297
00:16:20,260 --> 00:16:24,000
element in but it just
complicates the diagram.

298
00:16:24,000 --> 00:16:28,260
You have this input bit, you
have the previous input bit,

299
00:16:28,260 --> 00:16:30,930
and you have the input
bit before that.

300
00:16:30,930 --> 00:16:35,700
What comes out, a time J is a
linear combination of this

301
00:16:35,700 --> 00:16:39,960
bit, that previous bit, and the
bit one bit before that.

302
00:16:39,960 --> 00:16:44,220
You call this a convolutional
code with a constraint length

303
00:16:44,220 --> 00:16:47,800
of two because it has memory
of these two bits.

304
00:16:47,800 --> 00:16:52,180
If you think about it a little
bit, this is a device that has

305
00:16:52,180 --> 00:16:54,690
four states.

306
00:16:54,690 --> 00:16:59,880
OK, because at time J, it needs
to remember whether this

307
00:16:59,880 --> 00:17:02,730
bit was a one or a zero
and whether this bit

308
00:17:02,730 --> 00:17:04,790
was a one or a zero.

309
00:17:04,790 --> 00:17:09,170
So it's just a linear modulo
two device that happens to

310
00:17:09,170 --> 00:17:10,780
have four states.

311
00:17:10,780 --> 00:17:15,060
It produces two bits in each
interval of time which are

312
00:17:15,060 --> 00:17:17,920
functions of this bit and
of the current state.

313
00:17:21,730 --> 00:17:26,020
In this convolutional encoder
which is used in IS95, the

314
00:17:26,020 --> 00:17:28,850
constraint length is eight
instead of two.

315
00:17:28,850 --> 00:17:34,310
In other words, you have 8 of
these memory devices here and

316
00:17:34,310 --> 00:17:37,810
the rate is one-third instead of
one-half Here you have two

317
00:17:37,810 --> 00:17:40,670
bits coming out for
each bit going in.

318
00:17:40,670 --> 00:17:43,090
There you have three
bits coming out for

319
00:17:43,090 --> 00:17:44,550
each bit going in.

320
00:17:44,550 --> 00:17:46,500
It's the same principle.

321
00:17:51,190 --> 00:17:55,660
If you think about it a little
bit, as you increase the

322
00:17:55,660 --> 00:18:00,020
constraint length, the number
of possible states that you

323
00:18:00,020 --> 00:18:03,680
have is going up very rapidly.

324
00:18:03,680 --> 00:18:06,490
So, if you have a constraint
length of eight, which means

325
00:18:06,490 --> 00:18:09,550
eight binary digits stored
there, you have two to the

326
00:18:09,550 --> 00:18:14,310
eighth different states,
which is 256 states.

327
00:18:14,310 --> 00:18:17,600
If you added one more state to
this thing, you would double

328
00:18:17,600 --> 00:18:18,850
the complexity.

329
00:18:21,750 --> 00:18:24,420
Well, it turns out that because
of the way the decoder

330
00:18:24,420 --> 00:18:28,800
works, if you added one more bit
to this block length, it

331
00:18:28,800 --> 00:18:31,180
would multiply the complexity
of the decoder

332
00:18:31,180 --> 00:18:34,430
by a factor of two.

333
00:18:34,430 --> 00:18:37,300
So, when you try to decide how
long these constraint lengths

334
00:18:37,300 --> 00:18:41,250
should be, you have to take into
account that every time

335
00:18:41,250 --> 00:18:43,840
you make it one bit longer,
yes, the thing is going to

336
00:18:43,840 --> 00:18:45,600
work better.

337
00:18:45,600 --> 00:18:50,300
Also, you make it twice
as complex.

338
00:18:50,300 --> 00:18:52,790
Therefore, you have to wait
another six months before you

339
00:18:52,790 --> 00:18:54,640
produce it at the same cost.

340
00:18:58,110 --> 00:19:00,210
OK, we're going to
use a Viterbi

341
00:19:00,210 --> 00:19:02,430
algorithm for decoding.

342
00:19:02,430 --> 00:19:07,600
If you don't know what the
Viterbi algorithm is fine.

343
00:19:07,600 --> 00:19:11,890
If you think in terms of finite
state devices, think of

344
00:19:11,890 --> 00:19:17,160
it this way; you have a device
here which has four states.

345
00:19:17,160 --> 00:19:22,010
Somehow the decoder has to
realize at each instant of

346
00:19:22,010 --> 00:19:25,950
time, if it's gonna decode,
it could either

347
00:19:25,950 --> 00:19:29,000
decode the bits here.

348
00:19:29,000 --> 00:19:32,800
A nicer way to think of it is,
it decodes the state, at each

349
00:19:32,800 --> 00:19:34,520
instant of time.

350
00:19:34,520 --> 00:19:37,200
If it decodes the state at
each instant of time, it

351
00:19:37,200 --> 00:19:39,690
doesn't really have to
have any memory.

352
00:19:39,690 --> 00:19:42,830
As soon as it knows what the
state is at one unit of time,

353
00:19:42,830 --> 00:19:46,610
then it has a very simple
decision to make to figure out

354
00:19:46,610 --> 00:19:50,400
what the incoming bit is and
what the state is at the next

355
00:19:50,400 --> 00:19:51,600
instant of time.

356
00:19:51,600 --> 00:19:55,070
And what a Viterbi decoder is,
is something that does maximum

357
00:19:55,070 --> 00:19:59,620
likelihood decisions
on the state.

358
00:19:59,620 --> 00:20:02,950
There's a nice trellis diagram
to talk about how that's done,

359
00:20:02,950 --> 00:20:03,510
in the notes.

360
00:20:03,510 --> 00:20:05,760
You can read about it,
it's interesting.

361
00:20:05,760 --> 00:20:08,760
Many of you who have probably
seen about it, it's sort of

362
00:20:08,760 --> 00:20:11,860
the easiest thing to
explain, as far as

363
00:20:11,860 --> 00:20:13,560
coding theory is concerned.

364
00:20:13,560 --> 00:20:16,810
It's the easiest thing to
explain until you put all the

365
00:20:16,810 --> 00:20:19,310
notation in.

366
00:20:19,310 --> 00:20:21,750
Then whoever does it, as soon
as they put all of the

367
00:20:21,750 --> 00:20:24,890
notation in, it becomes
a bloody mess.

368
00:20:24,890 --> 00:20:26,240
Anyway, the idea is simple.

369
00:20:31,870 --> 00:20:36,100
So at that point, we can sort
of summarize what we've done

370
00:20:36,100 --> 00:20:39,550
as far as waste compression
and channel coding.

371
00:20:39,550 --> 00:20:44,940
So far, the IS95 standard is
pretty much the same as any

372
00:20:44,940 --> 00:20:47,020
other cellular standard.

373
00:20:47,020 --> 00:20:49,800
All of them, it turns out,
use convolutional codes.

374
00:20:49,800 --> 00:20:53,190
Whether that's a good idea or
not is another question, but

375
00:20:53,190 --> 00:20:56,260
they all do.

376
00:20:56,260 --> 00:20:59,660
It certainly is a very
sensible thing to do.

377
00:20:59,660 --> 00:21:03,370
All of them use the
same segmentation.

378
00:21:03,370 --> 00:21:08,190
All of them use similar
techniques for doing voice

379
00:21:08,190 --> 00:21:09,750
compression.

380
00:21:09,750 --> 00:21:11,410
All of them have all these
little overhead

381
00:21:11,410 --> 00:21:13,850
terms that come in.

382
00:21:13,850 --> 00:21:18,710
If you look at the numbers of
what's going on, we started

383
00:21:18,710 --> 00:21:22,340
out with a 172 bits per second,
which was what comes

384
00:21:22,340 --> 00:21:24,790
out of the voice compressor.

385
00:21:24,790 --> 00:21:27,610
You then have these two
overhead items.

386
00:21:27,610 --> 00:21:31,500
Incidentally this eight bit
convolutional terminator, we

387
00:21:31,500 --> 00:21:35,400
can now get some idea
of what that's for.

388
00:21:35,400 --> 00:21:39,780
You put in your 172 bits here.

389
00:21:39,780 --> 00:21:42,680
You're thinking of this thing in
terms of the state of each

390
00:21:42,680 --> 00:21:44,660
unit of time.

391
00:21:44,660 --> 00:21:47,780
If you're going to figure out
what's going on at the end,

392
00:21:47,780 --> 00:21:53,610
after you put in your 172 bits,
you have to put in a

393
00:21:53,610 --> 00:21:58,330
couple of extra zeros to let
this thing settle down.

394
00:21:58,330 --> 00:22:01,550
You have to let this bit go
all the way through this

395
00:22:01,550 --> 00:22:04,840
device so you got enough
data out about it that

396
00:22:04,840 --> 00:22:06,050
you can decode it.

397
00:22:06,050 --> 00:22:09,860
So that's what that terminator
is for, for putting zeros in

398
00:22:09,860 --> 00:22:13,580
at the end of the sequence so
you can view it all as one

399
00:22:13,580 --> 00:22:14,830
block code.

400
00:22:18,090 --> 00:22:21,300
Again, this is overhead, which
is caused by the need for

401
00:22:21,300 --> 00:22:22,190
small delay.

402
00:22:22,190 --> 00:22:25,380
If you're going to need small
delay, that overhead term

403
00:22:25,380 --> 00:22:27,730
would be much, much smaller.

404
00:22:27,730 --> 00:22:31,820
So at that point, we're up to
9.6 kilobits per second and

405
00:22:31,820 --> 00:22:34,690
we're up 192 bits per segment.

406
00:22:34,690 --> 00:22:38,210
Then we go into this
convolutional encoder and the

407
00:22:38,210 --> 00:22:41,830
convolutional encoder
multiplies things

408
00:22:41,830 --> 00:22:44,130
by a factor of three.

409
00:22:44,130 --> 00:22:47,170
In fact, the rate one-third is
a little bit different for

410
00:22:47,170 --> 00:22:50,430
most of the other standards
because one of the things that

411
00:22:50,430 --> 00:22:55,660
we're going to be doing here,
since we're mapping this input

412
00:22:55,660 --> 00:22:58,950
into one and a quarter mega
bits, that's a considerably

413
00:22:58,950 --> 00:23:01,690
broader band than these
other standards used.

414
00:23:01,690 --> 00:23:05,710
The other standards are quite
narrow band and therefore they

415
00:23:05,710 --> 00:23:11,490
don't want to have a large
number of bits per second.

416
00:23:11,490 --> 00:23:18,010
Here we're going to wind up
talking about 28.8 kilobits

417
00:23:18,010 --> 00:23:23,780
per second at this point which
is 576 bits per second, which

418
00:23:23,780 --> 00:23:26,910
is three times what we
started out with.

419
00:23:26,910 --> 00:23:31,050
We've expanded the number of
bits by a factor of three.

420
00:23:31,050 --> 00:23:35,200
If you question whether this
makes sense to get a slightly

421
00:23:35,200 --> 00:23:39,370
smaller error probability
through coding but increasing

422
00:23:39,370 --> 00:23:43,680
your rate by a factor of three,
that's a perfectly

423
00:23:43,680 --> 00:23:46,790
sensible question to ask.

424
00:23:46,790 --> 00:23:50,490
It just turns out that you do
get a saving from that and

425
00:23:50,490 --> 00:23:53,640
that's what all of coding theory
is about, how much

426
00:23:53,640 --> 00:23:55,950
savings you actually get.

427
00:23:55,950 --> 00:23:58,940
In fact, the savings are
pretty considerable.

428
00:23:58,940 --> 00:24:03,060
So, at this point, we're up
here at 28.8 kilobits per

429
00:24:03,060 --> 00:24:08,030
second with 578, 576
bits per segment.

430
00:24:08,030 --> 00:24:10,270
We then go through
an interleaver.

431
00:24:10,270 --> 00:24:13,010
Don't ask yet what the
interleaver is for.

432
00:24:13,010 --> 00:24:17,510
All the interleaver does is
takes these 576 bits and it's

433
00:24:17,510 --> 00:24:19,390
scrambles them all around.

434
00:24:19,390 --> 00:24:22,910
The receiver knows how they've
been scramble so the receiver

435
00:24:22,910 --> 00:24:24,660
can unscramble them again.

436
00:24:24,660 --> 00:24:28,400
Why you'd need that is something
we will talk about

437
00:24:28,400 --> 00:24:29,910
later, a good deal later.

438
00:24:33,870 --> 00:24:36,980
The next thing we're going to
do, you thought you were

439
00:24:36,980 --> 00:24:38,320
through with coding but no.

440
00:24:38,320 --> 00:24:41,540
In this system, they're actually
two stages of coding

441
00:24:41,540 --> 00:24:42,980
that you go through.

442
00:24:42,980 --> 00:24:47,190
You can view one of them as
modulation instead of coding.

443
00:24:47,190 --> 00:24:49,670
Therefore, you can claim you're
only doing one stage of

444
00:24:49,670 --> 00:24:54,070
coding and one stage of fairly
complex modulation.

445
00:24:54,070 --> 00:24:56,990
You remember when we talked
about orthogonal codewords.

446
00:24:56,990 --> 00:25:01,200
We said we could view orthogonal
codewords almost as

447
00:25:01,200 --> 00:25:04,920
easily, either as a coding
technique or as

448
00:25:04,920 --> 00:25:06,360
a modulation technique.

449
00:25:06,360 --> 00:25:09,240
Mainly, you'd gather together
lots of bits and then you'd

450
00:25:09,240 --> 00:25:13,330
form codewords, which we're
signals, which had a large

451
00:25:13,330 --> 00:25:15,440
number of dimensions in them.

452
00:25:15,440 --> 00:25:18,880
We're going to do the
same thing here.

453
00:25:18,880 --> 00:25:23,530
We are going to take this
interleaver output; we're

454
00:25:23,530 --> 00:25:27,260
going to segment it into
six, six bit blocks.

455
00:25:27,260 --> 00:25:31,600
Then each six bit block is going
to choose one of a set

456
00:25:31,600 --> 00:25:35,650
of 64 orthogonal codewords.

457
00:25:35,650 --> 00:25:38,350
I mean, with six bits, you have
two to the sixth, which

458
00:25:38,350 --> 00:25:40,750
is 64 different combinations.

459
00:25:40,750 --> 00:25:43,300
So, if you're going to use
orthogonal codewords, you need

460
00:25:43,300 --> 00:25:45,760
64 of them.

461
00:25:45,760 --> 00:25:48,660
When we were talking about
orthogonal codewords before,

462
00:25:48,660 --> 00:25:51,910
we didn't quite know how
to generate them.

463
00:25:51,910 --> 00:25:55,630
We then said last time, that may
be using PN sequences is a

464
00:25:55,630 --> 00:25:57,170
nice way of doing it.

465
00:25:57,170 --> 00:25:59,790
That's not quite exact.

466
00:25:59,790 --> 00:26:02,910
Here using Hadamard matrices
is a nice exact

467
00:26:02,910 --> 00:26:04,610
way of doing it.

468
00:26:04,610 --> 00:26:09,340
That happens to be the way it's
done and it's simple.

469
00:26:09,340 --> 00:26:15,140
I mean, you have a Hadamard
matrix for each integer b.

470
00:26:15,140 --> 00:26:18,470
If you start out with b equals
one, which is one bit that you

471
00:26:18,470 --> 00:26:21,450
want to encode.

472
00:26:21,450 --> 00:26:24,390
You have a matrix which consists
of 2 orthogonal

473
00:26:24,390 --> 00:26:28,810
codewords one of which is 0,
0 and the other is 0, 1.

474
00:26:28,810 --> 00:26:30,900
There aren't too many choices
for that and they're all

475
00:26:30,900 --> 00:26:33,100
equivalent.

476
00:26:33,100 --> 00:26:36,740
Then when you want to go to b
equals two, the thing you'd do

477
00:26:36,740 --> 00:26:39,490
is make a matrix and the rows of
the matrix are going to be

478
00:26:39,490 --> 00:26:40,740
the codewords.

479
00:26:44,500 --> 00:26:48,020
The columns correspond to the
bits in the codeword.

480
00:26:48,020 --> 00:26:52,740
The first codeword here is 0,
0 second codeword is 0, 1.

481
00:26:52,740 --> 00:26:56,210
The first codeword here
is 0, 0, 0, 0 the next

482
00:26:56,210 --> 00:26:58,050
one is 0, 1, 0, 1.

483
00:26:58,050 --> 00:27:01,330
For orthogonal codes, the block
lengths of the code and

484
00:27:01,330 --> 00:27:04,130
the number of codewords is
going to be the same.

485
00:27:04,130 --> 00:27:06,950
So the thing you'd do is you
take this matrix, you put it

486
00:27:06,950 --> 00:27:09,910
there, you put it there,
and you put it there.

487
00:27:09,910 --> 00:27:13,680
Then you compliment the matrix
and you put it there.

488
00:27:13,680 --> 00:27:16,040
OK why does that work?

489
00:27:16,040 --> 00:27:19,250
Well if we just look at this
part of it, this was an

490
00:27:19,250 --> 00:27:23,010
orthogonal code, this was
an orthogonal code.

491
00:27:23,010 --> 00:27:33,170
In other words, each of them
differ from each of the others

492
00:27:33,170 --> 00:27:35,840
in half the positions, which
is why you think of it as

493
00:27:35,840 --> 00:27:37,670
being orthogonal.

494
00:27:37,670 --> 00:27:43,010
This is the confusion that
runs through all of

495
00:27:43,010 --> 00:27:44,260
communication theory.

496
00:27:44,260 --> 00:27:47,720
We might as well get rid of
that confusion right now.

497
00:27:47,720 --> 00:27:51,410
When you talk about binary
sequences and you say they're

498
00:27:51,410 --> 00:27:55,750
orthogonal, what you mean is, if
you turn that sequence into

499
00:27:55,750 --> 00:28:01,310
a 2PAM signal, those
corresponding signals are

500
00:28:01,310 --> 00:28:02,250
orthogonal.

501
00:28:02,250 --> 00:28:07,020
In other words, an orthogonal
binary sequence, an orthogonal

502
00:28:07,020 --> 00:28:11,800
set of binary sequences is a set
of binary sequences where

503
00:28:11,800 --> 00:28:14,540
each of the sequences differ
from each of the other

504
00:28:14,540 --> 00:28:19,280
sequences in half of
the positions.

505
00:28:19,280 --> 00:28:22,380
Here with these Hadamard
matrices, the way that's done

506
00:28:22,380 --> 00:28:25,790
is that one of the sequences
is always all zero and the

507
00:28:25,790 --> 00:28:30,590
other sequences are all half
ones and half zeros.

508
00:28:30,590 --> 00:28:35,330
It turns out that when you add
any two sequences, add this

509
00:28:35,330 --> 00:28:39,680
sequence to this sequence for
example, you got something

510
00:28:39,680 --> 00:28:41,140
else, which is half ones .

511
00:28:41,140 --> 00:28:45,610
In fact, something else which is
in there, is what's called

512
00:28:45,610 --> 00:28:47,670
a group code.

513
00:28:47,670 --> 00:28:51,740
When you add any two codewords
you got another code.

514
00:28:51,740 --> 00:28:55,680
Anyway, when you look at this,
which is mapped into

515
00:28:55,680 --> 00:28:59,140
here and here --

516
00:29:01,680 --> 00:29:03,980
I think the argument is
difficult here because it's

517
00:29:03,980 --> 00:29:07,860
too simple minded, so you
don't see it in it's

518
00:29:07,860 --> 00:29:12,520
generality -- each time you go
from one b to the next b, the

519
00:29:12,520 --> 00:29:13,980
thing you do is the
same thing.

520
00:29:13,980 --> 00:29:17,410
You start out with this matrix,
put it there, you put

521
00:29:17,410 --> 00:29:19,600
it there, you put it there,
and you put the

522
00:29:19,600 --> 00:29:22,270
complement of it there.

523
00:29:22,270 --> 00:29:24,770
What that does is when you look
at the first half of the

524
00:29:24,770 --> 00:29:29,670
matrix, all of these differ in
half the positions because

525
00:29:29,670 --> 00:29:32,070
they differ in half the
positions here, and they

526
00:29:32,070 --> 00:29:33,970
differ in half the
positions here.

527
00:29:33,970 --> 00:29:37,570
So, they differ in half the
positions over all.

528
00:29:37,570 --> 00:29:40,980
When you look at everything down
here, they differ in half

529
00:29:40,980 --> 00:29:44,100
the positions for the same
reason because complementing

530
00:29:44,100 --> 00:29:47,570
this doesn't change any of those
distance properties.

531
00:29:47,570 --> 00:29:49,510
When you look at the difference
between these and

532
00:29:49,510 --> 00:29:52,520
these, it's the same kind of
thing if you think about it

533
00:29:52,520 --> 00:29:55,500
for a couple of minutes.

534
00:29:55,500 --> 00:30:00,400
So, this is an orthogonal
code.

535
00:30:00,400 --> 00:30:03,340
Why do we want to use this
orthogonal code rather than

536
00:30:03,340 --> 00:30:07,520
just an orthogonal code which
uses the first degree of

537
00:30:07,520 --> 00:30:09,710
freedom and sends an enormous
amount of energy?

538
00:30:09,710 --> 00:30:14,110
Or the second degree of freedom
sends an enormous

539
00:30:14,110 --> 00:30:15,820
amount of energy and so forth?

540
00:30:15,820 --> 00:30:18,690
That's the same thing we were
talking about last time with

541
00:30:18,690 --> 00:30:20,310
regard to channel measurement.

542
00:30:20,310 --> 00:30:23,420
You don't want to send enormous
amounts of energy in

543
00:30:23,420 --> 00:30:24,840
any one degree of freedom.

544
00:30:24,840 --> 00:30:28,580
You want to spread it out over
all the degrees of freedom.

545
00:30:28,580 --> 00:30:31,820
That's what all these codes are
doing; all these codes are

546
00:30:31,820 --> 00:30:36,130
using 2PAM on each
degree of freedom

547
00:30:36,130 --> 00:30:37,600
to generate a codeword.

548
00:30:37,600 --> 00:30:43,102
So the codewords all have sort
of uniform power in them.

549
00:30:46,950 --> 00:30:52,870
OK, so at this point, we have
gone into this orthogonal code

550
00:30:52,870 --> 00:30:57,610
generator with 28.8 kilobits
per second.

551
00:30:57,610 --> 00:31:02,950
We have come out of it with 28.8
kilobits per second times

552
00:31:02,950 --> 00:31:04,420
64 over six.

553
00:31:04,420 --> 00:31:08,770
Namely for each six bit
segment in, we've

554
00:31:08,770 --> 00:31:11,440
gotten 64 bits out.

555
00:31:11,440 --> 00:31:14,900
So the total number of bits that
we have has gone up by a

556
00:31:14,900 --> 00:31:18,270
factor of 64 divided by six.

557
00:31:18,270 --> 00:31:23,660
So we're suddenly up to 307.2
kilobits per second.

558
00:31:23,660 --> 00:31:26,900
What we're trying to do is get
ourselves -- by hook or by

559
00:31:26,900 --> 00:31:30,300
crook -- get ourselves up from
these very small bit rates

560
00:31:30,300 --> 00:31:33,860
that we need to represent voice,
up to these large bit

561
00:31:33,860 --> 00:31:38,970
rates, 1.25 megabits per second,
which we're going to

562
00:31:38,970 --> 00:31:41,780
spread this wave form to.

563
00:31:41,780 --> 00:31:45,430
All the reasons we want to
spread the wave form, I'll

564
00:31:45,430 --> 00:31:47,190
talk about them later.

565
00:31:47,190 --> 00:31:50,330
For now let's just think about
it as saying, somehow or other

566
00:31:50,330 --> 00:31:54,300
we want to spread the wave
form out and turn a small

567
00:31:54,300 --> 00:31:56,770
number of bits into a large
number of bits.

568
00:31:56,770 --> 00:31:58,690
So we've done a pretty
significant part

569
00:31:58,690 --> 00:32:00,840
of that right here.

570
00:32:00,840 --> 00:32:03,830
If we think of turning these
binary rows of the Hadamard

571
00:32:03,830 --> 00:32:09,450
matrix and modulate them
by 2PAM we wind

572
00:32:09,450 --> 00:32:11,080
up with wave forms.

573
00:32:11,080 --> 00:32:13,760
The wave forms are orthogonal.

574
00:32:13,760 --> 00:32:16,300
If you wanted to think of taking
these wave forms and

575
00:32:16,300 --> 00:32:20,290
then transmitting them up to
passband, we would wind up

576
00:32:20,290 --> 00:32:26,760
with the bandwidth
of 307,000 hertz.

577
00:32:26,760 --> 00:32:32,620
That's not enough yet, we want
to go up to 1.25 megahertz.

578
00:32:32,620 --> 00:32:35,990
Anyway, these wave forms are
called Walsh functions.

579
00:32:35,990 --> 00:32:40,290
So the wave forms that you got
from Hadamard matrices are

580
00:32:40,290 --> 00:32:42,130
called Walsh functions.

581
00:32:42,130 --> 00:32:45,450
You have to find something to
honor everybody that's done a

582
00:32:45,450 --> 00:32:48,710
significant amount in this field
and Walsh was one of

583
00:32:48,710 --> 00:32:50,600
these people.

584
00:32:50,600 --> 00:32:54,330
Walsh functions are quite famous
and all they are are

585
00:32:54,330 --> 00:32:57,490
just these orthogonal
wave forms.

586
00:32:57,490 --> 00:33:02,060
So, we now have an orthogonal
code of length 64.

587
00:33:02,060 --> 00:33:03,960
The receiver, I'm going
to talk about the

588
00:33:03,960 --> 00:33:06,130
receiver more later.

589
00:33:06,130 --> 00:33:10,190
In essence, what it's going to
do is take the 64 orthogonal

590
00:33:10,190 --> 00:33:16,170
wave forms, only one of them
will get transmitted in each

591
00:33:16,170 --> 00:33:18,290
of these small units of time.

592
00:33:18,290 --> 00:33:21,820
When the period of time
corresponding to six bits into

593
00:33:21,820 --> 00:33:25,870
the encoder, we have to decode
which of these 64

594
00:33:25,870 --> 00:33:27,600
wave forms was sent.

595
00:33:27,600 --> 00:33:31,230
We're going to do that by
using a rake receiver.

596
00:33:31,230 --> 00:33:34,080
That's what's used in IS95.

597
00:33:34,080 --> 00:33:36,360
This rake receiver is different
from the one we

598
00:33:36,360 --> 00:33:37,070
talked about.

599
00:33:37,070 --> 00:33:40,410
The one we talked about, we were
making a decision between

600
00:33:40,410 --> 00:33:42,310
two hypotheses.

601
00:33:42,310 --> 00:33:45,580
Here we're making a decision
between 64 possible

602
00:33:45,580 --> 00:33:46,830
hypotheses.

603
00:33:48,670 --> 00:33:51,040
If you can remember the
structure of that rake

604
00:33:51,040 --> 00:33:55,520
receiver, it sort of split into
two separate sections.

605
00:33:55,520 --> 00:33:58,710
One section was used for the
decision on one of the wave

606
00:33:58,710 --> 00:34:01,790
forms, the other one, on
the other wave form.

607
00:34:01,790 --> 00:34:06,140
When we do this with 64 wave
forms, it spreads into 64

608
00:34:06,140 --> 00:34:08,420
different sections,
which is why it's

609
00:34:08,420 --> 00:34:11,860
called the rake receiver.

610
00:34:11,860 --> 00:34:14,990
If you draw a picture of
it looks like a rake.

611
00:34:14,990 --> 00:34:17,700
You start out here with the
handle and then you have it

612
00:34:17,700 --> 00:34:22,410
spread out into 64 different
tines and all of these tines

613
00:34:22,410 --> 00:34:26,290
have all of this signal
processing going on.

614
00:34:26,290 --> 00:34:30,490
At the output you come back and
you change what your model

615
00:34:30,490 --> 00:34:34,200
of the channel is depending on
the actual decision that

616
00:34:34,200 --> 00:34:35,450
you've made.

617
00:34:37,620 --> 00:34:42,370
So what we're using is a rake
receiver but a rake receiver

618
00:34:42,370 --> 00:34:49,400
which has 64 decision devices
instead of two.

619
00:34:49,400 --> 00:34:52,980
Suppose we go into an orthogonal
code using seven

620
00:34:52,980 --> 00:34:56,610
bits instead of six bits.

621
00:34:56,610 --> 00:35:00,350
Now, at this point, you're
talking about real money.

622
00:35:00,350 --> 00:35:03,350
OK, because at this point,
you're talking about taking

623
00:35:03,350 --> 00:35:09,900
this rake receiver and turning
it from 64 arms into 128 arms.

624
00:35:09,900 --> 00:35:11,860
Now, you can do that because
these things are essentially

625
00:35:11,860 --> 00:35:15,730
free now and computation
is essentially free.

626
00:35:15,730 --> 00:35:18,980
At the time when this was
designed, there was a very

627
00:35:18,980 --> 00:35:23,590
hard constraint in terms of
complexity about how many bits

628
00:35:23,590 --> 00:35:27,700
they can encode together into
orthogonal wave forms.

629
00:35:27,700 --> 00:35:30,040
I'll show you why
in a little bit.

630
00:35:30,040 --> 00:35:32,770
It wouldn't have done them much
better to have a larger

631
00:35:32,770 --> 00:35:34,900
set of orthogonal wave
forms anyway.

632
00:35:39,100 --> 00:35:45,540
It also uses incoherent soft
decisions as a way of doing

633
00:35:45,540 --> 00:35:46,400
its detection.

634
00:35:46,400 --> 00:35:49,970
We talked about incoherent
detection.

635
00:35:49,970 --> 00:35:53,140
This rake receiver uses that
instead of the coherent

636
00:35:53,140 --> 00:35:56,260
detection that we talked
about in class.

637
00:35:56,260 --> 00:35:59,930
If you just put together in
your mind, the lecture we

638
00:35:59,930 --> 00:36:03,320
spent talking about rake
receivers and the one we spent

639
00:36:03,320 --> 00:36:06,820
talking about incoherent
detection and you put them

640
00:36:06,820 --> 00:36:11,260
together, you have what this
receiver is doing.

641
00:36:11,260 --> 00:36:13,140
I'll talk about just a
little more as we go.

642
00:36:17,410 --> 00:36:23,890
OK, if we now imagine these are
orthogonal codewords and

643
00:36:23,890 --> 00:36:26,660
suppose that each orthogonal
codeword has an

644
00:36:26,660 --> 00:36:30,790
energy e sub s.

645
00:36:30,790 --> 00:36:34,160
Suppose for the time being
that the channel is

646
00:36:34,160 --> 00:36:38,830
represented perfectly by a
single-tap model and we know

647
00:36:38,830 --> 00:36:41,640
what the energy in that
single-tap model is.

648
00:36:41,640 --> 00:36:45,710
We don't know what the
phase so we're

649
00:36:45,710 --> 00:36:49,170
using incoherent detection.

650
00:36:49,170 --> 00:36:51,810
What's the error probability?

651
00:36:51,810 --> 00:36:56,030
Well the error probability for
an incoherent receiver for

652
00:36:56,030 --> 00:37:01,390
making a decision between two
possibilities was one-half

653
00:37:01,390 --> 00:37:06,310
times e to the minus energy
divided by 2 N 0.

654
00:37:06,310 --> 00:37:09,400
Here we have 64 different
possibilities.

655
00:37:09,400 --> 00:37:13,320
So we're going to transmit one
of these wave forms and we now

656
00:37:13,320 --> 00:37:17,030
use the union band to say
there's this probability of

657
00:37:17,030 --> 00:37:21,730
error to each of the other
63 possible wave forms.

658
00:37:21,730 --> 00:37:24,090
we could make an error
to any one of them.

659
00:37:24,090 --> 00:37:26,750
That's equally likely to make
an error to any one of them

660
00:37:26,750 --> 00:37:28,930
because they're each orthogonal
to the one that

661
00:37:28,930 --> 00:37:30,410
we're dealing with.

662
00:37:30,410 --> 00:37:32,930
So this is a reasonably good
bound on the error

663
00:37:32,930 --> 00:37:35,070
probability.

664
00:37:35,070 --> 00:37:39,210
OK, now you go back from this to
look at the reason why, one

665
00:37:39,210 --> 00:37:42,120
of the main reasons why
you want to do this.

666
00:37:42,120 --> 00:37:46,180
E sub s is the amount of energy
you use to transmit six

667
00:37:46,180 --> 00:37:49,500
bits instead of one bit.

668
00:37:49,500 --> 00:37:52,140
Therefore, when you look at the
energy per bit that you're

669
00:37:52,140 --> 00:37:55,670
using, it's e sub s
divided by six.

670
00:37:55,670 --> 00:37:59,550
So, your probability of error,
-- if in fact you were making

671
00:37:59,550 --> 00:38:03,850
hard decisions at the output of
this incoherent detector --

672
00:38:03,850 --> 00:38:07,930
would be in the order of 63 over
2 times e to the minus

673
00:38:07,930 --> 00:38:10,610
3eb over N0.

674
00:38:10,610 --> 00:38:15,690
This is a considerably larger
exponent and therefore, a

675
00:38:15,690 --> 00:38:18,890
considerably lower error
probability than we were

676
00:38:18,890 --> 00:38:20,860
getting when we were
talking about

677
00:38:20,860 --> 00:38:22,970
transmitting single bits.

678
00:38:22,970 --> 00:38:26,390
In other words, the same thing
is going on here as was going

679
00:38:26,390 --> 00:38:29,390
on when we were talking about
getting up the channel

680
00:38:29,390 --> 00:38:33,680
capacity using a large number
of orthogonal wave forms.

681
00:38:33,680 --> 00:38:35,110
It's the same idea.

682
00:38:35,110 --> 00:38:39,540
When you encode lots of bits
together, you make a joint

683
00:38:39,540 --> 00:38:44,310
decision on all of them,
you make a gain.

684
00:38:44,310 --> 00:38:46,570
That's exactly what's
happening here.

685
00:38:46,570 --> 00:38:51,330
You made a gain because you've
taken the amount of energy

686
00:38:51,330 --> 00:38:54,570
that you have available for
each one of your bits and

687
00:38:54,570 --> 00:38:57,510
you've combined it all
so that you get this

688
00:38:57,510 --> 00:39:00,290
bigger exponent in here.

689
00:39:00,290 --> 00:39:02,700
If you're lucky, the exponent
is big enough that it

690
00:39:02,700 --> 00:39:09,070
overwhelms this term and your
decision comes out with very

691
00:39:09,070 --> 00:39:10,730
small error probability.

692
00:39:10,730 --> 00:39:13,980
Well, as it turns out, we're not
interested in making these

693
00:39:13,980 --> 00:39:15,130
hard decisions.

694
00:39:15,130 --> 00:39:20,160
What we're really interested
in doing is just sending a

695
00:39:20,160 --> 00:39:24,190
likelihood ratio back to this
Viterbi decoder which it can

696
00:39:24,190 --> 00:39:26,820
use in making final decisions.

697
00:39:26,820 --> 00:39:30,160
To see how well that's going to
work, this is exactly the

698
00:39:30,160 --> 00:39:32,100
thing you want to look at.

699
00:39:32,100 --> 00:39:37,030
This is what's telling you, if
E b is large enough your

700
00:39:37,030 --> 00:39:40,450
decisions, if you had to make
them, would be very good.

701
00:39:40,450 --> 00:39:43,660
Therefore, if instead of making
decisions, you pass

702
00:39:43,660 --> 00:39:47,470
likelihood ratios on, those
likelihood ratios are going to

703
00:39:47,470 --> 00:39:49,880
have a lot of information
in them.

704
00:39:49,880 --> 00:39:54,010
Essentially, those likelihood
ratios tell you what those

705
00:39:54,010 --> 00:39:56,100
codewords are.

706
00:39:56,100 --> 00:40:01,650
OK, now, the effect of fading
is to change this E sub b

707
00:40:01,650 --> 00:40:04,510
because when we were talking
about this incoherent

708
00:40:04,510 --> 00:40:12,100
detection, we were looking at
the energy per bit after going

709
00:40:12,100 --> 00:40:13,350
through the channel.

710
00:40:15,990 --> 00:40:19,470
So, this is the error
probability for a particular

711
00:40:19,470 --> 00:40:21,940
received energy per bit.

712
00:40:21,940 --> 00:40:25,270
Sometimes when the channel is
badly faded, this number is

713
00:40:25,270 --> 00:40:27,070
very small.

714
00:40:27,070 --> 00:40:30,170
This bound is a lot bigger than
one but you don't care

715
00:40:30,170 --> 00:40:33,820
about it because the bound
is no good then.

716
00:40:37,010 --> 00:40:41,090
When the channel is good, this
number is large and this

717
00:40:41,090 --> 00:40:43,860
probability there is very small
and your likelihood

718
00:40:43,860 --> 00:40:47,390
ratios give you a lot
of information.

719
00:40:47,390 --> 00:40:51,110
If you had multitap diversity
instead of the single-tap

720
00:40:51,110 --> 00:40:53,390
here, if you have
a lot of taps.

721
00:40:53,390 --> 00:40:56,080
If you have a lot of taps you
can visualize this as getting

722
00:40:56,080 --> 00:41:00,230
independent readings
on the channel.

723
00:41:00,230 --> 00:41:02,630
Therefore, you can view it
as getting independent

724
00:41:02,630 --> 00:41:07,040
information about the bits that
were sent and this is

725
00:41:07,040 --> 00:41:09,910
what diversity is.

726
00:41:09,910 --> 00:41:12,670
I mean, the trouble with these
Rayleigh fading channels is

727
00:41:12,670 --> 00:41:15,190
when they're faded there's
nothing you can do.

728
00:41:15,190 --> 00:41:18,800
If you have multiple taps
instead of one tap, then in

729
00:41:18,800 --> 00:41:21,320
fact, you have diversity
between all of them.

730
00:41:21,320 --> 00:41:23,340
If any of them are good,
then you decode.

731
00:41:23,340 --> 00:41:23,660
Yes?

732
00:41:23,660 --> 00:41:28,752
AUDIENCE: You were saying
earlier that PAM is not ideal

733
00:41:28,752 --> 00:41:31,140
[INAUDIBLE].

734
00:41:31,140 --> 00:41:33,140
[INAUDIBLE]

735
00:41:33,140 --> 00:41:36,403
Why is the standard using 2PAM
instead of pulse position

736
00:41:36,403 --> 00:41:38,690
modulation?

737
00:41:38,690 --> 00:41:40,540
PROFESSOR: Well because it's
using these long codewords.

738
00:41:45,500 --> 00:41:47,880
Because back when we were
analyzing it, we were

739
00:41:47,880 --> 00:41:50,590
analyzing it using
two codewords.

740
00:41:50,590 --> 00:41:54,600
Those two codewords were
orthogonal to each other.

741
00:41:54,600 --> 00:41:59,990
We could have made them plus
one minus one and plus one

742
00:41:59,990 --> 00:42:03,420
minus one for the other one if
we had in fact known what the

743
00:42:03,420 --> 00:42:06,510
channel was ahead of time, OK.

744
00:42:14,010 --> 00:42:16,370
That brings up a good point
because you have to get to

745
00:42:16,370 --> 00:42:18,030
started somehow.

746
00:42:18,030 --> 00:42:20,590
I mean you have to know somehow,
what's going on at

747
00:42:20,590 --> 00:42:23,370
the channel at the point
where you start.

748
00:42:23,370 --> 00:42:24,730
I'm not going to talk
about that.

749
00:42:28,390 --> 00:42:32,740
If you have this multitap
diversity than E sub b is

750
00:42:32,740 --> 00:42:34,170
going to be better
than it would be.

751
00:42:34,170 --> 00:42:41,460
Otherwise, this says, if you can
make the bandwidth bigger,

752
00:42:41,460 --> 00:42:43,600
as you make the bandwidth
bigger, the bits

753
00:42:43,600 --> 00:42:45,670
are coming in faster.

754
00:42:45,670 --> 00:42:50,460
As the bits are coming in
faster, this bit time is the

755
00:42:50,460 --> 00:42:54,550
separation between the taps
and this digital model.

756
00:42:54,550 --> 00:42:56,890
So that as you make the
bandwidth bigger, you

757
00:42:56,890 --> 00:42:58,520
automatically get
more diversity.

758
00:42:58,520 --> 00:43:01,600
You get more taps in this
discrete model.

759
00:43:01,600 --> 00:43:04,110
Looking at it another way, you
have a certain frequency

760
00:43:04,110 --> 00:43:05,750
coherence in the channel.

761
00:43:05,750 --> 00:43:09,100
If you're sending a broad
bandwidth, you get lots of

762
00:43:09,100 --> 00:43:10,800
different frequencies.

763
00:43:10,800 --> 00:43:13,220
If you get lots of different
frequencies, there's a good

764
00:43:13,220 --> 00:43:16,540
chance that one of
them is good.

765
00:43:16,540 --> 00:43:20,370
OK, so we are going to get some
gain in diversity there.

766
00:43:20,370 --> 00:43:23,360
Typically we're going to get a
relatively large amount of

767
00:43:23,360 --> 00:43:26,610
energy if the thing works.

768
00:43:29,940 --> 00:43:33,550
Well, now we come to a question
that we've been

769
00:43:33,550 --> 00:43:37,140
carefully avoiding all term.

770
00:43:37,140 --> 00:43:45,310
It's sort of the question of,
if you make codewords

771
00:43:45,310 --> 00:43:49,690
orthogonal or if you make
codewords have nice structure

772
00:43:49,690 --> 00:43:53,430
at the input to a channel and
the channel has some strange

773
00:43:53,430 --> 00:43:58,930
behavior, what's going to be
the output of the channel?

774
00:43:58,930 --> 00:44:01,130
What we're doing here is
making our codewords

775
00:44:01,130 --> 00:44:04,840
orthogonal at the input of the
channel, we can't guarantee

776
00:44:04,840 --> 00:44:07,800
that they're still orthogonal
at the output.

777
00:44:07,800 --> 00:44:11,610
What we do know is that PN
sequences are almost

778
00:44:11,610 --> 00:44:13,770
orthogonal anyway.

779
00:44:13,770 --> 00:44:17,490
If you put PN sequence through
anything, they still look like

780
00:44:17,490 --> 00:44:19,170
PN sequences.

781
00:44:19,170 --> 00:44:22,880
In other words, if you think
of a PN sequence as an IID

782
00:44:22,880 --> 00:44:26,870
binary sequence, and you have
a very long IID binary

783
00:44:26,870 --> 00:44:31,360
sequence, and you corrupt it
in any way you want to, it

784
00:44:31,360 --> 00:44:35,420
still looks like an IID
binary sequence.

785
00:44:35,420 --> 00:44:38,620
So, the point is, if you can
make these orthogonal

786
00:44:38,620 --> 00:44:42,850
codewords look more like PN
sequences, you can make them

787
00:44:42,850 --> 00:44:46,070
behave better at the output of
the channel as well as the

788
00:44:46,070 --> 00:44:47,580
input to the channel.

789
00:44:47,580 --> 00:44:52,600
So you'll get something that
looks orthogonal whether the

790
00:44:52,600 --> 00:44:55,590
channel essentially looks like
a one tap channel or a

791
00:44:55,590 --> 00:44:58,520
multiple tap channel.

792
00:44:58,520 --> 00:45:01,770
OK, we also have bandwidth to
burn because we're only up to

793
00:45:01,770 --> 00:45:06,290
307 kilohertz.

794
00:45:06,290 --> 00:45:11,830
What they decided to do was to
take a PN sequence and run it

795
00:45:11,830 --> 00:45:15,020
at four times the speed
of this bit sequence.

796
00:45:15,020 --> 00:45:19,860
So we have bits coming in at
307,000 bits per second.

797
00:45:19,860 --> 00:45:23,770
We're going to have a PN
sequence which is changing

798
00:45:23,770 --> 00:45:28,190
four times for each bit time.

799
00:45:28,190 --> 00:45:31,180
So suddenly we're increasing the
speed of this whole system

800
00:45:31,180 --> 00:45:33,590
by a factor of four.

801
00:45:33,590 --> 00:45:38,950
For every one bit, we multiply
it by a sequence of four bits.

802
00:45:38,950 --> 00:45:43,780
So instead of getting a change
every one over 307,000

803
00:45:43,780 --> 00:45:51,310
seconds, you now get a change
every one over 1.2288

804
00:45:51,310 --> 00:45:53,390
millionths of a second.

805
00:45:53,390 --> 00:45:56,080
So, suddenly you're up to a
sequence which is right at the

806
00:45:56,080 --> 00:45:57,510
bandwidth you want.

807
00:45:57,510 --> 00:46:01,740
I mean we want it to get
up to 1.25 megahertz.

808
00:46:01,740 --> 00:46:06,210
Suddenly, we're up so close to
that it's going to be a real

809
00:46:06,210 --> 00:46:12,610
challenge to build a filter,
which will really make the

810
00:46:12,610 --> 00:46:20,390
output look like it's limited
to this 1.25 megahertz.

811
00:46:20,390 --> 00:46:24,020
So we need very tight
filters here.

812
00:46:24,020 --> 00:46:26,660
If you multiply this PN sequence
, you're using the

813
00:46:26,660 --> 00:46:31,040
same PN sequence on all of
the orthogonal codewords.

814
00:46:31,040 --> 00:46:34,420
If you think just a little bit
about it, if these orthogonal

815
00:46:34,420 --> 00:46:35,480
codewords --

816
00:46:35,480 --> 00:46:40,170
I'm I mean think of them still
as binary sequences --

817
00:46:40,170 --> 00:46:43,420
if each of them differ from each
other when in half the

818
00:46:43,420 --> 00:46:48,260
places, when you multiply both
of them by this PN sequence,

819
00:46:48,260 --> 00:46:50,280
they're still gonna differ
in half the places.

820
00:46:52,950 --> 00:46:54,930
You still got the
same affect out.

821
00:46:54,930 --> 00:46:57,920
They're still perfectly
orthogonal before going

822
00:46:57,920 --> 00:47:00,740
through a channel but now you
have a good chance that

823
00:47:00,740 --> 00:47:03,830
they're pretty close to
orthogonal after going through

824
00:47:03,830 --> 00:47:06,880
the channel.

825
00:47:06,880 --> 00:47:10,700
So, suddenly, we've got
it up to the bandwidth

826
00:47:10,700 --> 00:47:13,420
we want to be at.

827
00:47:13,420 --> 00:47:17,740
There's another reason
for the PN sequence.

828
00:47:17,740 --> 00:47:20,480
I mean, so far we've been
thinking in terms of, how do

829
00:47:20,480 --> 00:47:23,780
you build a cell phone
and a base station so

830
00:47:23,780 --> 00:47:25,710
they will work together?

831
00:47:25,710 --> 00:47:28,820
Actually, you want to build a
base station and thousands of

832
00:47:28,820 --> 00:47:31,400
cell phones so they'll
work together.

833
00:47:31,400 --> 00:47:34,660
So you want some way of making
different cell phones look

834
00:47:34,660 --> 00:47:37,620
different from each other.

835
00:47:37,620 --> 00:47:41,740
What they use this PN sequence
for is to make different cell

836
00:47:41,740 --> 00:47:44,750
phones look different.

837
00:47:44,750 --> 00:47:49,290
Each cell phone is going to
start out on this PN sequence

838
00:47:49,290 --> 00:47:50,440
at a different point.

839
00:47:50,440 --> 00:47:57,630
The PN sequence is going to be
generated by a 42 bit feedback

840
00:47:57,630 --> 00:47:58,900
shift register.

841
00:47:58,900 --> 00:48:01,500
If you don't know what a
feedback shift register is,

842
00:48:01,500 --> 00:48:02,470
don't worry about it.

843
00:48:02,470 --> 00:48:04,420
Most of you probably do.

844
00:48:04,420 --> 00:48:09,840
A 42 bit feedback shift
register, with the right kind

845
00:48:09,840 --> 00:48:14,050
of settings in it, is going to
generate a periodic sequence

846
00:48:14,050 --> 00:48:18,080
with a period of two to the
forty second minus one, which

847
00:48:18,080 --> 00:48:21,310
is about four times
10 to the twelfth.

848
00:48:21,310 --> 00:48:23,190
It doesn't repeat very often.

849
00:48:23,190 --> 00:48:26,890
I mean, this really
looks like an IID

850
00:48:26,890 --> 00:48:29,780
sequence and binary digits.

851
00:48:29,780 --> 00:48:34,740
It really goes through every non
zero 42 bit combination in

852
00:48:34,740 --> 00:48:35,930
this period here.

853
00:48:35,930 --> 00:48:38,310
It has very nice properties
to it.

854
00:48:38,310 --> 00:48:43,410
But the property we want for
this system is that in fact,

855
00:48:43,410 --> 00:48:47,400
when you give a cell phone a
particular setting in that

856
00:48:47,400 --> 00:48:54,110
shift register, it starts it off
generating a PN sequence

857
00:48:54,110 --> 00:48:57,350
which looks totally different
from that generated by any

858
00:48:57,350 --> 00:48:58,840
other cell phone.

859
00:48:58,840 --> 00:49:00,920
That's the only thing that makes
these different cell

860
00:49:00,920 --> 00:49:02,270
phones different.

861
00:49:02,270 --> 00:49:05,820
It's enough to make each one
of them look orthogonal to

862
00:49:05,820 --> 00:49:09,120
each of the others.

863
00:49:09,120 --> 00:49:13,830
OK, their basements sequences
and thus passband wave forms

864
00:49:13,830 --> 00:49:16,080
are now going to be essentially
orthogonal to

865
00:49:16,080 --> 00:49:17,350
those of other cell phones.

866
00:49:17,350 --> 00:49:22,420
In other words, at this point,
we're sort of going into

867
00:49:22,420 --> 00:49:23,840
fantasy world.

868
00:49:23,840 --> 00:49:27,400
I mean, we started out
generating 64 wave forms which

869
00:49:27,400 --> 00:49:30,110
were strictly orthogonal
to each other.

870
00:49:30,110 --> 00:49:32,690
Then we said we want these
wave forms to still be

871
00:49:32,690 --> 00:49:37,130
orthogonal after we go through
this unknown channel.

872
00:49:37,130 --> 00:49:39,920
We said, well we can do
this by making them

873
00:49:39,920 --> 00:49:42,890
look like PN sequences.

874
00:49:42,890 --> 00:49:46,410
But the other thing that PN
sequences do, is it all of the

875
00:49:46,410 --> 00:49:53,430
possible wave forms for one
cellphone will look orthogonal

876
00:49:53,430 --> 00:49:57,690
to the wave forms for all of
the other cell phones.

877
00:49:57,690 --> 00:50:01,760
So that in fact, what's
happening is, if you look at a

878
00:50:01,760 --> 00:50:04,640
base station, and the base
station is trying to receive

879
00:50:04,640 --> 00:50:09,260
information from each cell
phone, what it receives from

880
00:50:09,260 --> 00:50:12,710
one cell phone is going to be
essentially independent of

881
00:50:12,710 --> 00:50:17,140
what it receives from
the next cell phone.

882
00:50:17,140 --> 00:50:21,920
Now if we think of the base
station as trying to receive

883
00:50:21,920 --> 00:50:25,520
what's coming from one cell
phone, what's the interference

884
00:50:25,520 --> 00:50:29,280
from the other cell phone
going to look like?

885
00:50:29,280 --> 00:50:33,000
We're going to take thousands
and thousands of sequences,

886
00:50:33,000 --> 00:50:37,880
which are now turned into wave
forms, which look like IID

887
00:50:37,880 --> 00:50:42,210
wave forms, IID binary wave
forms, and now we're adding

888
00:50:42,210 --> 00:50:45,540
together a large
number of them.

889
00:50:45,540 --> 00:50:48,500
They fill up the whole
spectrum uniformly.

890
00:50:48,500 --> 00:50:50,240
So they have a spectral
density --

891
00:50:50,240 --> 00:50:53,000
I mean it's a random process
-- and it has a spectral

892
00:50:53,000 --> 00:50:55,230
density which is flat over this

893
00:50:55,230 --> 00:50:58,170
bandwidth of 1.25 megahertz.

894
00:50:58,170 --> 00:51:01,030
And you've added a lot of them
together, so it looks like

895
00:51:01,030 --> 00:51:02,780
white noise.

896
00:51:02,780 --> 00:51:08,180
So the effect of these other
cell phones is just like a

897
00:51:08,180 --> 00:51:12,860
small addition of white noise
as far as trying to detect

898
00:51:12,860 --> 00:51:15,360
what's going on at
one cell phone.

899
00:51:15,360 --> 00:51:19,370
Now, in fact you could be very
clever here because, as soon

900
00:51:19,370 --> 00:51:23,990
as a base station decodes one
cell phone, it can say, I know

901
00:51:23,990 --> 00:51:26,890
what that wave form was,
subtracts it off from the

902
00:51:26,890 --> 00:51:31,750
received wave form, and uses
that to help in decoding other

903
00:51:31,750 --> 00:51:32,950
wave forms.

904
00:51:32,950 --> 00:51:34,820
These standards do not
do anything as

905
00:51:34,820 --> 00:51:37,700
sophisticated as that.

906
00:51:37,700 --> 00:51:39,730
Lots of papers talk
about doing it.

907
00:51:39,730 --> 00:51:42,280
Information theorists
love this idea.

908
00:51:46,720 --> 00:51:51,970
I think it's one of these ideas
that sooner or later, ah

909
00:51:51,970 --> 00:51:53,340
going to become practical.

910
00:51:53,340 --> 00:51:55,120
As soon as it becomes
practical,

911
00:51:55,120 --> 00:51:56,720
everyone will use it.

912
00:51:56,720 --> 00:51:58,780
What does it take to
become practical?

913
00:51:58,780 --> 00:52:04,560
For someone to use it, because
we all know it'll work.

914
00:52:04,560 --> 00:52:07,030
It's just a matter of
actually doing it.

915
00:52:07,030 --> 00:52:10,750
But anyway, it's not done now.

916
00:52:10,750 --> 00:52:13,900
All of these interferes are just
going to look like white

917
00:52:13,900 --> 00:52:16,710
noise as far as this
one cellphone

918
00:52:16,710 --> 00:52:18,710
detection is concerned.

919
00:52:18,710 --> 00:52:25,780
Now, if we compare this IS95
system with all of the narrow

920
00:52:25,780 --> 00:52:29,410
band systems that people use, at
this point you can find the

921
00:52:29,410 --> 00:52:32,840
main difference between these
different systems.

922
00:52:32,840 --> 00:52:38,750
When you use a narrow band
system, things are a ranged so

923
00:52:38,750 --> 00:52:43,990
that only one cell phone is
talking to one base station on

924
00:52:43,990 --> 00:52:46,390
one of these narrow bands
of frequency.

925
00:52:46,390 --> 00:52:49,890
Namely the channels are very
narrow but because they're

926
00:52:49,890 --> 00:52:56,690
narrow if you have two cell
phones which are using that

927
00:52:56,690 --> 00:53:00,000
same bandwidth, they're just
going to interfere with each

928
00:53:00,000 --> 00:53:00,980
other totally.

929
00:53:00,980 --> 00:53:03,000
You won't get through.

930
00:53:03,000 --> 00:53:07,290
So each cell phone which is
using one base station has to

931
00:53:07,290 --> 00:53:12,130
be using a different
narrow bandwidth.

932
00:53:12,130 --> 00:53:16,530
Cell phones using different
adjoining base stations are

933
00:53:16,530 --> 00:53:21,390
also going to have to
use different bands.

934
00:53:21,390 --> 00:53:26,900
In fact, that's a terribly
complicated problem just

935
00:53:26,900 --> 00:53:30,160
because these base stations
are put in sort of, random

936
00:53:30,160 --> 00:53:34,410
locations and trying to program
things in such a way

937
00:53:34,410 --> 00:53:37,080
that you don't have two cell
phones which are using

938
00:53:37,080 --> 00:53:41,440
adjacent base stations using
the same frequency.

939
00:53:41,440 --> 00:53:42,690
It's a real nightmare.

940
00:53:45,470 --> 00:53:47,910
So, you're going to have cell
phones using the same base

941
00:53:47,910 --> 00:53:51,210
station, which are a little
bit separated, but still

942
00:53:51,210 --> 00:53:55,030
because of all sorts of
channeling effects and strange

943
00:53:55,030 --> 00:53:59,530
electromagnetic effects, base
stations still receive data

944
00:53:59,530 --> 00:54:03,030
from these far away
cell phones.

945
00:54:03,030 --> 00:54:05,960
They're also trying to receive
data from the cell phone

946
00:54:05,960 --> 00:54:07,670
that's using that frequency.

947
00:54:07,670 --> 00:54:10,060
So you got a lot of interference
in these narrow

948
00:54:10,060 --> 00:54:19,130
band systems; you got a lot of
interference from cell phones

949
00:54:19,130 --> 00:54:21,630
using different base stations.

950
00:54:21,630 --> 00:54:25,570
In the IS95 system, you get more
interference from cell

951
00:54:25,570 --> 00:54:28,680
phones that are using this
particular base station

952
00:54:28,680 --> 00:54:31,900
because they're all using
the same bandwidth.

953
00:54:31,900 --> 00:54:34,530
They all just look like white
noise to each other.

954
00:54:34,530 --> 00:54:36,410
So they do interfere with
each other, they

955
00:54:36,410 --> 00:54:38,390
raise the noise level.

956
00:54:38,390 --> 00:54:40,580
When you look at the
interference with cell phones

957
00:54:40,580 --> 00:54:44,870
using other base stations, it's
not catastrophic like it

958
00:54:44,870 --> 00:54:49,060
is with these narrow
band systems.

959
00:54:49,060 --> 00:54:53,700
So what you effectively wind
up with is that in the IS95

960
00:54:53,700 --> 00:54:57,610
system, you have more
interference within a base

961
00:54:57,610 --> 00:55:01,340
station but less interference
between base stations.

962
00:55:01,340 --> 00:55:04,700
In the narrow band systems you
have no interference within a

963
00:55:04,700 --> 00:55:08,170
base station but considerable
interference

964
00:55:08,170 --> 00:55:09,840
between base stations.

965
00:55:09,840 --> 00:55:11,080
Which is better?

966
00:55:11,080 --> 00:55:12,630
Nobody really knows.

967
00:55:15,470 --> 00:55:18,980
Well except for the fact that
almost all new systems are

968
00:55:18,980 --> 00:55:21,000
planning to use CDMA.

969
00:55:21,000 --> 00:55:27,200
It seems that most people have
sort of agreed that you get

970
00:55:27,200 --> 00:55:30,850
less noise, overall, if
you're using if you're

971
00:55:30,850 --> 00:55:32,740
using a CDMA system.

972
00:55:42,010 --> 00:55:45,450
So that let's us sort of
summarize where we are with

973
00:55:45,450 --> 00:55:47,330
all of this.

974
00:55:47,330 --> 00:55:52,340
We started out with 28.8
kilobits per second.

975
00:55:52,340 --> 00:55:58,060
We then going into this Walsh
function, orthogonal wave form

976
00:55:58,060 --> 00:56:01,860
and coder, which comes
out with 307.2

977
00:56:01,860 --> 00:56:03,480
kilobits per second.

978
00:56:03,480 --> 00:56:09,650
We then multiplied by this long
PN sequence, 42 bits long

979
00:56:09,650 --> 00:56:13,560
with four bits coming in here
for each bit coming in here.

980
00:56:13,560 --> 00:56:17,690
Now we're implementing this and
anybody with any sense who

981
00:56:17,690 --> 00:56:23,110
was trying to implement PN
sequences with multipliers

982
00:56:23,110 --> 00:56:30,440
would just say, I don't want
to turn things into to PAM

983
00:56:30,440 --> 00:56:31,450
sequences yet.

984
00:56:31,450 --> 00:56:34,240
I want to keep them binary
and add them mod 2

985
00:56:34,240 --> 00:56:35,360
because that's easier.

986
00:56:35,360 --> 00:56:38,900
So all of this is still
mod 2 binary digits.

987
00:56:38,900 --> 00:56:40,950
This is mod 2 binary digits.

988
00:56:40,950 --> 00:56:43,490
This is mod 2 binary digits.

989
00:56:43,490 --> 00:56:47,470
The only thing we haven't talked
about yet is now they

990
00:56:47,470 --> 00:56:50,960
throw in two other
PN sequences.

991
00:56:50,960 --> 00:56:56,040
One on the real part of what's
going on here and one on the

992
00:56:56,040 --> 00:56:56,960
quadrature part.

993
00:56:56,960 --> 00:56:59,520
The thing they're doing is
taking this one sequence,

994
00:56:59,520 --> 00:57:03,780
splitting it into two parts;
adding a PN sequence here,

995
00:57:03,780 --> 00:57:08,820
adding a PN sequence here,
then doing the 2PAM, then

996
00:57:08,820 --> 00:57:12,550
filtering and sending this
stuff out on the cosign

997
00:57:12,550 --> 00:57:16,120
channel and the stuff out
on the sign channel.

998
00:57:16,120 --> 00:57:20,810
I've never had a very good sense
of why you need these

999
00:57:20,810 --> 00:57:22,900
two PN sequences here.

1000
00:57:22,900 --> 00:57:27,270
I can like sort of explain it
to you in the following way.

1001
00:57:27,270 --> 00:57:30,850
If you didn't have PN sequences
here, what you'd be

1002
00:57:30,850 --> 00:57:36,440
doing here is simply sending
this same sequence twice.

1003
00:57:36,440 --> 00:57:38,970
So you be sending it on the
cosign channel, you'd be

1004
00:57:38,970 --> 00:57:41,470
sending it on the sign channel,
which would sort of

1005
00:57:41,470 --> 00:57:44,560
be equivalent to sending
it at 45 degrees.

1006
00:57:47,190 --> 00:57:49,730
Once you realize that, you say
well, I might as well leave

1007
00:57:49,730 --> 00:57:53,100
this whole thing out and just
use the cosign channel and

1008
00:57:53,100 --> 00:57:55,890
nothing else.

1009
00:57:55,890 --> 00:57:58,580
If I'm just using the cosign
channel and nothing else it

1010
00:57:58,580 --> 00:58:02,120
won't make much difference
because the cosign just refers

1011
00:58:02,120 --> 00:58:05,470
to the phase at this
transmitter.

1012
00:58:05,470 --> 00:58:09,090
I'm talking about many cell
phones whose transmitters are

1013
00:58:09,090 --> 00:58:12,530
all at different places relative
to a base station.

1014
00:58:12,530 --> 00:58:15,090
Therefore, they're all going to
be using different phases

1015
00:58:15,090 --> 00:58:19,090
so they're all going to fill
up the signal space.

1016
00:58:19,090 --> 00:58:24,280
The thing that, that doesn't
take into account is the fact

1017
00:58:24,280 --> 00:58:26,730
that if we do that we're not
using all the degrees of

1018
00:58:26,730 --> 00:58:28,350
freedom available to us.

1019
00:58:28,350 --> 00:58:31,470
We're still just using the
number of degrees of freedom

1020
00:58:31,470 --> 00:58:34,470
that we got here, which are
real degrees of freedom.

1021
00:58:34,470 --> 00:58:37,320
When we do this and this,
we got twice as

1022
00:58:37,320 --> 00:58:40,210
many degrees of freedom.

1023
00:58:40,210 --> 00:58:42,690
The PN sequences that we're
looking at, which are the

1024
00:58:42,690 --> 00:58:46,160
things that are orthogonal
to each other.

1025
00:58:46,160 --> 00:58:50,820
We have twice as many bits in
a give interval of time when

1026
00:58:50,820 --> 00:58:57,350
we have these two PN sequences
as we do when we only use this

1027
00:58:57,350 --> 00:58:59,160
one PN sequence.

1028
00:58:59,160 --> 00:59:04,340
So in fact, if we view PN as
IID binary digits, you get

1029
00:59:04,340 --> 00:59:09,300
twice as many binary digits this
way as you got before.

1030
00:59:09,300 --> 00:59:14,290
Therefore, everything
works better.

1031
00:59:14,290 --> 00:59:17,570
You come much closer to being
orthogonal with higher

1032
00:59:17,570 --> 00:59:20,490
probabilities.

1033
00:59:20,490 --> 00:59:22,030
If you didn't understand
that's fine.

1034
00:59:22,030 --> 00:59:24,500
It's not explained in
the notes either.

1035
00:59:24,500 --> 00:59:29,350
It's not explained in
the IS95 standard.

1036
00:59:29,350 --> 00:59:32,610
I think the explanation is
right but it needs some

1037
00:59:32,610 --> 00:59:33,860
fleshing out.

1038
00:59:36,970 --> 00:59:40,350
OK, here's another interesting
feature

1039
00:59:40,350 --> 00:59:41,890
about this rake receiver.

1040
00:59:44,650 --> 00:59:49,920
It doesn't use this digital
model of the channel that

1041
00:59:49,920 --> 00:59:51,740
we've talked about.

1042
00:59:51,740 --> 00:59:55,550
It in fact, uses the analogue
base band model.

1043
00:59:55,550 --> 00:59:59,090
In other words, the base band
model of the channel is the

1044
00:59:59,090 --> 01:00:04,200
channel is represented
by an analog filter.

1045
01:00:04,200 --> 01:00:12,200
The analogue filter has impulses
or almost impulses at

1046
01:00:12,200 --> 01:00:13,450
different delays.

1047
01:00:15,310 --> 01:00:20,000
Now what you'd like to do in
this rake receiver here is

1048
01:00:20,000 --> 01:00:23,850
instead of having taps at these
sample times for the

1049
01:00:23,850 --> 01:00:28,110
given bandwidth, they're going
to adjust the taps so the taps

1050
01:00:28,110 --> 01:00:33,600
are right on top of these things
that look like impulses

1051
01:00:33,600 --> 01:00:36,590
in all of these path returns.

1052
01:00:36,590 --> 01:00:40,290
So the question is, what's the
difference between these two

1053
01:00:40,290 --> 01:00:42,240
strategies?

1054
01:00:42,240 --> 01:00:44,660
I mean, we sort of show that
the digital model was

1055
01:00:44,660 --> 01:00:49,470
completely equivalent
to the analog model.

1056
01:00:49,470 --> 01:00:56,590
Then I cheated you; I didn't
realize I cheated you until

1057
01:00:56,590 --> 01:00:58,650
about nine o'clock
this morning.

1058
01:00:58,650 --> 01:01:04,340
I cheated you in the following
way: I told you that if you

1059
01:01:04,340 --> 01:01:07,580
model the channel in terms of
the discrete set of taps

1060
01:01:07,580 --> 01:01:11,600
according to the sampling
therom, this was completely

1061
01:01:11,600 --> 01:01:17,600
equivalent to trying to model it
-- as far as a band limited

1062
01:01:17,600 --> 01:01:21,710
input was concerned -- in terms
of an analog filter.

1063
01:01:21,710 --> 01:01:26,130
That's absolutely right if you
use an infinite number of taps

1064
01:01:26,130 --> 01:01:28,260
for the channel.

1065
01:01:28,260 --> 01:01:30,990
If you now say that the impulse
response of the

1066
01:01:30,990 --> 01:01:36,730
channel is about one tap long
and then you say, how many

1067
01:01:36,730 --> 01:01:40,050
tabs do I need to
represent it?

1068
01:01:40,050 --> 01:01:43,460
It's an interesting question
because if the impulse

1069
01:01:43,460 --> 01:01:48,810
response is one tap long and you
filter to look like a sign

1070
01:01:48,810 --> 01:01:57,910
x over x, the impulse response
can look like this.

1071
01:02:03,120 --> 01:02:08,530
So you have one tap here, one
tap here, which is zero, one

1072
01:02:08,530 --> 01:02:11,840
tap here, one tap here,
which is zero.

1073
01:02:11,840 --> 01:02:15,320
If you've gotten your spacing
off by half a cycle, what do

1074
01:02:15,320 --> 01:02:17,020
you have then?

1075
01:02:17,020 --> 01:02:20,140
You have a tap here.

1076
01:02:20,140 --> 01:02:21,870
You have a tap here.

1077
01:02:21,870 --> 01:02:23,740
You have a tap here.

1078
01:02:23,740 --> 01:02:28,770
You have these taps which are
going down as one over time.

1079
01:02:28,770 --> 01:02:32,470
So in fact, modeling this
kind of thing with one

1080
01:02:32,470 --> 01:02:35,170
tap would be terrible.

1081
01:02:35,170 --> 01:02:38,800
Now when you use the analog
filter and you actually put

1082
01:02:38,800 --> 01:02:43,040
these taps of the rake receiver
at the places where

1083
01:02:43,040 --> 01:02:49,230
you have actual physical
responses you do much better.

1084
01:02:49,230 --> 01:02:53,160
You particularly do better if
the impulse response duration

1085
01:02:53,160 --> 01:03:00,650
of the channel is the same order
of magnitude as 1 over

1086
01:03:00,650 --> 01:03:04,090
the bandwidth of the source
that you're using.

1087
01:03:04,090 --> 01:03:06,950
At that point this becomes
an important issue.

1088
01:03:06,950 --> 01:03:11,170
That's exactly the situation
we have here because of the

1089
01:03:11,170 --> 01:03:14,590
impulse response of
these channels.

1090
01:03:25,520 --> 01:03:32,500
The sample time on this discrete
model it's about

1091
01:03:32,500 --> 01:03:34,980
eight-tenths of a microsecond.

1092
01:03:34,980 --> 01:03:37,840
If you think of how far light
can travel in eight-tenths of

1093
01:03:37,840 --> 01:03:44,430
a microsecond, it's about the
same as the multipath spreads

1094
01:03:44,430 --> 01:03:48,930
you would find outdoors
when you're in a

1095
01:03:48,930 --> 01:03:50,530
relatively rural area.

1096
01:03:50,530 --> 01:03:53,680
If you're in a city area,
multipath spreads are going to

1097
01:03:53,680 --> 01:03:55,240
be even smaller.

1098
01:03:55,240 --> 01:03:58,980
So if you want to a rake
receiver to work well you

1099
01:03:58,980 --> 01:04:01,840
should really have a rake
receiver which is trying to

1100
01:04:01,840 --> 01:04:05,940
zero in on the actual physical
response times.

1101
01:04:05,940 --> 01:04:09,150
This is what this system does.

1102
01:04:09,150 --> 01:04:10,750
They did it right and
I did it wrong.

1103
01:04:17,380 --> 01:04:19,590
OK, final thing.

1104
01:04:19,590 --> 01:04:24,350
I told you I wanted to talk
about why we did scrambling.

1105
01:04:24,350 --> 01:04:30,910
This rake decoder, in other
words, this decision device,

1106
01:04:30,910 --> 01:04:35,910
which every six bits tries to
make a decision on these 64

1107
01:04:35,910 --> 01:04:40,250
different orthogonal
wave forms.

1108
01:04:40,250 --> 01:04:43,330
You can just make hard decisions
which gives you six

1109
01:04:43,330 --> 01:04:45,610
bits out each time.

1110
01:04:45,610 --> 01:04:49,280
You can produce six bits out
also with some likelihood

1111
01:04:49,280 --> 01:04:51,700
about how likely they
are to be right.

1112
01:04:51,700 --> 01:04:54,530
So what you'd like is some
information which is

1113
01:04:54,530 --> 01:04:57,430
essentially the logarithm of
the probability of being

1114
01:04:57,430 --> 01:04:59,780
correct over the probability
of error.

1115
01:04:59,780 --> 01:05:04,080
You can estimate that in
your rake receiver.

1116
01:05:04,080 --> 01:05:06,900
You can estimate it by knowing
whether you're making a close

1117
01:05:06,900 --> 01:05:12,030
call or whether there's one
orthogonal wave form which is

1118
01:05:12,030 --> 01:05:15,090
far more likely than
all of the others.

1119
01:05:15,090 --> 01:05:19,790
So if you're making a close
call, then you produce an

1120
01:05:19,790 --> 01:05:22,770
output that says, I think
it's this output but

1121
01:05:22,770 --> 01:05:25,410
I'm not very sure.

1122
01:05:25,410 --> 01:05:29,290
This is what goes into
this viterbi decoder.

1123
01:05:29,290 --> 01:05:34,720
The viterbi decoder, since it's
operating on these states

1124
01:05:34,720 --> 01:05:37,380
-- in other words, it's
operating on what it

1125
01:05:37,380 --> 01:05:42,130
visualizes is being the state
of the viterbi decoder --

1126
01:05:42,130 --> 01:05:45,580
it can actually deal with these
log likelihood ratios as

1127
01:05:45,580 --> 01:05:47,970
well as anything else.

1128
01:05:47,970 --> 01:05:50,920
That's one of the reasons you
want to use a viterbi decoder

1129
01:05:50,920 --> 01:05:55,410
because most coding devices
that people have invented

1130
01:05:55,410 --> 01:05:58,000
don't work very well with
analog signals.

1131
01:05:58,000 --> 01:06:00,930
This does work well with
analog signals.

1132
01:06:00,930 --> 01:06:06,780
The problem is, anytime you
make a mistake on the 64

1133
01:06:06,780 --> 01:06:11,620
orthogonal wave forms, you
have a six bit batch of

1134
01:06:11,620 --> 01:06:16,030
digits, a six bit block, and
you're going to be wrong,

1135
01:06:16,030 --> 01:06:17,280
typically in three of them.

1136
01:06:20,640 --> 01:06:26,220
well, you're going to be wrong
in a random number of them.

1137
01:06:26,220 --> 01:06:27,660
Half the time you're
going to be wrong.

1138
01:06:33,570 --> 01:06:38,930
What this means is if you put
this data into a decoder, what

1139
01:06:38,930 --> 01:06:42,090
you're going to find is that
every time there's an error in

1140
01:06:42,090 --> 01:06:46,470
the in the rake receiver, you're
going to have a burst

1141
01:06:46,470 --> 01:06:51,450
of errors, some random bunch
of errors over six bits.

1142
01:06:51,450 --> 01:06:54,110
This is typically going to be in
the order of three bits an

1143
01:06:54,110 --> 01:06:56,200
error all at once.

1144
01:06:56,200 --> 01:06:59,340
If you look at the structure of
that decoder, anytime you

1145
01:06:59,340 --> 01:07:03,580
got a large number of errors in
all at once, it's going to

1146
01:07:03,580 --> 01:07:07,210
screw the thing up terribly.

1147
01:07:07,210 --> 01:07:10,440
I'll give you one
example of that.

1148
01:07:10,440 --> 01:07:13,300
You can take a much simpler
coding example.

1149
01:07:13,300 --> 01:07:17,520
Suppose you transmit either
all zeros, seven zeros or

1150
01:07:17,520 --> 01:07:20,200
seven ones.

1151
01:07:20,200 --> 01:07:23,570
At the receiver there's a
certain probability that you

1152
01:07:23,570 --> 01:07:27,970
make an error on each
one of these bits.

1153
01:07:27,970 --> 01:07:31,380
You first make a decision on
each bit and then after that

1154
01:07:31,380 --> 01:07:33,390
you make a decision on
the whole code word.

1155
01:07:37,040 --> 01:07:40,250
If the bit errors are
independent of each other,

1156
01:07:40,250 --> 01:07:43,470
then you make an error in the
overall detection of these

1157
01:07:43,470 --> 01:07:48,800
code words only when you make
four errors out of seven.

1158
01:07:48,800 --> 01:07:52,400
Or five errors out of seven
which is negligible.

1159
01:07:52,400 --> 01:07:55,030
So you calculate, what's the
probability of making four

1160
01:07:55,030 --> 01:07:57,420
errors out of seven here?

1161
01:07:57,420 --> 01:07:59,670
Well it's the number of
combinations of seven things

1162
01:07:59,670 --> 01:08:04,650
taken three at a time which is
35 times p fourth, p to the

1163
01:08:04,650 --> 01:08:06,400
fourth power which is
the probability

1164
01:08:06,400 --> 01:08:09,770
of making four errors.

1165
01:08:09,770 --> 01:08:13,520
If those bits are perfectly
correlated mainly, if whenever

1166
01:08:13,520 --> 01:08:17,460
you make one bit error you make
all seven bit errors,

1167
01:08:17,460 --> 01:08:22,100
then the probability of error is
p If p is relatively small,

1168
01:08:22,100 --> 01:08:27,720
p is always a lot bigger than
35 times p to the fourth.

1169
01:08:27,720 --> 01:08:31,330
In other words, the lesson here
is that highly dependent

1170
01:08:31,330 --> 01:08:37,070
errors cause trouble for
any kind of decoder.

1171
01:08:40,060 --> 01:08:42,680
Now you see why you had the
scrambler in here, why you

1172
01:08:42,680 --> 01:08:43,920
have the interleaver.

1173
01:08:43,920 --> 01:08:47,530
You Have the interleaver to take
these highly correlated

1174
01:08:47,530 --> 01:08:52,090
errors which are coming out of
the rake receiver where you

1175
01:08:52,090 --> 01:08:56,160
make blocks of six errors all
tend to appear together.

1176
01:08:56,160 --> 01:09:01,060
You're scrambling them out so
they're widely separated so

1177
01:09:01,060 --> 01:09:06,800
that the viterbi decoder is
able to deal with them.

1178
01:09:06,800 --> 01:09:10,390
That's the last piece
of the whole thing.

1179
01:09:10,390 --> 01:09:13,000
I could talk a little bit about
how the viterbi decoder

1180
01:09:13,000 --> 01:09:17,630
works but I think you're
probably exhausted by now.

1181
01:09:17,630 --> 01:09:20,430
I think I will stop
at this point.

1182
01:09:20,430 --> 01:09:23,070
Than you all for your attention
all term and good

1183
01:09:23,070 --> 01:09:24,680
luck on the final.