~~ Tales Of Kalstein ~~

뭐 ctypes 매뉴얼에 잘 나와있긴한데...
왠만한 winapi들은 python win32 expansion에 들어있다. 그런데 가끔은 없는것도 있단말이지.
그럴경우는 kernel32.dll에 있는 함수를 직접 호출해줘야한다.
하는 방법은 매우 간단하다.
(FindFirstVolume이라는 winapi 호출을 한다고 가정한다)

from ctypes import *
winapifunc = windll.kernel32.FindFirstVolumeA

그리고는 winapifunc 함수호출. 끝.
-ㅁ-;; 좀 허전하지? ㅎㅎ 여기서 반드시 주의할점. 대부분의 windows api들은 A,W로 끝나는 ANSI, Unicode 버젼이 따로 존재한다. 즉, 실제 함수명과 MSDN에 나오는 함수명은 다른것. 실제 함수명을 보고싶다...면 DLL export 가 어떻게 되어있는지 살펴보면 좋다.

http://www.nirsoft.net/utils/dll_export_viewer.html

여기 가보면 해당 유틸리티를 다운받을수 있다. 이건 꼭 kernel32.dll뿐만 아니라 다른 dll들에도 적용되므로 (다른점이라면 LoadLibrary 호출이 한줄 더 들어가는정도?) 참고하자~~~

문서로 남겨뒀다가 복사해둔다.

1 Apache 설치 (2.2.3)
    yum install httpd
2 python 확인 (2.4.3)
    yum install python
3 setuptools 설치 (EasyInstall)
    python ./ez_setup.py
4 Genshi 설치
    easy_install Genshi (잘 되지않을경우 -U 옵션 붙여서 실행)
5 python-sqlite 설치 (1.1.7)
    yum install python-sqlite
6 subversion Binary 설치
    Summer 에서 패키지한 1.5.1버젼 rpm들을 받아서 설치
(
    or
    -이 방식으로는 mod_dav_svn이 컴파일되지않는다-
    subversion 소스설치 (apache와 연동시키지않는다 - 세팅할게 많으므로)
        # 소스 다운로드 (1.4.6) - dep도 같이 다운로드.
        # cd subversion-1.4.6/neon
        # ./configure --enable-shared
        # ./make
        # ./make install
        # ./cd ..
        # ./configure
        # ./make
        # ./make install
        # ./make swig-py
        # ./make install-swig-py
        # subversion 소스 디렉토리에서 make swig-py && make install-swig-py로 Python 바인딩을 설치하고,
        다음 명령으로 python 경로에 등록해준다.
        $ echo [subversion설치경로]/lib/svn-python >
            [python 설치경로]/lib/python2.x/site-packages/subversion.pth
        - thanks to http://pragprog.tistory.com/tag/Subversion
)
7 mod_python 설치
    1 yum install mod_python
8 Install Trac
    1 홈페이지에서 Trac을 다운로드 (0.11.1)
    2 압축풀기
    3 python ./setup.py install
9 trac 디렉토리 초기화 후 tracd 를 실행해서 trac자체는 제대로 동작하는지 확인한다.


기본설정은 끝. 실제 환경을 만들어 보자 (apache+trac 연동)

