在GPRS模塊上網的過程中，主要是經過PPP協議中的三種協議，分別爲LCP（Link Control Protocol）協議，PAP（Pass-word Authentication Protocol）認證協議以及IPCP（Internet Protocol Control Protocol）協議LCP部分主要協商下一步的密碼認證協議，可選擇PAP方式或CHAP方式，我們根據ISP要求選擇PAP方式。PAP部分主要是向ISP發送密碼進行認證。密碼認證通過以後進入IPCP，完成客戶端請求IP及ISP端分發IP的過程。其實現過程圖如圖2所示
在認證過程中，MCU、GPRS模塊及ISP都需要發送PPP格式的數據包來完成協商過程該數據包爲16進制，多數情況下其對應ASCII碼並無實際意義PPP數據幀的結構如表1所示。
對於表1所示的協議部分有如下凡種形式的描述:
對於表1所示的信息位包括了鏈路配置包標誌，描述如下：
以上3個表所示的內容是分析PPP協議各種類型數據包的基本概念。在解析PPP數據包中需要注意的另外一個事項是，如果字符中包括了Ox7D，則表示該字符後面的字符需要轉義。轉義方式是後一個字符與0x20進行異或運算得出的16進制數據作爲真是數據比如一個數據包包括了......Ox7D0x23......，則真實表示的爲Ox03a（爲方便表示下文所示數據均爲轉義後的數據）
2．實際協商過程分析
（1）LCP協商過程
首先設置模塊的初始化參數及工作參數向模塊發送如下AT指令：
1）AT CGCLASS="B"置爲“B”模式
2）AT CGDCONT=1，"IP";"CMNET"設置APN
3）AT CGATT=1，使GPRS模塊附着在網絡上
然後發送指令"ATD*99***1#"建立撥號過程，模塊會返回16進制的一些數據。我們要據此與模塊進行協商。首先返回數據包（16進制）:7EFF03CO2101010016010405DC020600000000070208020304CO2326B47E
數據包含義:7E（PPP包頭）FF03CO21（LCP協議）01（代碼）01（標識符）0016（長度）01（類型）04（長度）05DC（協商內容Maximum-Receive-Unit）02（類型）06（長度）00000000（協商內容）07C類型協議壓縮協商）02（長度）08（類型，地址控制域壓縮協商）02C長度）03〔類型）04（長度）CO23（內容表示請求PAP認證）26B4（FCS，校驗和）7E（PPP包尾）。
此模塊在進行LCP協商階段是比較友好的，主動提出了PAP認證方式，可直接返回對它請求的同意也可以提出些新的申請，實際操作中發送同意請求爲：7EFF03CO2102010016010405DC020600000000070208020304CO23DO477E。
至此LCP認證階段已經結束
（2）PAP認證過程
因爲協商同意PAP密碼認證方式故進入PAP過程，需要發送用戶名和密碼至ISP.請求格式爲7ECO230101000600003B3F7E
該包在0006後的0000分別代表用戶名和密碼，都爲空此時由於需要與ISP進行認證，需要等一段時間經過判斷，服務器通過密碼認證，返回：7ECO237D227D217D207D2D7D2857656C636F6D65214EBC7E
其中的16進制字符"57656C636F6D6521"轉爲ASCII碼爲"Welcome!".同時服務器發送IPCP請求數據包：7E8021010100OA0306COA86F6FCID497E
進入IPCP協商過程
（3）IPCP協商過程
客戶端部分此時需要請求ISP分發IP請求爲：7E802101060016030600000000810600000000830600000000OACF7E
"0306""8106""8306"後的四個00分別代表客戶端IP，第一DNS主機地址，第二DNS主機地址，這3個部分全部爲00表示內容爲空，是請求ISP分發IP到客戶端。
服務器得到請求後分發IP數據包爲：7E8021030600160306OA4A0C148106D38812AB8306D3887D34CB.6B6B7E
OA4AOC14表示爲十進制的10.74，12.20，由於中國移動通信規定GPRS撥號上網的用戶分發的IP均爲內部IP，非外部IP，所以IP都是以10.＊＊＊開頭的。8106後面的D38812AB表示211.136.18171，是第一DNS主機的IP地址。8306後面的D38814CB表示211.136.20.203，是第二DNS主機的IP地址此後我們需要對分發下的幾個IP辨認識別，然後再次請求請求中包含這3個分發IP，代表接受分發結果。數據包爲7E8021010700160306OA4A4C838106038812ABe3o6D38e14CBF2C17E
此後清求得到ISP認可，鏈路層PPP握手過程全部結束進入網絡階段。此後所有發往GGSN網紹的包含IP的數據包都會透明的傳給所對應的IP地址。以上既是對PPP協商過程的分析，只要注意上面所提及的每步的注意事項及含義，即可迅速快捷的建立數據鏈路層.
三、網絡層及傳輸層的實現
網絡層和傳輸層雖然屬於IP及UDP協議實現的功能但此兩者都是建立在數據鏈路層基礎上的，因此在發送PDP/IP包的時候仍然不能擺脫對PPP協議的依賴。由PPP封裝的UDP/IP數據包組成如下表所示：
1．IP協議介紹
IP包的組成形式如表5所示，其中8位協議處可選擇TCP方式或UDP方式，8位TTL爲TimeToLive，只數據包在網絡中的存活時間。
2．UDP協議介紹
相對於舊數據包UDP數據包的組成比較簡草，主要包含所要發送的數據信息即數據段。結構如表6所示其中最後的UDP校驗與IP數據包中的IP校驗方式一樣，但與PPP協議中的FSC校驗方式不同。FSC校驗屬於CRC16位校驗方式的一種而舊校驗和UDP校驗是相對簡單的反碼求和的校驗機制。並且對於IP及UDP校驗而言需要將數據包需要校驗部分的16位轉換爲32位進行校驗校驗好之後再轉換爲16位.
3．IP及UDP校驗和
IP校驗和所要校驗的數據段包括了前面所提的IP數據包內的所有位段，而UDP校驗相對IP校驗複雜的地方在於，UDP校驗不僅僅要將UDP數據包內的內容包括進來，而且還要包括IP部分的一些信息UDP校驗位組成如下：
對於最後一位的數據段而言由於校驗是32位所以如果數據段出現奇數個數據，需要加零補位。
校驗程序如下所示：
HdelineUSHORT
unsignedshortUSHOPTchecksum(USHORT*buller，Intsize)
{
unsignedIongcksum=0;
while(size＞1)
{
cksum =*buffer ；
size-=sizeof(USHORT);
}
if(size)
cksum =*(UCHAR*)buller;
cksum＝(cksum>>16) (cksum＆oxnff);
cksum =(cksum>>16)return(USHORT)(Ccksum);
}
4．由PPP封裝形式封裝的UDP/IP數據包
根據前面所介紹的方法，下面給出一個具體的實例進行分析：7E2145.00001D47F300DOBID11BOF60A4A30EDD350336C03E803F20000551B61A5DE7E
7E21爲PPP包頭，4表示舊版本號5表示首部長度，00表示服務類型，001D表示包的All長度47F3表示16位的標識，00表示3位的標誌 13位的片偏移，80表示TTL，11表示協議（11表示UDP協議，TCP爲06），B0F6是IP首部校驗和。接下來的"0A4A30E0"表示本地IP地址即剛纔通過PPP協議獲得的動態IP而"D350336C"表示對方IP，即要發送的目的IP，"03E8"表示本地端口（這個可以隨便設定只要不與系統已用端口衝突即可，對於UDP而言這個沒有實際意義因爲GPRS分配到的是內部IP，即使對方知道你的IP及端口也可能通過UDP方式傳輸數據，而如果是TCP協議則用GPRS作爲Client清求Server建立通道後Server端可根據端口發送數據）"03F2"表示目的端口"0009"，表示UDP包的長度（本地端口2字節＋目的端口2字節＋數據長度2字節＋數據端n字節十UDP校驗2字節），“55”表示數據，轉換爲ASCII碼應爲"a"，"1B61"爲UDP校驗和"A5DE"爲PPP包的FSC校驗和。此段代碼的含義是“向IP爲211.80.51.108，端口爲1010的目的地發送字符a".