51学通信技术论坛

 找回密码
 立即注册
搜索
楼主: 爱卫生
打印 上一主题 下一主题

从高丽国给唐朝的密函看MS到SGSN的信令协议栈(未完待续)     [复制链接]

Rank: 2Rank: 2

30#
发表于 2012-3-23 15:05:06 |只看该作者
模拜,学习了

使用道具 举报

Rank: 2Rank: 2

29#
发表于 2012-3-23 11:21:47 |只看该作者
楼主好有才啊!牛郎都很牛逼了!再来唐朝,我佩服

使用道具 举报

Rank: 3Rank: 3Rank: 3

28#
发表于 2012-3-19 16:48:48 |只看该作者
犀利啊群主

使用道具 举报

Rank: 9Rank: 9

懒

27#
发表于 2012-2-28 22:40:31 |只看该作者
回复 justme_zjw 的帖子

建议在8版块无线版块单独再开一贴。否则可能论坛的一些高手看不到你的问题,就无法帮你解答了。

在GPRS的空中接口中传输的完整数据流如下图所示。 网络层的协议数据单元(N-PDU)在SNDCP层进行分段后传给LLC;LLC添加帧头和帧校验序列后形成LLC帧; LLC帧在RLC/MAC再进行分段后, 封装成RLC块; RLC块经过卷积编码和打孔后形成456比特的无线数据块; 无线数据块再分解为4个突发后, 在4个时隙中传输。

不同的编码方式,从CS-1到CS-4,能够承载的有效信息字段不一样,CS-4的效率最高。从CS-1 - CS-4,能够承载的数据比特分别是181、268、312、428(不含USF)。

编码过程以CS-3为例:

315个信息比特(含3个USF比特),首先添加16个用于检错的分组校验序列(BCS)比特,然后对3个比特的USF预编码形成6个比特,之后添加4个尾比特,生成338个比特。随后将338个比特进行1/2卷积编码,得到676个比特。最后对这676个比特截短220个比特,形成456个比特的输出。

附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

26#
发表于 2012-2-28 15:22:57 |只看该作者
回复 爱卫生 的帖子

爱总,小弟刚刚接触GPRS,有一事想请教:
RLC/MAC层根据无线链路的传输能力将1527个字节(LLC帧的最大长度)按CScoding scheme)切成不同的小块,是不是就要进行CS1-4或者MCS1-9的信道编码了?那么它的下一层物理层的一般是4个TDMA帧共456比特的信息,会不会对CS1-4或者MCS1-9有所限制?

使用道具 举报

Rank: 1

25#
发表于 2012-2-13 11:16:18 |只看该作者
挺不错,这故事编起来也不容易呀

使用道具 举报

Rank: 2Rank: 2

24#
发表于 2012-2-7 16:28:58 |只看该作者
来晚了!膜拜!!!!

使用道具 举报

Rank: 3Rank: 3Rank: 3

23#
发表于 2012-2-6 16:37:21 |只看该作者
太牛了    爱死你了  爱总   

使用道具 举报

Rank: 2Rank: 2

22#
发表于 2011-10-31 13:49:22 |只看该作者
生动形象,牛人

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

21#
发表于 2011-10-14 23:39:27 |只看该作者
爱总,分析的很不错,呵呵!
身体是革命的本钱!

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

20#
发表于 2011-9-6 09:27:33 |只看该作者
我也来顶一个

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

19#
发表于 2011-9-1 09:41:18 |只看该作者
果然很生猛啊

使用道具 举报

Rank: 3Rank: 3Rank: 3

18#
发表于 2011-9-1 06:59:01 |只看该作者
楼主,你这太猛了,呵呵

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

17#
发表于 2011-7-26 16:48:46 |只看该作者
绝对精典,嘿嘿,有大师的风范

使用道具 举报

Rank: 2Rank: 2

16#
发表于 2011-7-3 23:16:01 |只看该作者
膜拜!!!!

使用道具 举报

Rank: 9Rank: 9

懒

15#
发表于 2011-6-26 19:50:18 |只看该作者

LLC的功能(和故事中国防部的职责的映射)

    根据TS44.064 LLC协议的规范,对LLC层的要求如下,以下还列出了LLC层功能需求和故事中国防部的功能之间的对应关系:
1 LLC应能提供在MS和SGSN之间的一条高度可靠的逻辑链路
    - 相当于高丽国防部和唐朝兵部之间的联络通道
