51学通信技术论坛

标题: 如果让我来设计一台SGSN（抛砖引玉贴） [打印本页]

作者: 爱卫生 时间: 2011-2-15 20:58:17 标题: 如果让我来设计一台SGSN（抛砖引玉贴）

本帖最后由爱卫生于 2011-2-16 11:04 编辑

如题，如果我是一名研发人员？我应该怎样来设计一台SGSN呢？应该遵循怎样的原则呢？
以下都是个人观点，仅供茶资闲聊。都是自己瞎想的，很不完善，请大家多拍砖啊！
首先，最基本的要求是可用性。也就是3GPP规范里的各个接口功能一定要能够满足，或者如果再偷一点懒，拿到中国移动的技术应标书，来个点对点应答，至少标书里提到的强制要求满足的一定要能够满足才行，可选的都可以以后再慢慢开发。
  然后，应该是低碳，环保。这就需要在硬件的设计工艺上多下苦功。尽量保证设备的功耗最小即耗电量最低，尺寸最小也就可以保证占用的机柜面积越小，那这个机柜就可以放更多的设备。以一台SGSN 4000W的功耗计算，工业用电1元1度，那一年就是1*4*24*365差不多4万多元的电费。如果有10台，100台那就不是一笔小数目了。所以降低功耗不只是为了低碳环保，更可以为运营商节省不小的成本。（当然，有一些软件技术也可以做到这一点，比如SGSN POOL等）。
  第三点应该是稳定性吧。这就包括硬件软件。大概谁也不希望三天两头对设备打补丁升级或修改bug吧。
  第四点应该是性能。这取决于产品的定位，如果这台SGSN定位是高端产品，那和竞争对手的同档次产品比起来应该至少有性能上某方面的亮点。运营商都比较讲究ARPU值也就是每用户的每月贡献值。在购买设备的时候，同样也看中产品的ARPU值。比如花了1元钱，那是不是能附着10个用户呢？另一个厂家是11个？然后就看口碑和服务了。其实和大家买家电等产品是一个道理。
  第五点是可扩展性。要保证板卡的向下兼容以及软件版本的平滑演进。不能说升级硬件就要把老的硬件全淘汰了。需要保护用户的投资。
  第六点是易用性和好用性。这是指用户对产品的易上手程度和产品是否提供大量丰富的指令或工具来帮助用户来完成日常维护、故障排除等一系列操作。这一点其实是很重要，但说实话，因为在选购设备的时候会听取运维部门的意见，但最终买单的并不是运维部门，真正买单的最关心的还是设备稳不稳定，会不会出问题，至于操作维护不是他的职责。还是稳定压倒一切。所以这一点可以放到第六位。但如果你的易用性、好用性要比其他厂家好，那在设备选型的时候就是锦上添花了。

作者: 爱卫生 时间: 2011-2-15 21:57:58

本帖最后由爱卫生于 2011-2-15 21:58 编辑

先来说说关于硬件架构的设计。
个人认为（想到哪说到哪，可能没有逻辑性），硬件设计上先抛开性能不谈，至少可以从以下几个方面去考虑。
（一）模块化的设计。将所有SGSN涉及到的接口做成模块化的，除了一些必选接口如Gn/Gb/Gr/Iu等作为基本配置外，其余一些可选或国内没有的接口如Gs/Ge/LI接口做成可选的模块。如果以后哪天要上的话，只需要增加相应的模块就可以了。这样模块化以后，生产成本会更低，也更利于开拓更多的市场。也更受运营商的欢迎。
（二）分层设计。这是最基本的。将用户平面和控制平面的处理板卡分开，物理上分开。当然如果一块板子既能处理控制信令，又能处理用户的payload，那自然也是受欢迎的。但就是要保证在设计上要区分用户和控制平面。这也是保证一个可扩展性。
（三）采用一个稳定的操作系统来实现各个组件之间的资源调度。当然还要考虑性价比。例如Linux是免费的。
（四）需要有良好的自愈能力。比如针对某个进程，某个错误的配置，某个失效的链路，能够尽可能的提供自愈功能。当然，断电自然是没有办法了。
可选的，觉得它还应该内置F5交换机那种负荷分担的功能。可以根据不同的条件来实现自动或者可经人工干预的硬件负荷分担。例如，假设第一个机框是最新的3代硬件板，第二个机框是性能稍差的2代硬件板。那SGSN应能支持自动的或者人工的根据多种条件，如用户的APN、地址范围、IMSI号段、QOS分类等等来将这些用户的控制或payload信息转发给第一个机框的3代硬件板或第二个机框的2代硬件板。

作者: xiner 时间: 2011-8-9 11:10:33 标题: 想到在SGSN上一个关于RAU的功能

本帖最后由 xiner 于 2011-8-9 11:11 编辑

回复爱卫生的帖子

关于SGSN，我有一个小的功能想实现

现网中，new SGSN收到终端的RAU请求消息后，会对消息中的old-RAI数据进行解析，得到终端的old SGSN的IP，从而发送SGSN context request消息与old SGSN进行信令交互。而RAI与SGSN对应关系，一般是在DNS上定义的，也就是进行网络割接后（如BSC从SGSN1割接到了SGSN2），必须同时在DNS上进行数据修改，这个数据的修改是手动操作的，容易出现不及时、不准确等问题，从而因此导致RAU失败。

我有两个想法：
1：升级SGSN和DNS，使SGSN能将所辖RAI数据提交给DNS。DNS自动定义或修改RAI解析数据。

2：升级SGSN，实现SGSN定期自动查询RAI对应SGSN的IP，并进行DNS解析，比对两者数据，如果不一致，SGSN则发出相应的告警，方便及时发现故障，及时处理此类路由更新失败故障。

作者: 爱卫生 时间: 2011-8-14 20:18:09

xiner 发表于 2011-8-9 11:10
回复爱卫生的帖子

关于SGSN，我有一个小的功能想实现

好主意。确实是一个比较现实的现网问题。谢谢分享。
但个人感觉要实现起来还是比较困难的。因为这涉及到对DNS协议的改造。但DNS协议本身的扩展性不强，因为它不是基于TLV（类型长度编码）的。所以不像其他那些支持TLV编码的协议例如IS-IS、Diameter等等，可以要实现一个新的功能，就制定一个新的类型，赋一个值就可以了。但这个DNS就不行。需要对协议本身进行整体改造，比较困难。

作者: xiner 时间: 2011-8-25 10:24:41

爱卫生发表于 2011-8-14 20:18
好主意。确实是一个比较现实的现网问题。谢谢分享。
但个人感觉要实现起来还是比较困难的。因为这涉 ...

嗯，第2个功能比较容易实现，仅需要SGSN对自身RAI数据与DNS解析数据比对，如不符合则产生相应的告警，使得维护人员能够及时的发现问题，人工修改DNS上的RAI解析数据

作者: arrowbroken 时间: 2011-10-14 12:48:03

回复 xiner 的帖子

非常赞同楼上的说法。好像F5的3DNS/GTM就有功能检查它服务的网元的LOAD状况，然后根据网元的LOAD来回应DNS QUERY的网元的IP地址。这样来做全网的负载均衡，同理SGSN也可以主动做DNS查询，然后人工通知OMC来处理，个人觉得不能自动更新，毕竟有些东西还是需要人来做决定的。

作者: haibin606 时间: 2012-1-15 11:44:50

讨论的真好，学习学习！

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)