本帖最后由 爱卫生 于 2011-6-20 22:28 编辑
SGSN Pool功能的实现,离不开BSC/RNC的节点选择功能。因为用户是首先接到BSC/RNC上,再由BSC/RNC为用户来选择Pool里的SGSN的。因此,本帖用于说明BSC/RNC上的节点选择功能。如果你想得到最权威的解释,可以去看TS23.236。但如果想得到相对也比较权威的解释,则可以从本帖提到的中国移动SGSN Pool测试规范中的“节点选择功能”测试项目来了解。
BSC/RNC上为用户选择Pool里的SGSN分为以下几种情况:
1)用户是第一次使用GPRS业务,使用IMSI进行附着。
2)用户非首次使用,以TLLI(即P-TMSI)发起附着,并在BSC/RNC上能成功找到和NRI对应的SGSN。
3)用户非首次使用,以TLLI(即P-TMSI)发起附着,但在BSC/RNC上不能成功找到和NRI对应的SGSN。
4)用户以TLLI发起附着请求,所带NRI对应的SGSN不可达的情况。
针对以上四种情况,中国移动SGSN Pool的测试规范对应制定了四个测试项目。下面的内容摘自“中国移动SGSN Pool的测试规范”的“节点选择功能”测试项目部分。
实际上关于BSC/RNC上的“节点选择功能”已经在测试规范的“测试目的”项里明确说明。
先给出测试组网图如下:
图一 测试组网图
1.1.1.用户使用IMSI发起附着请求 测试项目编号:1.1.1 | 项目属性:必选 | 测试项目:用户使用IMSI发起附着请求 | 测试目的:验证BSC能够实现NNSF功能,根据负荷均衡算法选择服务的SGSN并将消息分发到该SGSN | 测试参考:3GPP 23.236 | 测试前提条件: 1.测试环境中SGSN POOL功能打开,相关数据配置正确; 2.6个用户没有存储P-TMSI,能够以IMSI发起业务; | 测试配置:测试组网图一 | 测试流程:
1.在POOL内的所有SGSN上打开用户信令消息跟踪; 2.6个用户以IMSI发起附着请求; | 测试预期结果: 1.6个用户的附着请求成功,且消息跟踪流程正确; 2.6个用户根据负荷均衡算法被负荷分担到POOL内的不同SGSN上; | 备注:该测试例同样适用于RNC; |
1.1.2.用户以TLLI发起附着请求,成功找到和NRI对应的SGSN 测试项目编号 1.1.2 | 项目属性:必选 | 测试项目:用户以TLLI发起附着请求 | 测试目的:验证BSC能够从TLLI中获得NRI,并根据自身保存的NRI与SGSN的对应关系找出服务的SGSN,将消息分发到该SGSN | 测试参考:3GPP TS 23.236 | 测试前提条件: 1.测试环境中SGSN POOL功能打开,相关数据配置正确; 2.用户已成功注册到POOL内,且处于空闲态; | 测试配置:测试组网图一 | 测试流程: 1.通过OM查询用户信息,确定用户目前归属的SGSN; 2.打开用户信令消息跟踪; 3.用户以TLLI发起附着请求,并成功激活PDP上下文,进行分组数据传输; 4.数据传输结束,用户释放PDP上下文; | 测试预期结果: 1.附着流程成功,PDP上下文成功激活,消息跟踪流程正确; 2.数据传输完成后所有资源释放正常; 3.用户的服务SGSN没有改变,该会话消息被正确分发到NRI对应的SGSN上; | 备注:该用例同样适用于RNC以P-TMSI发起会话建立请求; |
1.1.3.用户以TLLI发起附着请求,没有和NRI对应的SGSN 测试项目编号:1.1.3 | 项目属性:必选 | 测试项目: 用户以TLLI发起附着请求,所带的NRI没有与其对应的SGSN | 测试目的:验证当NRI没有与其对应的SGSN时,BSC能够采用负荷均衡算法,将呼叫消息分发到POOL内某个SGSN上 | 测试参考:3GPP TS 23.236 | 测试前提条件: 1.测试环境中SGSN POOL功能打开,相关数据配置正确; 2.用户已成功注册到POOL内,且处于空闲态; | 测试配置:测试组网图一 | 测试流程: 1.在POOL内的所有SGSN上打开用户信令消息跟踪; 2.通过OM查询用户信息,确定用户的TLLI中NRI目前对应的SGSN; 3.在BSC上删除NRI与该SGSN的对应关系; 4.用户以TLLI发起附着请求,并激活PDP上下文,进行分组数据传输; 5.会话结束,用户释放PDP上下文; 6.用户去附着; 7.重复3~6步操作,并执行6次; | 测试预期结果: 1.用户附着成功,PDP上下文成功激活,消息跟踪流程正确; 2.6次RAU流程建立按照负荷均衡算法,被负荷分担到POOL内不同的SGSN上; | 备注: 1. 该用例同样适用于RNC以P-TMSI发起会话建立请求; 2. 测试流程第4步,第一次会话建立可能失败,原因为SGSN返回“TLLI unknown”),但后续PDP上下文建立成功。如符合上述描述,预期结果1应属于满足。 |
1.1.4.用户以TLLI发起附着请求,所带NRI对应的SGSN不可达 测试项目编号:1.1.4 | 项目属性:必选 | 测试项目:用户以TLLI发起附着请求,所带NRI对应的SGSN信令点不可达 | 测试目的:验证当NRI对应的SGSN信令点不可达时,BSC能够采用负荷均衡算法,将呼叫消息分发到POOL内其他SGSN上 | 测试参考:3GPP TS 23.236 | 测试前提条件: 1.测试环境中SGSN POOL功能打开,相关数据配置正确; 2.6用户均已成功注册到POOL内同一个SGSN上,且处于空闲态; | 测试配置:测试组网图一 | 测试流程: 1.在POOL内的所有SGSN上打开用户信令消息跟踪; 2.通过OM查询用户信息,确定6个用户的TLLI中的NRI目前对应的SGSN; 3.断开该SGSN与BSC的连接; 4.用户1以TLLI发起一次附着请求,激活PDP上下文,并进行分组数据传输; 5.数据传输结束,用户释放PDP上下文; 6.用户2-6重复4~5步操作; | 测试预期结果: 1.用户附着成功,PDP上下文成功激活,消息跟踪流程正确; 2.6个用户按照负荷均衡算法,被负荷分担到POOL内不同的SGSN上; | 备注: 1. 该用例同样适用于RNC以P-TMSI发起会话建立请求; 2. 测试流程第4步,第一次会话建立可能失败,原因为SGSN返回“TLLI unknown”),但后续会话建立成功。如符合上述描述,预期结果1应属于满足。 |
|