OFDM - mac

1. bandwidth determines subcarrier frequency spectrum
2. the duration of the data is determined by grant time

3. all 1500 frequencies are required to represent a sequence of symbols

ie IFFT is

1500 x 1 mul 1 x 1500 matrix multiplication

64 QAM at a go can decode 1 symbol of 8bits or 1 byte, in the cartisian coordinates amplitude and angles representthe 64 points on the graphs each representing particular symbol

incoming bitstream is organized as a 8bits or 1 symbol, they are then imprinted on a frequency, converted to time domain, raised by central frequency and sent out

phy starts with broadcasting zadoff-chou preambles from common shared set, eNb uses a ra process to select the UE and assigns dedicated resource for future communication with the UE

so when contention is resolved or a dedicated zadoff-chou preamble is detected , phy becomes ready to forward the accompanying messages to FFT of eNb side

phy view
phy has two threads
one deals with RACH
other with other channels

when RACH thread is done ,it handovers to other thread
when other thread needs RACH it invokes that

OFDM - mac

each ue has 3000 subfrequencies to work with, maybe 1500 are usable for data, 1 usable for synchronization

ue will not use all of them together, for max bandwidth

it will use a subset at a time, lower bandwidth

the allocation of the specific frequency set is indicated by eNb

so at a time multiple UE's will talk with eNb under different subsets of 3000 frequencies

if an eNb is overutilised another eNb in the same area can taken over more connections than 3000

the spectrum will be shared between different eNbs in the area

each spectrum band is split into 3000

Transport Block - mac unit

the centre frequency 1500 is used for special purpose

lte - mac

1.RACH - random access channel
2.DLSCH - downlink shared channel
3.PUSCH - uplink channel
4.BCH - broadcast channel
5.PCH - paging channel
6.MCH - multicast channel

the system begins by activities on the RACH, to get initial access ie exclusive radio access
once it it done control data is sent using the accquired resource

virtual memory, physical memory and os

In windows mdl holds an association between the physical pages and virtual buffers

A scatter gather entry represents a contiguous physical memory
It can span multiple pages if the vm associated extends
mostly the first SGE will have this

in this case from the virtual address find the corresponding physical address
this physical address will be on a page boundry by default
then calculate the offset of vm by finding the nearest page rounded vm and taking the difference
apply this difference to physical address

then start calculating the pages till but the last one

find the offset of the last one

In linux the procedure is same but the skb contains SGL with SGE's

protocol implementation

basic requirements

each layer of the protocol has a control block, and a set of callback functions and call forward functions

control block to store all the protocol related variables
callback functions for the lower layer to call into this layer
call forward functions to call into the lower layer

inaddition to this sublayering can be done in each layer


effectively top layer should handle serialization, and each lower layer handles only discontinuities

queues might be required at each layers

pre allocated buffers can be allocated for data

mostly cannot do away with dynamic allocation because there will be some linked list structures

if these can be populated during initialization all is good, otherwise need to handle systemwide
discontinuity

memory barrier

In SMP cpus sync with each other using MESI protocol

suppose a drivers buffer and a variable is declared side by side in its control block

ie

struct device {

char a;
char buff[x];
};

Unfortunately if the variable and the buffer happen to share same cache line , problems can arise

see the sequence
1.Dma writes to the buffer with shared cache line
2.user thread writes to the variable with shared cacheline
3.please note that the cpu handling dma write after process and the cpu associated with thread
might be different
4.so if the dma write after processing happens first and variable write after processing happends next the original dma content will be overwritten by the variable write

wince

wince has support for 8139 and NE2000 hardware under KITL
what it means is that in addition to normal 8139 and NE2000 drivers , its initialization
code has a custom driver (which is not the other 8139,NE2000 driver) that gets initialized
at the booting time.This will get discarded later if its not used by KITL

so if we need to debug a network driver in wince we need atleast 2 n/w interfaces once being
8139 compatible for eg dlink

its too difficult with the wince to bootup with usb,but since most of the time the images are on the usb so you cannot do without it too

Need dos to format the usb to create a FAT partition with bootsector written and command.com

later the loaded wince image can be made to use another partition on the usb as its filesystem

How to see linux

1.basic linux infrastructure contains
grub,initrd,kernel,rootfs

we need grub preinstalled on the boot medium
initrd binary
kernel binary
and expanded rfs or ramdisk rfs

each of the 4 can be setup independent of each other(compare with windows .. do we have this flex)

Interestingly initrd is almost similar to rfs, so what really happening is that at one stage of
booting kernel chooses initrd as its rfs and later switches to another rfs and this can be continued further if required

so rfs and kernel highly flexible design

now another interesting thing, all the devices are also files, it gives yet another level of
powerful feature

at the time of boot up kernel loads all the drivers and is initialized ... but if the device
nodes are not present as files on the rfs devices are unusable

so simply we can create device files in the filesystem on the fly to add devices to the system


as different rfs can be mounted on any rfs recursively its possible to switch between them at will

Qemu

Qemu without the guest:
1.has a mechanism by which it will advertise the availability of 8139,NE2000 network controllers
to the guest. So when the guest boots up it will automatically pick up 8139 and NE2000 drivers
from the kernel
2.So only these two drivers can be used to create a virtual ethernet driver on top of the host network system using qemu
3.It utilises bridging utilities brutility to create a virtual network comprising of guest networks
and host network
4.there is also a mode in qemu where an application tcpip stack is used to simulate the network

5.Again similar to the n/w interface UART is also advertised by the qemu

kqemu + processor hardware support can give near equal performance for a guest os