2 LLC层应和下层使用何种空中接口协议无关
    - 相当于高丽交通部使用鸽子、鹰、马来传递货物,国防部并不关心。
3 LLC应能提供可变长的信息帧
    - 相当于在传递货物时,国防部能按照不同的规格来传递。如50公斤一箱装的黄金还是10公斤一箱来装。这个军用运输箱由国防部来提供。交通部只负责传。
4 LLC层应能提供确认和非确认模式的传输
    - 相当于高丽国防部在唐朝兵部收到货后要求进行确认,或不确认。(例如一些价值不高的货物。)

5 LLC层应允许在SGSN和一个或多个MS之间能复用相同的物理链路资源(空中接口)
    - 相当于高丽国防部在要求交通部送货时,除了携带密函外,还可以顺便携带高丽其他部门给唐朝的其他物件。例如高丽国外交部给唐朝礼部送了礼物,也可以由交通部的同一匹马/鸽子/鹰来传递。
6 LLC层能保证到同一个MS的高优先级数据比低优先级数据能得到更高的Qos待遇
    - 相当于国防部要求交通部在运送货物时,对价值贵的物品如国画、夜明珠之类的用绿色通道及最好的资源例如战马、官道来传送。但价值稍低的物品如白银则用普通的资源例如普通马、民用道来传送一样。
7 LLC应能提供对用户数据、信令的加密,以及提供对用户身份标识的加密
    - 相当于高丽国防部对信函的加密、黄金的伪装,以及对高丽国王身份的加密。

www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 9Rank: 9

懒

14#
发表于 2011-6-26 18:17:22 |只看该作者

国防部的职责(对应LLC协议)

  看完了控制平面和唐朝故事的对应关系。我们就一级一级来看在这个故事中各个职能部门的具体职责。
  按照从上往下的顺序,首先是高丽国王写好密函,外交部整理。这些属于上层的应用消息。或者在后来的高丽国进贡黄金的过程,黄金也是上层的东西。只不过是用户平面的Payload。相当于是MS访问外部PDN网络的IP报文。
  这些应用部分如果暂时不看的话,首先我们就需要了解一下国防部的功能。在上面的映射过程中,我们看到国防部的职责是负责将信函加密变成密函以防止被盗取,或者在运输黄金的时候,对黄金进行伪装成牛粪,防止被抢劫。当然如何解密这个规则对方唐朝的兵部是明白的。能够在收到密函后将密函的真实内容还原出来。只不过如何加密解密的这个协商过程是双方事先早就约定好的,并不在传送密函的过程中进行协商。
  但实际上,国防部的职责除了对高层交代下来的东西(信函或黄金)进行加密外,还需要做很多事情。
(一)国防部要为高层提供服务,即国王/外交部交代的任务需要完成。
(二)国防部对下可以要求交通部来完成实际的传送任务。并且需要对交通部的货物传递状态及行为进行监管。因为,一旦出了什么问题。国王是只会找国防部的麻烦,而不一定直接去找交通部的麻烦,甚至交通部的罪责更轻一些。
(三)国防部需要和对方对等的接收者即唐朝兵部进行一些关于货物传递的协商。例如黄金装箱的规格等等。确定了则可以更方便实际的传送。
  基于以上原因,国防部还需要完成以下职责和功能:
1 打上标记,能识别出运送的对象是密函还是黄金或其他物品。
2 使用军方通用的语言和对等功能实体唐朝兵部建立直接对话和通信。
3 和唐朝兵部进行确认运送的对象(密函或黄金)是否收到。
4 如果有货物丢失,要通知高层外交部或国王调配物资进行重发。
5 如果运送的是黄金等货物,要对其进行编号,并按顺序发送。
6 如果运送的是黄金等货物,需要和唐朝兵部协商每箱黄金的规格是多少,以方便在双方的道路上传递。
7 上述都没问题,则国防部通知交通部负责货物的传递。
8 国防部要对交通部的货物发送进行监管,保证无差错,平滑的传送到唐朝兵部。不能太快,也不能太慢。太慢会让唐朝产生误会高丽没有诚意而开战,太快容易丢失货物。

   大致上的国防部的职责用下图来表示:

图七 国防部的职责(LLC协议)

附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

13#
发表于 2011-6-24 14:35:37 |只看该作者
学习了,好好好好

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-6-30 23:30 , Processed in 0.054672 second(s), 9 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部