1 mod_python이 동작하는지 확인
    1 /etc/httpd/conf/httpd.conf에
        <Location /mpinfo>
           SetHandler mod_python
           PythonInterpreter main_interpreter
           PythonHandler mod_python.testhandler
        </Location>
      추가 후 웹페이지 확인. (http://trac/mpinfo)
    2 추가한 부분 삭제.
2 .htpasswd 생성
    1  htpasswd 명령어로 사용자 생성 및 추가
3 httpd.conf 추가
    <Location /trac>
            SetHandler mod_python
            PythonInterpreter main_interpreter
            PythonHandler trac.web.modpython_frontend
            PythonOption TracEnvParentDir /data/trac
            PythonOption TracUriRoot /trac
            PythonOption PYTHON_EGG_CACHE /tmp
    </Location>   
    <LocationMatch "/trac/[^/]+/login">
            AuthType Basic
            AuthName "Type your ID, Password"
            AuthUserFile /data/trac/.htpasswd
            Require valid-user
    </LocationMatch>




=====================================================================
                    프로젝트 생성하기
=====================================================================
1 root로 접속
2 trac-admin [프로젝트 trac path] initenv
3 각종 파라미터 입력
4 svnadmin create [프로젝트 svn path]
5 폴더 권한변경 => [/]# chown -R apache.apache [프로젝트 trac path]
6 폴더 권한변경 => [/]# chown -R apache.apache [프로젝트 svn path]

요즘 python을 개인적으로 관심있게 보고있는데...한가지 의문이 생겼더랜다.

'스크립트 언어지만, 실제 .py 코드가 동작하는것은 이미 쓰여진 코드. 그러면 runtime에 코드를 동적으로 생성해서 실행하는것이 가능할까?'

자세히는 보지않아서 정확한 구현을 어떻게 하는지는 기억이 나지는 않지만, C/C++쪽에서도 실시간으로 op code를 만들 수 있다. 비단 C/C++뿐만 아니라 .NET 환경하에서도 가능하다. (예전 windows들도 상당히 즐겨썼다고 한다. asm을 만들어서 끼워넣는 방법. Beautiful code 라는 책에서 살펴볼 수 있다)
그렇다면 python은??

일단 함수,클래스 들의 호출은 kldp에 문의해서 알아봤다 ㅎㅎ (링크)

__dict__ 를 사용하면 될꺼같은데요.
만약 인터프레터에서 나가고 싶으면 exit() 을 처도 되지만,
__buitlins__.__dict__["exit"]() 을 처도 나가집니다. ㅎㅎ.
다른 예로...

>>> class Foo:

...     def bar(self):

...             print "Hello, world"

...

>>> a = Foo()

>>> a.bar()

Hello, world

>>> Foo.__dict__

{'__module__': '__main__', 'bar': , '__doc__': None}

>>> Foo.bar(a)

Hello, world

>>> Foo.__dict__['bar'](a)

Hello, world

>>>

이 코드에선 a.bar(), Foo.bar(a), 와 Foo.__dict__['bar'](a) 가 다 같은 뜻을 가집니다 ㅎㅎ. 만약 문자열을 가지고 함수를 부르고 싶으면 __dict__['문자열'] 을 해버리면 되겟군요.

오호라...역시 되는구나.
그렇다면 조금 다른 활용을 살펴보도록 하자. 보통 OOP에서의 동적 함수 호출이라고 하면 C++로 표현해서 다음과 같은걸 의미한다.

class Base
{    virtual void foo() = 0; };

class Derived_1
{    virtual void foo() { 어쩌구; } };

class Derived_2
{    virtual void foo() { 저쩌구; } };

그리고는 실제 호출시에는 Base의 포인터만을 이용해서 호출하는 방식. 이방식의 문제점이라면...Factory Pattern을 쓴다고 했을때, type별로 매칭되는 뭔가를 따로 만들어줘야 한다는거지. id라고나 할까? id가 1이면 Derived_1을 생성해주고, 2이면 Derived_2를 생성해주고.

자 예제 코드 --->>
Base * FactoryMethod(int class_id)
{
    if (1 == id)
        return new Derived_1();
    else if (2 == id)
        return new Derived_2();
    else
        return NULL;
}

요런식으로 된다. 그런데...그냥 따로 id 받지않고 클래스 명을 받을수도 있지않을까? 또 코드로 말하자면 --->>
Base * FactoryMethod(const string class_name)
{    return new class_name(); }

이렇게 말이다. 좀 어이없을수도...;; C/C++에선 쉽지않을꺼다. (가능할까? 흠...잘 모르겠네...;;) 그런데 python은 저게 된다 -_-;;;; 컴파일을 인터프리터로 할 수 있기때문에 가능하다. 아래의 코드.

-------------------------------------------------------------
import codeop

class T1:
    def Eval(self, val):
        print val

class T2:
    def Eval(self, val):
        print 2 * val

tmpcodeobj = codeop.compile_command('obj = T1()')
eval(tmpcodeobj)
obj.Eval(10)
-------------------------------------------------------------

위의 코드에서 'obj=T2()' 이렇게 문자열을 바꾸면 T2:Eval() 이 호출된다. ^^;
스크립트 언어의 위대함이랄까...;;;

Memory allcation에 대해서 공부하다가 요청하는 숫자에 적합한 2의배수 값을 찾아주는게 필요해서 한번 간단히 짜봤다.

// 처음 1이 나오는 MSB 위치를 리턴 : 0-31
unsigned int SearchMSB(unsigned int n)
{
    unsigned int i;
    for (i=0; i<32; i++) {
        if (0x80000000 == (n & 0x80000000))
            break;
        n <<= 1;       
    }
    return i;
}

unsigned int FindFitSize(unsigned int n)
{
    unsigned int msb = SearchMSB(n);
    unsigned int tmp = SearchMSB((1 << (31-msb)) - 1 + n);
    return 1 << (31-tmp);
}

int _tmain(int argc, _TCHAR* argv[])
{
    while(1)
    {
        int n;
        printf("input number : ");
        scanf("%d",&n);
        printf("fit size : %u\n\n", FindFitSize(n));
    }
    return 0;
}

여기서 SearchMSB의 경우는 거의 모든 CPU에서 한사이클짜리 단일 asm으로 제공되어진다. (linux의 O(1) 스케쥴링 알고리즘이 그걸 이용함. - 물론 코드 분석한건 아니고 주워들은 얘기 ㅎㅎㅎ - TI DSP에도 _lmbd 라는 명령어로 존재한다.)

FindFitSize의 결과는 64를 넣으면 딱 맞으니까 64를 리턴하고,  65를 넣으면 128을 리턴하는 것. 또 나중에 생각하기 귀찮아서 생각난김에 플밍하고 기록해둠~ ^^;;

이쪽 세계도 심오하구나...하고 절실히 느끼는중 ^^;;
크누스 형님이 제창하신 buddy-system (2의 배수로만 메모리 할당해주는것 - 33바이트를 요구하면 64바이트를 65KB를 요구하면 128KB를... 구현이 쉽다는게 장점) 에서 요즘은 slab allocator로 넘어가는게 대세인것 같다.

이런 링크도 참고해보고 -> http://monac.egloos.com/1246303
slab allocator 관련된 논문들도 보고있는데....어려웠던 부분은,
좀 더 하위레벨 얘기가 나오면 GG상황이었던것. 예를들어, 하드웨어 캐쉬 미스를 줄이기 위해 이런걸 썼다 라고 하는데...'웅?? 이뭥뮈?;;' 이러고 있으니 ㅋㅋㅋ SDR interleaving 얘기도 나오고... 그래도 이리저리 찾아보니 슬슬 알아가는 재미가 있다 ㅎㅎㅎ

다 알게되면 좀 정리 해야할듯...

요즘 책을 보는데 언어가 JAVA로 되어있다. 그래서 몇가지 단어들이 익숙치 않은데...
그중에서 좀 애매한 부분이 'implements' 와 'extends'. extends를 구현상속이라고 되어있더라.
C++에선 상속이...그냥 pulic상속이냐, private 상속이냐...이정도만 있어서 뭐가 있나보다...하고 넘어갔다가 오늘 찾아보니 java에서는 좀 상속을 엄격하게 다루는듯.

implements를 C++로 하자면

struct IConnection
{
    virtual void connect() = 0;
};

class TCPConnection : public IConnection
{
public:
    virtual void connect()
    {
        어쩌구저쩌구...
    }
private:
    어쩌구저쩌구...
};

요런식으로 interface만 정의된 (pure virtual function들만 있는...) class를(혹은 구조체를) 상속받아서 구현하는것을 의미한다.

그 외의 것은 다 extends로 보면 된다.

WCDMA physical layer에서 보면 TFC, TFI, TFCI 등등...뭐가 많이 나온다. 전반적인 설명과 함께 TFC에 대하여 글을 남겨둔다.

WCDMA for UMTS 책에 보면 간략히 TFI, TFCI의 관계에 대해 나와있다.
TFI는 Transport Format Indicator, TFCI는 Transport Format Combination Indicator의 줄임말이다.

Higher layer에서는 모든 블럭이 Transport Block으로 관리된다. (Transport 채널이기도 하고.) 요 TB들은 어떤 특정한 포맷을 가지게 되는데 이를 TF, Transport Format이라고 한다. 이는 상위에서 설정값으로 내려온다. 이게 종류가 여러개란 말이지. 그런데 physical 전송할때마다 일일히 '이 포맷은 몇바이트짜리다.' 라고 쓰면 bit를 많이 쓰게 되니까 그냥 그걸 index식으로 표현하는게 (0은 A비트, 1은 B비트 뭐 이런식) TFI 인것.

TrCH은 (Transport Channel) 동시에 여러개가 열려있을 수 도 있다. 그러면 당연히 TFI도 여러개. 하지만 실질적으로 Physical Layer의 Channel은 DPCCH, DPDCH의 2개. 그러면 여러개의 TrCH을 Multiplexing 해야되는거지. 그래서 어떤 TFI의 데이터들을 MUX했는지 알려주기 위한 것이 TFCI.

예들 들자면, TrCH이 3개가 있었다고 가정하고 각각 TFI가 0,1,0 이었다고 하자. 저런 구성의 TFI 3개를 섞었을때 TFCI가 0이라고 정해놓는거지. TFI가 0,1,1일 경우에 TFCI가 1이라고 정해놓는거고. 그럼 DPCCH에 TFCI값을 보고 '아 이거 어떤녀석들이 섞여 있는거구나. 그거에 따라서 분리(Demultiplexing)해야겠네' 라고 할 수 있는것.

해당되는 TFCI의 의미를 알려면 3GPP 34.108 의 6.10.2 절을 보면 상세히 나와있다. 저 스펙문서에서 TFS에 보면... '숫자'x'숫자' 가 있다. (ex. 0x103, 1x39, etc) 앞의 숫자는 블럭개수를 의미하고, 뒤의 숫자는 비트수를 의미한다. 간혹 보면 0x103 이런녀석들 있는데...사이즈가 있어도 블럭이 없는것이니까 0이라고 생각하면 된다. (그래서 저런 경우 옆에 'alt. 1x0' 라고 명시되어있다. 사이즈 제로란 소리)

생각을 깊게하면 좀 더 난이도를 낮출 수 있다!!

요즘 회사서 기존 소스코드를 분석하고 있는데...수백줄이 각종 for 문으로 왔다갔다 하는 부분이 있었다. 이거 뭐이리 복잡하나...싶어서 봤더니. 결국 찾아내고 싶은 값은 하나. 각종 전역변수들을 들락날락 했던 이유는? 관계된 값을 찾을 때, index값을 이용하기 때문이었다.

즉 간단히 말해서는 RDB의 모습이었다는것. 뭐 취지는 좋다. index 기반이니까 배열으로써 바로 접근이 가능하니까. 속도면에서도 그럭저럭 쓸만할테고...메모리량도 적게먹을테고. 그러나... 코드가 너무 지저분하며, 검색시에는 해당 값으로 정렬되어있지않기 때문에 무조건 for문을 이용해서 linear하게 찾을 수 밖에 없다. 게다가 테이블에는 유일한 값이 있는것이 아니라 중복값이 있을 수 있다. 즉 for 문 안에서 1번 조건을 만족 하더라도, 2번조건에 부합되지않으면 마저 돌아야되는것. 이러다보니 소스코드가 좀 너저분하고 분기문이 많아진다.

찾는 값들을 살펴보니...3비트, 2비트 길어봐야 16비트 정도의 값이다. 다 합쳐보면 32비트 미만일 듯 싶다. (찾는 값들은 key값들로 볼 수 있고, 나머지 value 값들도 존재함) 이럴 때 사용할 수 있는건 뭔가? DB에서 사용되는 BITMAP Index 를 사용할 수 있지않을까. 그러면 검색하고 싶은 조건을 한번에 32비트안에 다 집어 넣을 수 있을테고 (SQL문의 where 절이 되겠다.) 총 entry 개수만큼 iteration만 하면 100% 검색이 가능하다.

총 entry는 너무 많다고? 그럴수있다. 지금 내가 참여하고있는 프로젝트는 소형 기지국 Femto cell 쪽 SW인데 여기는 총 8명 user에다가 각 유저당 8개의 entry를 가진다. 그럼 여기선 64개의 iteration을 가지지만 64명의 user를 지원한다면? 128번의 iteration이다. 제법 많아지게 되는것이지. 그럴경우? 그럼 유저당 검색을 별개로 할 수 있도록 partitioning을 하면 되는것. 그럴경우 256명을 지원한다고 해봐야 메모리는 좀 더 잡아먹을 수 있겠지만 (그나마도 dynamic allocation을 활용하면 극도로 효율적인 운영이 가능하다.) 속도는 MAX 8번의 iteration만으로 가능해진다.

코드도 보기 좋아지고, 속도도 빨라지고...이 얼마나 좋을소냐. 제발 생각좀 하자...생각좀...

ps : 뭐 사실...생각의 부재라기보다는...Data Structure에 대해서 깊게 공부하는 사람이 없어서 더 이런 문제가 있는 것 같다. 프로그래밍의 가장 중요한 요소인데 말이지...쩝.

ps2 : 어찌보면...DB의 역정규화와 상당히 동일한 작업이다. storage는 조금 더 쓰는 방향이 될듯. (entry들의 사이즈가 작아서 큰 문제는 없다)

1. CRC 란?

CRC라는게 뭔지는 알아야겠지? 일단 비트 계산이 이용된다. 덧셈연산은 XOR(Exclusive OR)가 사용되며 곱셈연산은 AND연산과 동일하다.

영어 위키는 여기. http://en.wikipedia.org/wiki/Cyclic_redundancy_check 잘 정리 되어있다. 간추리자면, 약자 그대로 모든 비트를 검사하고 그걸 축약시켜서 n bit 길이의 code로 만들어 두면, 나중에 실제 message k bits를 보냈을 때, n bit code 검사만으로도 k bit에 Error 가 있는지 없는지 검사할 수 있다는 것. 계산 방법은 영어 위키 페이지에서 Computation of CRC 챕터에 간단히 잘 나와있다.

자 그럼 내가 이 문서를 쓰는 의의는 뭘까?

웹페이지 검색을 해보면 '그냥 이렇게 계산해~' 정도만 나와있다. CRC 원리를 그대로 sw로 구성하면 매우 비효율적이다. 한 비트씩 shift 해서 연산해야되니까. 수백KB가 되면 그거 다 shift하려면 하세월이지. 그런데 SW예제들을 보면 그냥 Table Lookup 방식을 쓴단말이지. 왜 이렇게 해도 되는지는 잘 나와있지않다. 생각해보자. 원리는 bit shifting을 통해서 해야된다고 나와있는데, 실제 구현은 table lookup. 왜 table lookup을 써도 괜찮은지에 대한 설명을 찾기가 쉽지않다. (물론 아주 어려운건 아니다. 그러니까 내가 찾았지 -_-;;) 그래서 table lookup을 쓸 수 있는 이유를 증명을 통해 보이려고 한다. 사실 증명은 문서로 이미 되어있거든. 지금 쓰는건 단지 그것을 이해하고 쉽게 '한글로' 풀어쓰려는 것일뿐. 그 이상도 그 이하도 아니다.

 

2. CRC 계산 기본

SW 구현을 이해하려면 기본적으로 CRC 계산 수식들에 익숙해져야한다. (CRC가 어떻게 Error Detection을 하고, 제대로 하는것인지에 대한 증명은 패스. 그냥 기본적인 것만 한다.)

CRC 계산을 위해 generator polynomial이 주어지게 되는데 그걸 g(x)라고들 표현한다. (위에 위키 페이지에 보면 잔뜩있는 CRC-8, CRC-16 등등에 사용되는 수식들임) 그리고 입력에 사용되는 k-bit message를 u(x), message에 CRC정보를 덧붙여서 만든 n-bit codeword를 v(x)라고 한다. 그리고, CRC로 붙는 (n-k) bit 내용을 s(x)라고 하자. 요런 관계를 수식으로 표현하면

(1)

로 표현할 수 있다. 는 를 로 나눈 후 나머지가 되는 임의의 다항식이라고 가정하면,

(2)

라고 가정이 가능하다. (도 역시 임의의 다항식) 이런 상황이 만족되는 경우, 덧셈연산이 XOR이므로 가 된다. 그러므로 v(x)는 g(x)로 나눠떨어지는 값을 가지게 된다. 즉, Error Detect측에서는 단순히 정해진 g(x)로 나눠서 나머지가 없으면 error가 없는 것이라고 판단하는 것이다.

 

참쉽죠? ^________^

 

 

…. 라고 하면 맞으려나? -_-; 사실 수학에 손땐지 오래인 나로써는 쉬워보이면서도 이해하기 어렵더라. 근데 알고보면 별 거 아니다. 솔직히 (1)방정식의 가 어디서 나온건지 궁금해 할 수 있다. (철저히 개인적이다. 뭐…내가 쓰는건데 개인적으로 쓰는거지 ㅡ,.ㅡ) 아까 젤 위에 가정을 할 때 k는 original message의 길이, n은 CRC정보가 첨부된 길이라고 했다. 즉, 항상 n>k 임을 알 수 있다. 요거는 단지 u(x)의 k승수를 v(x)의 n승수로 맞춰주기 위해 곱해주는 것 일뿐~ 뭐 이것만 알면 아래에 SW구현 파트는 이해가 가능하다.

 

이 챕터를 끝내기 전에 예제를 한번 풀어보자.

101011 이라는 bit sequence의 CRC값을 계산하자. 이 경우 이다. g(x)의 경우 CRC-16으로 하기로하면 이 된다. 계산하면

이고 여기에서 s(x)를 계산하면 Figure 3과 같이 된다.

즉, 101011을 CRC-16을 거치면 0111110100000000101011 이 된다.

 

3. SW 구현

위에서 말했다시피 HW 구현은 그냥 CRC 원리 그대로 bit 계산으로 하면 된다고 치자. (물론 더 좋은 방법으로 구현들 할꺼다…하지만 HW는 내 알바 아니니 패스) SW으로 그렇게 구현하려면 무지 비효율적인것도 이미 말했으니…바로 어떤식으로 계산하면 좋을지 수식으로 들어가자.

 

CRC generator polynominal을 g(x)로 표현하기로 하고 예제로는 CRC-16을 사용한다고 가정하자. u(x)는 message bits를, s(x)는 g(x)로 나눈 나머지를 의미한다고 가정하자. 그러면…

 

 

으로 표현이 가능하다. 그리고

        

로 가정한다. 자 이제 한 바이트, 즉 8비트가 밀려들어왔다고 가정하자. 새로운 값이 추가된 meesage를 u'(x) 라고 가정하면,

        

이다. 새로운 나머지값인 s'(x)는

        

로 표현 할 수 있다. (R은 나머지값이라는 표현임. 다른 뜻은 없으니 크게 신경쓰지말자~) 자~ 식을 전개해보면

        

 

        

b(x)와 s(x)를 전개해보면

        

, i = 0,1, … , 7 로 변환시키면

        

        

요렇게 된다. g(x)가 이것보다 큰 값이니까 나머지해봐야 그대로 남는 것이고…자, 8비트 추가된 후의 나머지(CRC)값의 방정식이 구해졌다. 살펴보도록 하자.

일단 의미는 뭘까? 은 8비트 추가가 되기 전에 기존 CRC값의 high-order 8비트값이었다. 그런데 그게 단순히 8비트 right-shift 된 것이지. (x의 승수가 높을수록 low-order bit이다. 위에서 예제로 계산했던 것을 다시 살펴보자)

이번엔 요녀석을 살펴보자. 여기서 은 단순히 새로 추가된 8비트와 기존 u(x)의 하위16비트(CRC-16이니까)에서의 low-order 8bit인 와의 합(XOR)이다. 결론은 꼭 1비트씩 할 필요없이 8비트씩 계산해도 괜찮다~라는것!!

여기서는 8비트씩 계산을 해도 된다~ 라는 결론만 가지고 다음 챕터로 넘어가보자.

 

4. Table Lookup Algorithm

위에서 이 값은 8비트이므로 총 256개의 값을 가질 수 있고, 따라서 이 값은 미리계산 되어질 수 있다. (영어로 하자면 precomputable하다…정도? 모든 경우의 수를 다 계산해 놓는것) g(x)가 CRC-16의 경우 값은 최대 16비트값을 가지게 되므로 해당 테이블의 크기는 2byte * 256 = 512byte가 되겠다. CRC-8이라면 256byte를 가질 것이다. 계산 순서는 다음과 같다.

1. CRC register를 0x0000 으로 만든다. (값이다)
2. 를 구한다. (계산)
3. CRC register를 8비트 right-shift한다.
4. 미리 계산해둔 CRC Lookup table에서 해당값을 CRC register에 XOR 연산을 한다.
5. CRC 계산할 byte-stream data가 끝날때까지 2~4 단계를 반복한다.

끝나고 나면 CRC register에 전체 byte-stream data에 대한 CRC 값이 있게된다. 끝!!

 

5. Reference

A Tutorial on CRC Computations

Ramabadran, T.V.   Gaitonde, S.S.  
lowa State Univ., Ames, IA

WCDMA Downlink Symbol Level Processing에 대해서 써보고자 한다. 주로 3GPP 25.212 spec에 따라서 쓸 꺼당…

데이터의 흐름은

1. CRC Attachment
2. TrBK concatenation / Code block segmentation
3. Channel coding
4. Rate matching
5. 1^st insertion of DTX indication
6. 1^st interleaving
7. Radio frame segmentation

상위 1-7 순서를 단위로 해서 묶어서

1. TrCH Multiplexing
2. 2^nd insertion of DTX indication
3. Physical channel segmentation
4. 2^nd interleaving
5. Physical channel mapping

의 순서대로 처리하게 된다.

 

각각의 단계에 대해 Study를 한 후 해당 내용을 정리할 생각이다. 이는 뭐 그냥 3GPP spec내용이니까 대외비인 것도 없고, 사내 blog에는 그냥 doc파일로 저장해서 올려야지… blog api가 없어서 귀찮단 말이지 ^^;;;

CRC attchment는 공부 좀 했었는데…시간 좀 지났다고 다 까먹었다 -.-;;;