怎么计算基站的覆盖距离和面积(2G.4G,定向和全向)

BT零 回复了问题 • 2 人关注 • 1 个回复 • 1279 次浏览 • 2018-11-15 10:04 • 来自相关话题

【IMS】SIP应答消息状态码与功能详解(二)

Jumbo 发表了文章 • 0 个评论 • 1249 次浏览 • 2018-10-19 09:45 • 来自相关话题

前面给大家介绍了临时应答(1XX) 、会话成功(2XX)以及重定向(3XX)三类应答消息代码,今天继续介绍客户端请求失败(4xx)、服务器失败(5XX)及全局性错误(6XX)三类应答消息代码。




4)客户端请求失败4xx 
4xx应答定义了特定服务器响应的请求失败的情况。客户端不应在不更改请求的情况下重新尝试同一个请求。(例如,增加合适的认证信息)。不过,同一个请求交给不同服务器也许就会成功。 
 400 Bad Request 
请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误,比如”Missing Call-ID header field”。 
401 Unauthorized 
请求需要用户认证。这个应答是由UAS和注册服务器产生的,而407(Proxy Authentication Required)是proxy服务器产生的。 
402 Payment Required 
保留/以后使用 
403 Forbidden 
服务端支持这个请求,但是拒绝执行请求。增加验证信息是没有必要的,并且请求应当不被重试。 
404 Not Found 
服务器返回最终信息:用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下, 也会产生这个应答。 
405 Method Not Allowed 
服务器支持Request-Line中的方法,但是对于这个Request-URI中的地址来说,是不允许应用这个方法的。 
应答必须包括一个Allow头域,这个头域包含了指定地址允许的方法列表。
406 Not Acceptable 
请求中的资源只会导致产生一个在请求中的Accept头域外的,内容无法接收的错误。 
407 Proxy Authentication Required 
这个返回码和401(Unauthorized)很类似,但是标志了客户端应当首先在proxy上通过认证。
这个返回码用于应用程序访问通讯网关(比如,电话网关),而很少用于被叫方要求认证。 
408 Request Timeout 
在一段时间内,服务器不能产生一个终结应答,例如,如果它无法及时决定用户的位置。客户端可以在稍后不更改请求的内容然后重新尝试请求。 
410 Gone 
请求的资源在本服务器上已经不存在了,并且不知道应当把请求转发到哪里。这个问题将会是永久性的。
如果服务器不知道,或者不容易检测,这个资源消失是临时性质的还是永久性质的,那么应当返回一个404(Not Found)。 
413 Request Entity Too Large 
服务器拒绝处理请求,因为这个请求的实体超过了服务器希望或者能够处理的大小。这个服务器应当关闭连接避免客户端重发这个请求。 
如果这个情况是暂时的,那么服务端应当包含一个Retry-After头域来表明这是一个暂时的故障,并且客户端可以过一段时间再次尝试。 
414 Request-URI Too Long 
服务器拒绝这个请求,因为Request-URI超过了服务器能够处理的长度。 
415 Unsupported Media Type 
服务器由于请求的消息体的格式本服务器不支持,所以拒绝处理这个请求。这个服务器必须根据内容的故障类型,返回一个Accept,Accpet-Encoding,或者Accept-Language头域列表。
416 Unsupported URI Scheme 
服务器由于不支持Request-URI中的URI方案而终止处理这个请求。 
420 Bad Extension 
服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不支持的扩展。
421 Extension Required 
UAS需要特定的扩展来处理这个请求,但是这个扩展并没有在请求的Supported头域中列出。具有这个应答码的应答必须包含一个Require头域列出所需要的扩展。 
UAS不应当使用这个应答除非它真的不能给客户端提供有效的服务。相反,如果在Support头域中没有列出需要的扩展,服务器应当根据基准的SIP兼容的方法和客户端支持的扩展来进行处理。 
423 Interval Too Brief 
服务器因为在请求中设置的资源刷新时间(或者有效时间)过短而拒绝请求。这个应答可以用于注册服务器来拒绝那些Contact头域有效期过短的注册请求。
480 Temporarily Unavailable 
请求成功到达被叫方的终端系统,但是被叫方当前不可用(例如,没有登陆,或者登陆了但是状态是不能通讯,或者有”请勿打扰”的标记)。
应答应当在 Retry-After中标志一个合适的重发时间。这个用户也有可能在其他地方是有效的(在本服务器中不知道),Reason-Phrase(原因短句) 应当提示更详细的原因,为什么被叫方暂时不可用,这个值应当是可以被UA设置的,状态码486(Busy Here)可以用来更精确的表示本请求失败的特定原因。 
这个状态码也可以是转发服务或者proxy服务器返回的,因为他们发现Request-URI指定的用户存在,但是没有一个给这个用户的合适的当前转发的地址。 
481 Call/Transaction Does Not Exist 
这个状态表示了UAS接收到请求,但是没有和现存的对话或者事务匹配。 
482 Loop Detected 
服务器检测到了一个循环(16.3/4) 。
483 Too Many Hops 
服务器接收到了一个请求,包含的Max-Forwards(20.22)头域是0 。
484 Address InComplete 
服务器接收到了一个请求,它的Request-URI是不完整的,在原因短语中应当有附加的信息说明。
这个状态码可以和拨号交叠,在和拨号交叠中,客户端不知道拨号串的长度,它发送增加长度的字串,并且提示用户输入更多的字串,直到不再出现484(Address Incomplete)应答为止。 
485 Ambiguous 
Request-URI是不明确的。应答可以在Contact头域中包含一个可能的明确的地址列表。这个提示列表可能在安全性和隐私性对用户或者组织造成破坏。必须能够由配置决定是否以404(NotFound)代替这个应答,又或者禁止对不明确的地址使用可能的选择列表。 
带有Request-URI的请求的一个应答例子: 
sip: lee@example.com: 
SIP/2.0 485 Ambiguous 
Contact: Carol Lee <sip:carol.lee@example.com> 
Contact: Ping Lee <sip:p.lee@example.com> 
Contact: Lee M.Foote <sips:lee.foote@example.com> 
部分email和语音邮箱系统提供了这个功能。
这个状态码和3xx状态码不同:对于300来说,它是假定同一个人或者服务有不同的地址选择。所以对3xx来说,自动选择系统或者连续查找就有效,但是对485(Ambiguous)应答来说,一定要用户的干预。 
486 Busy Here 
当成功联系到被叫方的终端系统,但是被叫方当前在这个终端系统上不能接听这个电话,那么应答应当回给呼叫方一个更合适的时间在Retry-After头域重试。这个用户也许在其他地方有效,比如电话邮箱系统等等。如果我们知道没有其他终端系统能够接听这个呼叫,那么应当返回一个状态码600(Busy Everywhere)。 
487 Request Terminated 
请求被BYE或者CANCEL所终止,这个应答永远不会给CANCEL请求本身回复。 
488 Not Acceptable Here 
这个应答和606(Not Acceptable)有相同的含义,但是只是应用于Request-URI所指出的特定资源不能接受,在其他地方请求可能可以接受。 
包含了媒体兼容性描述的消息体可以出现在应答中,并且根据INVITE请求中的Accept头域进行规格化(如果没有Accept头域,那么就是application/sdp)。
这个应答就像给OPTIONS请求的200(OK)应答的消息体一样。 
491 Request Pending 
在同一个对话中,UAS接收到的请求有一个正在处理。 
493 Undecipherable 
UAS接收到了一个请求,包含了一个加密的MIME,并且不知道或者没有提供合适的解密密钥。
这个应答可以包含单个包体,这个包体包含了合适的公钥,这个公钥用于给这个UAS通讯中加密包体使用的。




5)服务器失败5xx 
5xx应答是当服务器本身故障的时候给出的失败应答。 
500 Server Internal Error 
服务器遇到了未知的情况,并且不能继续处理请求。
客户端可以显示特定的错误情况,并且可以在几秒种以后重新尝试这个请求。 
如果这个情况是临时的,服务器应当在Retry-After头域标志客户端过多少秒钟之后重新尝试这个请求。 
501 Not Implemented 
服务器没有实现相关的请求功能。当UAS不认识请求的方法,并且对每一个用户都无法支持这个方法的时候,应当返回这个应答。(proxy不考虑请求的方法而转发请求)。 
注意:405(Method Not Allowed)是因为服务器实现了这个请求方法,但是这个请求方法在特定请求中不被支持。 
502 Bad Gateway 
服务器作为gateway或者proxy存在,从下行服务器上接收到了一个非法的应答(这个应答对应的请求是本服务器为了完成请求而转发给下行服务器的)。 
503 Service Unavailable 
由于临时的过载或者服务器管理导致的服务器暂时不可用。这个服务器可以在应答中增加一个Retry-After来让客户端重试这个请求,如果没有Retry-After指出,客户端必须就像收到了一个500(Server Internal Error)应答一样处理。 
客户端(proxy或者UAC)收到503(Service Unavailable)应当尝试转发这个请求到另外一个服务器处理,并且在Retry-After头域中指定的时间内,不应当转发其他请求到这个服务器。 
作为503(Service Unavaliable)的替代,服务器可以拒绝连接或者把请求扔掉。 
504 Server Time-out 
服务器在一个外部服务器上没有收到一个及时的应答。这个外部服务器是本服务器用来访问处理这个请求所需要的。如果从上行服务器上收到的请求中的Expires头域超时,那么应当返回一个408(Request TimeOut)错误。 
505 Version Not Supported 
服务器不支持对应的SIP版本。服务器要是无法处理具有客户端提供的相同主版本号的请求,就会导致这样的错误信息。 
513 Message Too Large 
服务器无法处理请求,因为消息长度超过了处理的长度。 
 
6)全局性错误6xx 
6xx应答意味这服务器给特定用户有一个最终的信息,并不只是在Request-URI的特定实例有最终信息。 
600 Busy Everywhere 
成功联系到被叫方的终端系统,但是被叫方处于忙的状态,并不打算接听电话。
这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以 后可以继续呼叫。如果被叫方不希望提示拒绝的原因,被叫方应当使用603(Decline);只有当终端系统知道没有其他终端节点(比如语音邮箱系统)能 够访问到这个用户的时候才能使用这个应答,否则应当返回一个486(Busy Here)的应答。
603 Decline 
谢绝,当成功访问到被叫方的设备,但是用户明确的不想应答。
这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。
只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。 
604 Does Not Exists Anywhere 
服务器验证了在请求中Request-URI的用户信息,哪里都不存在。 
606 Not Acceptable 
当成功联系到一个UA,但是会话描述的一些部分比如请求的媒体,带宽,或者地址类型不被接收。 
606(NotAcceptable)应答意味着用户希望通讯,但是不能充分支持会话描述。
606(Not Acceptable)应答可以在Warning头域中包含一个原因列表,用于解释为何会话描述不能被支持。
在应答中,可以出现一个包含媒体兼容性描述的消息体,这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化(如果没有Accept头域,那么就是application/sdp),就像给OPTIONS亲求的200(OK)应答中的消息一样。 
我们希望这些媒体协商不要经常需要,并且当一个新用户被邀请加入已经存在的会话的时候,这个媒体协商可能不需要。这取决于邀请的初始化者是否需要对606(Not Acceptable)进行处理。 
这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。
 
关于SIP应答消息状态码与功能详解就到这里,后续如果有相关的疑问可以关注公众号或者加入微信群进行讨论和交流!
 




如果你喜欢本文内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧!




 
 
  查看全部
前面给大家介绍了临时应答(1XX) 、会话成功(2XX)以及重定向(3XX)三类应答消息代码,今天继续介绍客户端请求失败(4xx)、服务器失败(5XX)及全局性错误(6XX)三类应答消息代码。
SIP协议架构.jpg

4)客户端请求失败4xx 
4xx应答定义了特定服务器响应的请求失败的情况。客户端不应在不更改请求的情况下重新尝试同一个请求。(例如,增加合适的认证信息)。不过,同一个请求交给不同服务器也许就会成功。 
  •  400 Bad Request 

请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误,比如”Missing Call-ID header field”。 
  • 401 Unauthorized 

请求需要用户认证。这个应答是由UAS和注册服务器产生的,而407(Proxy Authentication Required)是proxy服务器产生的。 
  • 402 Payment Required 

保留/以后使用 
  • 403 Forbidden 

服务端支持这个请求,但是拒绝执行请求。增加验证信息是没有必要的,并且请求应当不被重试。 
  • 404 Not Found 

服务器返回最终信息:用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下, 也会产生这个应答。 
  • 405 Method Not Allowed 

服务器支持Request-Line中的方法,但是对于这个Request-URI中的地址来说,是不允许应用这个方法的。 
应答必须包括一个Allow头域,这个头域包含了指定地址允许的方法列表。
  • 406 Not Acceptable 

请求中的资源只会导致产生一个在请求中的Accept头域外的,内容无法接收的错误。 
  • 407 Proxy Authentication Required 

这个返回码和401(Unauthorized)很类似,但是标志了客户端应当首先在proxy上通过认证。
这个返回码用于应用程序访问通讯网关(比如,电话网关),而很少用于被叫方要求认证。 
  • 408 Request Timeout 

在一段时间内,服务器不能产生一个终结应答,例如,如果它无法及时决定用户的位置。客户端可以在稍后不更改请求的内容然后重新尝试请求。 
  • 410 Gone 

请求的资源在本服务器上已经不存在了,并且不知道应当把请求转发到哪里。这个问题将会是永久性的。
如果服务器不知道,或者不容易检测,这个资源消失是临时性质的还是永久性质的,那么应当返回一个404(Not Found)。 
  • 413 Request Entity Too Large 

服务器拒绝处理请求,因为这个请求的实体超过了服务器希望或者能够处理的大小。这个服务器应当关闭连接避免客户端重发这个请求。 
如果这个情况是暂时的,那么服务端应当包含一个Retry-After头域来表明这是一个暂时的故障,并且客户端可以过一段时间再次尝试。 
  • 414 Request-URI Too Long 

服务器拒绝这个请求,因为Request-URI超过了服务器能够处理的长度。 
  • 415 Unsupported Media Type 

服务器由于请求的消息体的格式本服务器不支持,所以拒绝处理这个请求。这个服务器必须根据内容的故障类型,返回一个Accept,Accpet-Encoding,或者Accept-Language头域列表。
  • 416 Unsupported URI Scheme 

服务器由于不支持Request-URI中的URI方案而终止处理这个请求。 
  • 420 Bad Extension 

服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不支持的扩展。
  • 421 Extension Required 

UAS需要特定的扩展来处理这个请求,但是这个扩展并没有在请求的Supported头域中列出。具有这个应答码的应答必须包含一个Require头域列出所需要的扩展。 
UAS不应当使用这个应答除非它真的不能给客户端提供有效的服务。相反,如果在Support头域中没有列出需要的扩展,服务器应当根据基准的SIP兼容的方法和客户端支持的扩展来进行处理。 
  • 423 Interval Too Brief 

服务器因为在请求中设置的资源刷新时间(或者有效时间)过短而拒绝请求。这个应答可以用于注册服务器来拒绝那些Contact头域有效期过短的注册请求。
  • 480 Temporarily Unavailable 

请求成功到达被叫方的终端系统,但是被叫方当前不可用(例如,没有登陆,或者登陆了但是状态是不能通讯,或者有”请勿打扰”的标记)。
应答应当在 Retry-After中标志一个合适的重发时间。这个用户也有可能在其他地方是有效的(在本服务器中不知道),Reason-Phrase(原因短句) 应当提示更详细的原因,为什么被叫方暂时不可用,这个值应当是可以被UA设置的,状态码486(Busy Here)可以用来更精确的表示本请求失败的特定原因。 
这个状态码也可以是转发服务或者proxy服务器返回的,因为他们发现Request-URI指定的用户存在,但是没有一个给这个用户的合适的当前转发的地址。 
  • 481 Call/Transaction Does Not Exist 

这个状态表示了UAS接收到请求,但是没有和现存的对话或者事务匹配。 
  • 482 Loop Detected 

服务器检测到了一个循环(16.3/4) 。
  • 483 Too Many Hops 

服务器接收到了一个请求,包含的Max-Forwards(20.22)头域是0 。
  • 484 Address InComplete 

服务器接收到了一个请求,它的Request-URI是不完整的,在原因短语中应当有附加的信息说明。
这个状态码可以和拨号交叠,在和拨号交叠中,客户端不知道拨号串的长度,它发送增加长度的字串,并且提示用户输入更多的字串,直到不再出现484(Address Incomplete)应答为止。 
  • 485 Ambiguous 

Request-URI是不明确的。应答可以在Contact头域中包含一个可能的明确的地址列表。这个提示列表可能在安全性和隐私性对用户或者组织造成破坏。必须能够由配置决定是否以404(NotFound)代替这个应答,又或者禁止对不明确的地址使用可能的选择列表。 
带有Request-URI的请求的一个应答例子: 
sip: lee@example.com
SIP/2.0 485 Ambiguous 
Contact: Carol Lee <sip:carol.lee@example.com
Contact: Ping Lee <sip:p.lee@example.com
Contact: Lee M.Foote <sips:lee.foote@example.com
部分email和语音邮箱系统提供了这个功能。
这个状态码和3xx状态码不同:对于300来说,它是假定同一个人或者服务有不同的地址选择。所以对3xx来说,自动选择系统或者连续查找就有效,但是对485(Ambiguous)应答来说,一定要用户的干预。 
  • 486 Busy Here 

当成功联系到被叫方的终端系统,但是被叫方当前在这个终端系统上不能接听这个电话,那么应答应当回给呼叫方一个更合适的时间在Retry-After头域重试。这个用户也许在其他地方有效,比如电话邮箱系统等等。如果我们知道没有其他终端系统能够接听这个呼叫,那么应当返回一个状态码600(Busy Everywhere)。 
  • 487 Request Terminated 

请求被BYE或者CANCEL所终止,这个应答永远不会给CANCEL请求本身回复。 
  • 488 Not Acceptable Here 

这个应答和606(Not Acceptable)有相同的含义,但是只是应用于Request-URI所指出的特定资源不能接受,在其他地方请求可能可以接受。 
包含了媒体兼容性描述的消息体可以出现在应答中,并且根据INVITE请求中的Accept头域进行规格化(如果没有Accept头域,那么就是application/sdp)。
这个应答就像给OPTIONS请求的200(OK)应答的消息体一样。 
  • 491 Request Pending 

在同一个对话中,UAS接收到的请求有一个正在处理。 
  • 493 Undecipherable 

UAS接收到了一个请求,包含了一个加密的MIME,并且不知道或者没有提供合适的解密密钥。
这个应答可以包含单个包体,这个包体包含了合适的公钥,这个公钥用于给这个UAS通讯中加密包体使用的。
SIP消息1.gif

5)服务器失败5xx 
5xx应答是当服务器本身故障的时候给出的失败应答。 
  • 500 Server Internal Error 

服务器遇到了未知的情况,并且不能继续处理请求。
客户端可以显示特定的错误情况,并且可以在几秒种以后重新尝试这个请求。 
如果这个情况是临时的,服务器应当在Retry-After头域标志客户端过多少秒钟之后重新尝试这个请求。 
  • 501 Not Implemented 

服务器没有实现相关的请求功能。当UAS不认识请求的方法,并且对每一个用户都无法支持这个方法的时候,应当返回这个应答。(proxy不考虑请求的方法而转发请求)。 
注意:405(Method Not Allowed)是因为服务器实现了这个请求方法,但是这个请求方法在特定请求中不被支持。 
  • 502 Bad Gateway 

服务器作为gateway或者proxy存在,从下行服务器上接收到了一个非法的应答(这个应答对应的请求是本服务器为了完成请求而转发给下行服务器的)。 
  • 503 Service Unavailable 

由于临时的过载或者服务器管理导致的服务器暂时不可用。这个服务器可以在应答中增加一个Retry-After来让客户端重试这个请求,如果没有Retry-After指出,客户端必须就像收到了一个500(Server Internal Error)应答一样处理。 
客户端(proxy或者UAC)收到503(Service Unavailable)应当尝试转发这个请求到另外一个服务器处理,并且在Retry-After头域中指定的时间内,不应当转发其他请求到这个服务器。 
作为503(Service Unavaliable)的替代,服务器可以拒绝连接或者把请求扔掉。 
  • 504 Server Time-out 

服务器在一个外部服务器上没有收到一个及时的应答。这个外部服务器是本服务器用来访问处理这个请求所需要的。如果从上行服务器上收到的请求中的Expires头域超时,那么应当返回一个408(Request TimeOut)错误。 
  • 505 Version Not Supported 

服务器不支持对应的SIP版本。服务器要是无法处理具有客户端提供的相同主版本号的请求,就会导致这样的错误信息。 
  • 513 Message Too Large 

服务器无法处理请求,因为消息长度超过了处理的长度。 
 
6)全局性错误6xx 
6xx应答意味这服务器给特定用户有一个最终的信息,并不只是在Request-URI的特定实例有最终信息。 
  • 600 Busy Everywhere 

成功联系到被叫方的终端系统,但是被叫方处于忙的状态,并不打算接听电话。
这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以 后可以继续呼叫。如果被叫方不希望提示拒绝的原因,被叫方应当使用603(Decline);只有当终端系统知道没有其他终端节点(比如语音邮箱系统)能 够访问到这个用户的时候才能使用这个应答,否则应当返回一个486(Busy Here)的应答。
  • 603 Decline 

谢绝,当成功访问到被叫方的设备,但是用户明确的不想应答。
这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。
只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。 
  • 604 Does Not Exists Anywhere 

服务器验证了在请求中Request-URI的用户信息,哪里都不存在。 
  • 606 Not Acceptable 

当成功联系到一个UA,但是会话描述的一些部分比如请求的媒体,带宽,或者地址类型不被接收。 
606(NotAcceptable)应答意味着用户希望通讯,但是不能充分支持会话描述。
606(Not Acceptable)应答可以在Warning头域中包含一个原因列表,用于解释为何会话描述不能被支持。
在应答中,可以出现一个包含媒体兼容性描述的消息体,这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化(如果没有Accept头域,那么就是application/sdp),就像给OPTIONS亲求的200(OK)应答中的消息一样。 
我们希望这些媒体协商不要经常需要,并且当一个新用户被邀请加入已经存在的会话的时候,这个媒体协商可能不需要。这取决于邀请的初始化者是否需要对606(Not Acceptable)进行处理。 
这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。
 
关于SIP应答消息状态码与功能详解就到这里,后续如果有相关的疑问可以关注公众号或者加入微信群进行讨论和交流!
 
网优俱乐部1.jpg

如果你喜欢本文内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧!
云端拾贝.jpg

 
 
 

【IMS】SIP应答消息状态码与功能详解(一)

Jumbo 发表了文章 • 0 个评论 • 1769 次浏览 • 2018-10-18 09:55 • 来自相关话题

之前我们向大家介绍过SIP应答消息状态码与功能,但是对于其中的多数功能,我们并不是很了解,对其理解尚停留在字面上,今天我们就为大家比较详细的介绍下这些状态码及其对应的功能含义,希望能对大家有所助益!




1、SIP协议应答消息状态码及功能分类
SIP/2.0 allows six values for the first digit:
      1xx: Provisional -- request received, continuing to process the request;
      2xx: Success -- the action was successfully received, understood, and accepted;
      3xx: Redirection -- further action needs to be taken in order to complete the request;
      4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
      5xx: Server Error -- the server failed to fulfill an apparently valid request;
      6xx: Global Failure -- the request cannot be fulfilled at any server.
The first digit of the Status-Code defines the class of response. 
The last two digits do not have any categorization role.  
For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response", any response with a status code between 200 and 299 as a "2xx response", and so on. 




2 、SIP应答消息状态码与功能
格式:类型  状态码  状态说明
1) 临时应答(1XX) 
100 Trying 正在处理中
180 Ringing 振铃
181 call being forwarder 呼叫正在前向
182 queue 排队
183 session progress 会话进行
2)会话成功(2XX)
200 OK 会话成功
3)重定向(3XX)
300 multiple 多重选择
301 moved permanently 永久移动
302 moved temporaily 临时移动
305 use proxy 用户代理
380 alternative service 替代服务
4)客户端失败(4XX) 
400 bad request 错误请求
401 unauthorized 未授权
402 payment required 付费要求
403 forbidden 禁止
404 not found 未发现
405 method no allowed 方法不允许
406 not acceptable 不可接受
407 proxy authentication required 代理需要认证
408 request timeout 请求超时
410 gone 离开
413 request entity too large 请求实体太大
414 request-url too long 请求URL太长
415 unsupported media type 不支持的媒体类型
416 unsupported url scheme 不支持的URL计划
420 bad extension 不良扩展
421 extension required 需要扩展 
423 interval too brief 间隔太短
480 temporarily unavailable 临时失效
481 call/transaction does not exist 呼叫/事务不存在
482 loop detected 发现环路
483 too many hops 跳数太多
484 address incomplete 地址不完整
485 ambiguous 不明朗
486 busy here 这里忙
487 request terminated 请求终止
488 not acceptable here 这里请求不可接受
491 request pending 未决请求
493 undecipherable 不可辨识
5)服务器失败(5XX)
500 server internal error 服务器内部错误
501 not implemented 不可执行
502 bad gateway 坏网关
503 service unavailable 服务无效
504 server time-out 服务器超时
505 version not supported 版本不支持
513 message too large 消息太大
6)全局性错误(6XX)
600 busy everywhere 全忙
603 decline 丢弃
604 does not exist anywhere 不存在
606 not acceptable 不可接受




3、SIP应答消息状态码详解
1) 临时应答1xx 
临时应答,也就是消息性质的应答,标志了对方服务器正在处理请求,并且还没有决定最后的应答。
如果服务器处理请求需要花200ms以上才能产生终结应答的时候,它应当发送一个1xx应答。 
注意1xx应答并不是可靠传输的,他们不会导致客户端传送一个ACK应答。临时性质的(1xx)应答可以包含消息体,包含会话描述。 
100 Trying 
这个应答表示下一个节点的服务器已经接收到了这个请求并且还没有执行这个请求的特定动作(比如,正在打开数据库的时候)。
这个应答,就像其他临时应答一 样,终止了UAC重新传送INVITE请求。
180 Ringing 
UA收到INVITE请求并且试图提示给用户,这个应答应当初始化一个本地回铃。 
181 Call is Being Forwarded 
呼叫被转发,服务器可以用这个应答代码来表示呼叫正在转发到另一个目的地集合。 
182 Queued 
当呼叫的对方暂时不能接收呼叫,并且服务器决定将呼叫排队等候,而不是拒绝呼叫的时候,那么就应当发出这个应答。当被叫方一旦恢复接收呼叫,他会返回合适的终结应答。
对于这个呼叫状态,可以有一个表示原因的短语,比如:”5 calls queued;expected waiting time is 15minutes”。
服务器可以给出好几个182(Queued)应答告诉呼叫方排队的情况(比如排队靠前了等等)。 
183 Session Progress 
会话进度提示,应答用于提示建立对话的进度信息。
Reason-Phrase(表达原因的句子)、头域或者消息体可以用于提示呼叫进度的更消息的信息。 
2)成功信息2xx 
这个应答表示请求是成功的。 
200 OK 
请求已经处理成功。这个信息取决于不同方法的请求的应答。 
 
3)转发请求3XX 
3xx系列的应答是用于提示用户的新位置信息的,或者为了满足呼叫而转发的额外服务地点。 
300 Multiple Choices 
请求的地址有多个选择,每个选择都有自己的地址,用户或者UA可以选择合适的通讯终端,并且转发这个请求到这个地址。 
应答可以包含一个具有每一个地点的在Accept请求头域中允许的资源特性,这样用户或者UA可以选择一个最合适的地址来转发请求。
这些地址选择也应当在Contact头域中列出。不同于HTTP,SIP应答可以包含多个Contact头域或者一个Contact头域中具有一个地址列表。UA可以使用Contact头域来自动转发或者要求用户确认转发。
如果被叫方可以在多个地址被找到,并且服务器不能或者不愿意转发请求的时候,可以使用这个应答来给呼叫方。 
301 Moved Permently 
当不能在Request-URI指定的地址找到用户的时候,请求的客户端应当使用Contact头域所指出的新的地址重新尝试。
请求者应当用这个新的值来更新本地的目录,地址本和用户地址cache,并且在后续请求中,发送到这个/这些列出的地址。 
302 Moved Temporarily 
请求方应当把请求重新发到这个Contact头域所指出的新地址。新请求的Request-URI应当用这个应答的Contact头域所指出的值。 
在应答中的Expires或者Contact头域的expires参数定义了这个Contact URI的生存周期。UA或者proxy在这个生存周期内cache这个URI。如果没有严格的有效时间,那么这个地址仅仅本次有效,并且不能在以后的事务中保存。 
如果cache的Contact头域的值失败了,那么被转发请求的Request-URI应当再次尝试一次。
临时URI可以比超时时间更快的失效,并且可以有一个新的临时URI。 
305 Use Proxy 
请求的资源必须通过Contact头域中指出的proxy来访问。Contact头域指定了一个proxy的URI,接收到这个应答的对象应当通过这个proxy重新发送这个单个请求。
305(UseProxy)必须是UAS产生的。 
380 Alternative Service 
呼叫不成功,但是可以尝试另外的服务。另外的服务在应答的消息体中定义。
消息体的格式在这里没有定义,可能在以后的规范中定义。 

限于篇幅太长,今天就给大家先介绍临时应答(1XX) 、会话成功(2XX)以及重定向(3XX)三类应答消息代码,后续继续介绍客户端请求失败(4xx)、服务器失败(5XX)及全局性错误(6XX),欢迎大家持续关注!





如果你喜欢本文内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧!




 
 
  查看全部
之前我们向大家介绍过SIP应答消息状态码与功能,但是对于其中的多数功能,我们并不是很了解,对其理解尚停留在字面上,今天我们就为大家比较详细的介绍下这些状态码及其对应的功能含义,希望能对大家有所助益!
SIP协议架构.jpg

1、SIP协议应答消息状态码及功能分类
SIP/2.0 allows six values for the first digit:
      1xx: Provisional -- request received, continuing to process the request;
      2xx: Success -- the action was successfully received, understood, and accepted;
      3xx: Redirection -- further action needs to be taken in order to complete the request;
      4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
      5xx: Server Error -- the server failed to fulfill an apparently valid request;
      6xx: Global Failure -- the request cannot be fulfilled at any server.
The first digit of the Status-Code defines the class of response. 
The last two digits do not have any categorization role.  
For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response", any response with a status code between 200 and 299 as a "2xx response", and so on. 
SIP消息1.gif

2 、SIP应答消息状态码与功能
格式:类型  状态码  状态说明
1) 临时应答(1XX) 
100 Trying 正在处理中
180 Ringing 振铃
181 call being forwarder 呼叫正在前向
182 queue 排队
183 session progress 会话进行
2)会话成功(2XX)
200 OK 会话成功
3)重定向(3XX)
300 multiple 多重选择
301 moved permanently 永久移动
302 moved temporaily 临时移动
305 use proxy 用户代理
380 alternative service 替代服务
4)客户端失败(4XX) 
400 bad request 错误请求
401 unauthorized 未授权
402 payment required 付费要求
403 forbidden 禁止
404 not found 未发现
405 method no allowed 方法不允许
406 not acceptable 不可接受
407 proxy authentication required 代理需要认证
408 request timeout 请求超时
410 gone 离开
413 request entity too large 请求实体太大
414 request-url too long 请求URL太长
415 unsupported media type 不支持的媒体类型
416 unsupported url scheme 不支持的URL计划
420 bad extension 不良扩展
421 extension required 需要扩展 
423 interval too brief 间隔太短
480 temporarily unavailable 临时失效
481 call/transaction does not exist 呼叫/事务不存在
482 loop detected 发现环路
483 too many hops 跳数太多
484 address incomplete 地址不完整
485 ambiguous 不明朗
486 busy here 这里忙
487 request terminated 请求终止
488 not acceptable here 这里请求不可接受
491 request pending 未决请求
493 undecipherable 不可辨识
5)服务器失败(5XX)
500 server internal error 服务器内部错误
501 not implemented 不可执行
502 bad gateway 坏网关
503 service unavailable 服务无效
504 server time-out 服务器超时
505 version not supported 版本不支持
513 message too large 消息太大
6)全局性错误(6XX)
600 busy everywhere 全忙
603 decline 丢弃
604 does not exist anywhere 不存在
606 not acceptable 不可接受
SIP消息2.jpg

3、SIP应答消息状态码详解
1) 临时应答1xx 
临时应答,也就是消息性质的应答,标志了对方服务器正在处理请求,并且还没有决定最后的应答。
如果服务器处理请求需要花200ms以上才能产生终结应答的时候,它应当发送一个1xx应答。 
注意1xx应答并不是可靠传输的,他们不会导致客户端传送一个ACK应答。临时性质的(1xx)应答可以包含消息体,包含会话描述。 
  • 100 Trying 

这个应答表示下一个节点的服务器已经接收到了这个请求并且还没有执行这个请求的特定动作(比如,正在打开数据库的时候)。
这个应答,就像其他临时应答一 样,终止了UAC重新传送INVITE请求。
  • 180 Ringing 

UA收到INVITE请求并且试图提示给用户,这个应答应当初始化一个本地回铃。 
  • 181 Call is Being Forwarde

呼叫被转发,服务器可以用这个应答代码来表示呼叫正在转发到另一个目的地集合。 
  • 182 Queued 

当呼叫的对方暂时不能接收呼叫,并且服务器决定将呼叫排队等候,而不是拒绝呼叫的时候,那么就应当发出这个应答。当被叫方一旦恢复接收呼叫,他会返回合适的终结应答。
对于这个呼叫状态,可以有一个表示原因的短语,比如:”5 calls queued;expected waiting time is 15minutes”。
服务器可以给出好几个182(Queued)应答告诉呼叫方排队的情况(比如排队靠前了等等)。 
  • 183 Session Progress 

会话进度提示,应答用于提示建立对话的进度信息。
Reason-Phrase(表达原因的句子)、头域或者消息体可以用于提示呼叫进度的更消息的信息。 
2)成功信息2xx 
这个应答表示请求是成功的。 
  • 200 OK 

请求已经处理成功。这个信息取决于不同方法的请求的应答。 
 
3)转发请求3XX 
3xx系列的应答是用于提示用户的新位置信息的,或者为了满足呼叫而转发的额外服务地点。 
  • 300 Multiple Choices 

请求的地址有多个选择,每个选择都有自己的地址,用户或者UA可以选择合适的通讯终端,并且转发这个请求到这个地址。 
应答可以包含一个具有每一个地点的在Accept请求头域中允许的资源特性,这样用户或者UA可以选择一个最合适的地址来转发请求。
这些地址选择也应当在Contact头域中列出。不同于HTTP,SIP应答可以包含多个Contact头域或者一个Contact头域中具有一个地址列表。UA可以使用Contact头域来自动转发或者要求用户确认转发。
如果被叫方可以在多个地址被找到,并且服务器不能或者不愿意转发请求的时候,可以使用这个应答来给呼叫方。 
  • 301 Moved Permently 

当不能在Request-URI指定的地址找到用户的时候,请求的客户端应当使用Contact头域所指出的新的地址重新尝试。
请求者应当用这个新的值来更新本地的目录,地址本和用户地址cache,并且在后续请求中,发送到这个/这些列出的地址。 
  • 302 Moved Temporarily 

请求方应当把请求重新发到这个Contact头域所指出的新地址。新请求的Request-URI应当用这个应答的Contact头域所指出的值。 
在应答中的Expires或者Contact头域的expires参数定义了这个Contact URI的生存周期。UA或者proxy在这个生存周期内cache这个URI。如果没有严格的有效时间,那么这个地址仅仅本次有效,并且不能在以后的事务中保存。 
如果cache的Contact头域的值失败了,那么被转发请求的Request-URI应当再次尝试一次。
临时URI可以比超时时间更快的失效,并且可以有一个新的临时URI。 
  • 305 Use Proxy 

请求的资源必须通过Contact头域中指出的proxy来访问。Contact头域指定了一个proxy的URI,接收到这个应答的对象应当通过这个proxy重新发送这个单个请求。
305(UseProxy)必须是UAS产生的。 
  • 380 Alternative Service 

呼叫不成功,但是可以尝试另外的服务。另外的服务在应答的消息体中定义。
消息体的格式在这里没有定义,可能在以后的规范中定义。 

限于篇幅太长,今天就给大家先介绍临时应答(1XX) 、会话成功(2XX)以及重定向(3XX)三类应答消息代码,后续继续介绍客户端请求失败(4xx)、服务器失败(5XX)及全局性错误(6XX),欢迎大家持续关注!

网优俱乐部1.jpg

如果你喜欢本文内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧!
云端拾贝.jpg

 
 
 

关于TDD、BDD和DDD的一些看法

回复

BT零 发起了问题 • 3 人关注 • 0 个回复 • 941 次浏览 • 2017-03-05 11:30 • 来自相关话题

VoLTE用户通过拜访地网络建立语音承载的过程

Jumbo 发表了文章 • 0 个评论 • 961 次浏览 • 2018-10-12 14:08 • 来自相关话题

前面我们讲了,当开启了PRECONDITION及基于 PCC的主叫位置信息获取功能后,主叫侧语音承载预留触发点从之前的SDP ANSWER改为了SDP OFFER,也就是从收到被叫回复的183 Session Progress 变成了收到主叫发出的 INVITE;主叫侧语音承载更新与激活的触发点,也从收到被叫回复的200 OK(For Update) 变成了收到主叫发出的 UPDATE,相应的信令触发点变成下图所示。




具体的语音专用承载的建立过程如下。




1. P-CSCF收到手机 A发出的INVITE消息,其中包含了SDP编码列表。 
2. 由于网络开启了主叫位置信息获取功能,P-CSCF的触发点为SDP OFFER,所以主叫P-CSCF在这里就触发了向 PCRF发送AAR消息,将带宽、业务类型、IP地 址、端口等信息以MEDIA FLOW的描述格式携带(这里语音 FLOW的资源预留带宽为预估值,且状态为非双向激活态(ENABLED-DOWNLINK/或 DISABLED,取决于运营商 策略),请求语音专用承载的资源预留,并携带SpecificAction=ACCESS_NETWORK_INFO_REPORT,及Required-AccessInfo=USER_LOCATION,告知PCRF除了资源预留,同时还需要位置信息,PCRF回复AAA消息确认。
3. PCRF向PGW发送RAR消息,将从P-CSCF获得的资源预留信息转换成CHARGING RULE描述格式,进行资源预留,同时还加入语音承载的QOS信息,如QCI=1、ARP、MBR等,其中还携带Required-Access-Info=USER_LOCATION,标识需求位置信息,PGW返回RAA消息确认。
4.PGW(SGW)向MME发送Create Bearer Request,并将IP地址,端口等信息转换成TFT(Traffic Flow Template)描述格式,请求建立语音专用承载。
5-8.MME向ENODEB发送E-RAB Setup Request,并请求建立语音专用承载的无线资源。ENODEB在和UE建立完无线资源后,返回E-RAB Setup Response。
9.MME在向 PGW(SGW)回复的Create Bearer Response响应中携带UserLocation Info (ULI) ,其中包含UE的TAI和 ECGI。 
10. PGW向PCRF发送CCR(UPDATE),其中包含EventTrigger=ACCESS_NETWORK_INFO_REPORT,及3GPP-User-Location-Info,其中携 带了UE的E-CGI和TAI。11. PCRF向P-CSCF发送RAR,其中包含 EventTrigger=ACCESS_NETWORK_INFO_REPORT,及 3GPP-User-Location-Info,其中携带UE的E-CGI和TAI。
12. P-CSCF将获取的位置信息,放入INVITE消息的P-Access-Network-Info中传递。(如果需要的话,还将根据 TAI完成区号映射的转换)。
这样,主叫侧的语音专用承载就成功预留了,并同时完成了主叫的位置信息获取。 但需要留意的是,在这一次触发的语音专用承载建立过程中,由于还没有完成和UE-B的编解码协商,所以这一次所建立的语音专用承载的带宽为预估值,将在后续的 UPDATE流程中再次更新为最终协商值。
当UE-A在收到183 SESSION PROGRESS消息,根据其中的信息,在确认自己已经成功建立起语音承载的无线资源后,便发送UPDATE消息,其中包含了最终协商后的编解码信息,以及资源预留的更新状态。
对于被叫侧的语音专用承载的建立与主叫侧流程类似,只是触发点不同,并且不含位置信息获取。
被叫侧P-CSCF收到手机B回复的183 Session Progress 触发承载预留;
被叫侧P-CSCF收到手机B回复的200 OK(For Update)触发承载修改与激活。




 





如果你喜欢本文内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧! 查看全部
前面我们讲了,当开启了PRECONDITION及基于 PCC的主叫位置信息获取功能后,主叫侧语音承载预留触发点从之前的SDP ANSWER改为了SDP OFFER,也就是从收到被叫回复的183 Session Progress 变成了收到主叫发出的 INVITE;主叫侧语音承载更新与激活的触发点,也从收到被叫回复的200 OK(For Update) 变成了收到主叫发出的 UPDATE,相应的信令触发点变成下图所示。
SDP对语音承载出发点影响.jpg

具体的语音专用承载的建立过程如下。
语音专用承载的建立.jpg

1. P-CSCF收到手机 A发出的INVITE消息,其中包含了SDP编码列表。 
2. 由于网络开启了主叫位置信息获取功能,P-CSCF的触发点为SDP OFFER,所以主叫P-CSCF在这里就触发了向 PCRF发送AAR消息,将带宽、业务类型、IP地 址、端口等信息以MEDIA FLOW的描述格式携带(这里语音 FLOW的资源预留带宽为预估值,且状态为非双向激活态(ENABLED-DOWNLINK/或 DISABLED,取决于运营商 策略),请求语音专用承载的资源预留,并携带SpecificAction=ACCESS_NETWORK_INFO_REPORT,及Required-AccessInfo=USER_LOCATION,告知PCRF除了资源预留,同时还需要位置信息,PCRF回复AAA消息确认。
3. PCRF向PGW发送RAR消息,将从P-CSCF获得的资源预留信息转换成CHARGING RULE描述格式,进行资源预留,同时还加入语音承载的QOS信息,如QCI=1、ARP、MBR等,其中还携带Required-Access-Info=USER_LOCATION,标识需求位置信息,PGW返回RAA消息确认。
4.PGW(SGW)向MME发送Create Bearer Request,并将IP地址,端口等信息转换成TFT(Traffic Flow Template)描述格式,请求建立语音专用承载。
5-8.MME向ENODEB发送E-RAB Setup Request,并请求建立语音专用承载的无线资源。ENODEB在和UE建立完无线资源后,返回E-RAB Setup Response。
9.MME在向 PGW(SGW)回复的Create Bearer Response响应中携带UserLocation Info (ULI) ,其中包含UE的TAI和 ECGI。 
10. PGW向PCRF发送CCR(UPDATE),其中包含EventTrigger=ACCESS_NETWORK_INFO_REPORT,及3GPP-User-Location-Info,其中携 带了UE的E-CGI和TAI。11. PCRF向P-CSCF发送RAR,其中包含 EventTrigger=ACCESS_NETWORK_INFO_REPORT,及 3GPP-User-Location-Info,其中携带UE的E-CGI和TAI。
12. P-CSCF将获取的位置信息,放入INVITE消息的P-Access-Network-Info中传递。(如果需要的话,还将根据 TAI完成区号映射的转换)。
这样,主叫侧的语音专用承载就成功预留了,并同时完成了主叫的位置信息获取。 但需要留意的是,在这一次触发的语音专用承载建立过程中,由于还没有完成和UE-B的编解码协商,所以这一次所建立的语音专用承载的带宽为预估值,将在后续的 UPDATE流程中再次更新为最终协商值。
当UE-A在收到183 SESSION PROGRESS消息,根据其中的信息,在确认自己已经成功建立起语音承载的无线资源后,便发送UPDATE消息,其中包含了最终协商后的编解码信息,以及资源预留的更新状态。
对于被叫侧的语音专用承载的建立与主叫侧流程类似,只是触发点不同,并且不含位置信息获取。
被叫侧P-CSCF收到手机B回复的183 Session Progress 触发承载预留;
被叫侧P-CSCF收到手机B回复的200 OK(For Update)触发承载修改与激活。
Volte.jpg

 

网优俱乐部1.jpg

如果你喜欢本文内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧!
云端拾贝.jpg

3GPP协议查看实例【转载来源不明,貌似中兴文档中的部分内容】

Meta 发表了文章 • 0 个评论 • 660 次浏览 • 2018-10-11 16:30 • 来自相关话题

2 协议查看实例
2.1 2/3G互操作协议查看实例
在做23G互操作时,需要查看RAB指派中的一个信元,是Service Handover,这个信元可能影响到RNC是否下发测量控制.
1) 打开25.413协议后,找到9.1.3,看到RAB ASSIGNMENT REQUEST消息中有一个Service Handover信元,而且他是“O”,代表的是该信元是可选择的,可以带也可以不带。
 





2) 然后到9.2.1.41查看对于Service Handover这个信元的具体解释。






如果带上了这个信元,要看信元具体带的是什么值,有0,1,2三种可能,对应着三种情况。
Service Handover=0:Handover to GSM should be performed,意义是切换到GSM可以执行;
Service Handover=1:Handover to GSM should not be performed,意义是切换到GSM不应该执行;
Service Handover=0:Handover to GSM shall not be performed,意义是切换到GSM不会执行;
2.2 从IuB口信令看码道占用协议查看实例
在RRC连接建立过程中,通过Radio Link Setup Request消息中的信元可以看出打孔限制参数。
1) 从25.433协议中Radio Link Setup Request消息中可以看到Puncture Limit信元。“M”,表示该信元是必选的。
 





2) 再到9.2.1.50看Puncture Limit信元的详细解释。
 





PL 有0.。。15共16个选项、
0代表PL=40%,可以打孔60%;
1代表PL=44%,可以打孔56%;
2代表PL=48%,可以打孔52%;
......
14代表PL=96%,可以打孔4%;
15代表PL=100%,不可以打孔。 查看全部
2 协议查看实例
2.1 2/3G互操作协议查看实例

在做23G互操作时,需要查看RAB指派中的一个信元,是Service Handover,这个信元可能影响到RNC是否下发测量控制.
1) 打开25.413协议后,找到9.1.3,看到RAB ASSIGNMENT REQUEST消息中有一个Service Handover信元,而且他是“O”,代表的是该信元是可选择的,可以带也可以不带。
 
协议查看实例1.png


2) 然后到9.2.1.41查看对于Service Handover这个信元的具体解释。

协议查看实例2.png


如果带上了这个信元,要看信元具体带的是什么值,有0,1,2三种可能,对应着三种情况。
Service Handover=0:Handover to GSM should be performed,意义是切换到GSM可以执行;
Service Handover=1:Handover to GSM should not be performed,意义是切换到GSM不应该执行;
Service Handover=0:Handover to GSM shall not be performed,意义是切换到GSM不会执行;
2.2 从IuB口信令看码道占用协议查看实例
在RRC连接建立过程中,通过Radio Link Setup Request消息中的信元可以看出打孔限制参数。
1) 从25.433协议中Radio Link Setup Request消息中可以看到Puncture Limit信元。“M”,表示该信元是必选的。
 
协议查看实例3.png


2) 再到9.2.1.50看Puncture Limit信元的详细解释。
 
协议查看实例4.png


PL 有0.。。15共16个选项、
0代表PL=40%,可以打孔60%;
1代表PL=44%,可以打孔56%;
2代表PL=48%,可以打孔52%;
......
14代表PL=96%,可以打孔4%;
15代表PL=100%,不可以打孔。

LTE物理下行信道-总体描述

luo_kf 发表了文章 • 0 个评论 • 591 次浏览 • 2018-10-11 10:26 • 来自相关话题

1. 物理信道
下行物理信道对应于一组资源粒子(RE),这些RE承载有来自上层的信息。这些信道包括:Physical Downlink Shared Channel(PDSCH),Physical Broadcast Channel(PBCH),Physical Multicast Channel(PMCH),Physical Control Format Indicator Channel(PCFICH),Physical Downlink Control Channel(PDCCH),Physical Hybrid ARQ Indicator Channel(PHICH)。
2. 物理信号
下行物理信号对应于一组资源粒子(RE),这些RE不承载来自上层的信息。这些信号包括:Reference signal,Synchronization signal。
在下行参考信号(Reference signal)中,包括三种类型的下行参考信号(Rel 8):
小区专用参考信号(cell-specific RS):小区专用参考信号有下行信道质量测量和下行信道估计(UE以此进行相干检测和解调)两个作用。在每一个非MBSFN的子帧上传输。同时,其放置的位置不同,也会表征不同的antenna port。MBSFN参考信号:在MBSFN子帧中传送。在多播业务情况下,用于下行测量,同步,以及解调MBSFN数据。UE专用参考信号:终端专用参考信号只在分配给传输模式7(transmission mode)的终端的资源块(Resource Block)上传输,在这些资源块上,小区级参考信号也在传输,这种传输模式下,终端根据终端专用参考信号进行信道估计和数据解调。终端专用参考信号一般用于波束赋形(Beamforming),此时,基站(eNodeB)一般使用一个物理天线阵列来产生定向到一个终端的波束,这个波束代表一个不同的信道,因此需要根据终端专用参考信号进行信道估计和数据解调。
 
跟大家分享个好工具-网优云,是我们网优俱乐部为通信行业的童鞋们倾心打造。近期网优俱乐部向各位用户免费赠送VIP特权体验,欢迎大家踊跃试用!
 请登录“网优云(http://gis.234gclub.com)”,在“用户中心”的“个人信息”中输入邀请码:4mgc9k,即可获得一个月的免费VIP体验。




如果喜欢我发的文章或者觉得文章对您的进步有帮助,请持续关注【通信小弟】微信公众号!! 查看全部
1. 物理信道
下行物理信道对应于一组资源粒子(RE),这些RE承载有来自上层的信息。这些信道包括:Physical Downlink Shared Channel(PDSCH),Physical Broadcast Channel(PBCH),Physical Multicast Channel(PMCH),Physical Control Format Indicator Channel(PCFICH),Physical Downlink Control Channel(PDCCH),Physical Hybrid ARQ Indicator Channel(PHICH)。
2. 物理信号
下行物理信号对应于一组资源粒子(RE),这些RE不承载来自上层的信息。这些信号包括:Reference signal,Synchronization signal。
在下行参考信号(Reference signal)中,包括三种类型的下行参考信号(Rel 8):
  • 小区专用参考信号(cell-specific RS):小区专用参考信号有下行信道质量测量和下行信道估计(UE以此进行相干检测和解调)两个作用。在每一个非MBSFN的子帧上传输。同时,其放置的位置不同,也会表征不同的antenna port。
  • MBSFN参考信号:在MBSFN子帧中传送。在多播业务情况下,用于下行测量,同步,以及解调MBSFN数据。
  • UE专用参考信号:终端专用参考信号只在分配给传输模式7(transmission mode)的终端的资源块(Resource Block)上传输,在这些资源块上,小区级参考信号也在传输,这种传输模式下,终端根据终端专用参考信号进行信道估计和数据解调。终端专用参考信号一般用于波束赋形(Beamforming),此时,基站(eNodeB)一般使用一个物理天线阵列来产生定向到一个终端的波束,这个波束代表一个不同的信道,因此需要根据终端专用参考信号进行信道估计和数据解调。

 
跟大家分享个好工具-网优云,是我们网优俱乐部为通信行业的童鞋们倾心打造。近期网优俱乐部向各位用户免费赠送VIP特权体验,欢迎大家踊跃试用!
 请登录“网优云(http://gis.234gclub.com”,在“用户中心”的“个人信息”中输入邀请码:4mgc9k,即可获得一个月的免费VIP体验。
0.jpg

如果喜欢我发的文章或者觉得文章对您的进步有帮助,请持续关注【通信小弟】微信公众号!!
订阅号二维码.jpg

234G系统消息汇总

luo_kf 发表了文章 • 9 个评论 • 1061 次浏览 • 2018-10-11 10:00 • 来自相关话题

2G系统消息
共有8类系统信息块:SIB1~SIB8,具体如下:
SIB1:随机接入控制信息(RACH)和小区频点分配表(即CA 表),在BCCH 信道上发送。SIB2:随机接入控制信息(RACH)和小区频点分配表(即CA 表),在BCCH 信道上发送。SIB3:位置区标识、小区标识、随机接入控制信息(RACH)以及和小区选择有关的参数SIB4:位置区标识、随机接入控制信息(RACH)、小区选择参数以及可选的CBCH 信道信息SIB5:邻近小区的频点信息(即BA2 表SIB6:位置区标识、小区标识、以及一些描述小区功能的参数SIB7/8:该系统消息必选,在BCCH 上发送,包含用于该小区重选信息
3G系统消息
共有18类系统信息块:SIB1~SIB18,其中TDD常用的有9种,具体如下:
SIB1:NAS系统参数,定时器信息和drx cycle lengthcoefficient;SIB2:URA id;SIB3:小区选择/重选门限参数(用于空闲态);指示SIB4是否在本小区广播SIB4:小区选择/重选门限参数(仅在连接状态下有效);SIB5:公共信道配置(用于空闲态);指示SIB6是否在本小区广播SIB6:公共信道配置(仅在连接状态下有效);SIB7:业务接入控制参数,可能随无线环境改变经常变化,因此SIB7需要周期读取;SIB11:测量控制信息,包括邻小区列表;SIB12:测量控制信息,包括邻小区列表(仅在连接状态下有效)。
4G系统消息
共有13类系统信息块:SIB1~SIB13,其中TDD常用的有11种,具体如下:
SIB 1
Cell access related information:小区接入相关信息,包括TAC:区域跟踪码,PLMN标识Cell Selection Info:小区选择信息,包括CELL IDp-Max:适用于该小区的值。如果不存在,UE根据自己的能力确定最大发射功率。freqBandIndicator:频率带宽指示schedulingInfoList:调度信息列表tdd-Configuration:用于描述TDD专用物理信道的配置
SIB 2
ac-BarringInfo:接入限制信息radioResourceConfigCommon:公共无线资源配置ue-TimersAndConstants:UE定时器和计数器freqInfo:频率信息
SIB 3
cellReselectionInfoCommon:公共的小区重选信息包括CELL ID和频点t-ReselectionEUTRA:表示TS 36.304 [4]中的参数“TreselectionEUTRAN”cellReselectionServingFreqInfo:表示频间小区重选和RAT (Radio AccessTechnology)间小区的公共信息intra Freq cell Reselection Info:表示频内小区的小区重选公共信息
SIB 4
intraFreqNeighbCellList:表示频内邻区列表,含有具体的小区重选参数intraFreqBlackCellList:表示被列入黑名单的频内邻区列表
SIB 5  
频间邻区列表
SIB 6 
UTRAN邻区列表
SIB 7  
Carrier Freqs Info List:提供相邻GERAN载频的列表,为相邻GERAN小区所监控carrierFreqs:表示归为一组GERAN载频的GERAN 载频列表commonInfo:定义GERAN载频组的小区重选参数集q-RxLevMin:GSM小区要求的最小RX等级p-MaxGERAN:上行载频GERAN的最大许可传输功率
SIB 8
systemTimeInfo:表示关于CDMA2000系统时间的信息searchWindowSize:该搜索窗口为一个CDMA2000参数,用于帮助邻近导频的搜索parametersHRPD:该小区重选参数仅仅适用于CDMA2000 HRPD 系统的相互作用cellReselectionParametersHRPD:小区重选参数仅仅适用于CDMA2000HRPD 系统的小区重选NeighCellListCDMA2000: CDMA2000 邻区列表parameters1XRTT:小区重选参数仅仅适用于CDMA20001XRTT系统的交互phyCellIdList:标识CDMA 2000小区id列表
SIB 9
HNB-Name:HNB名称
SIB 10
messageIdentifier:标识ETWS 通知的来源和类型serialNumber:标识ETWS通知的变化warningType:标识ETWS主要通知的警告类型,并提供关于紧急情况用户注意以及用户反馈的信息warningSecurityInformation:提供ETWS通知安全方面的信息
SIB 11
warningMessageSegmentType:表示包括的ETWS警告消息分段 是否是最后一个分段warningMessageSegmentNumber:表示包含在SIB中的ETWS警告消息分段的分段号码
 
跟大家分享个好工具-网优云,是我们网优俱乐部为通信行业的童鞋们倾心打造。近期网优俱乐部向各位用户免费赠送VIP特权体验,欢迎大家踊跃试用!
 请登录“网优云(http://gis.234gclub.com)”,在“用户中心”的“个人信息”中输入邀请码:4mgc9k,即可获得一个月的免费VIP体验。




如果喜欢我发的文章或者觉得文章对您的进步有帮助,请持续关注【通信小弟】微信公众号!! 查看全部
2G系统消息
共有8类系统信息块:SIB1~SIB8,具体如下:
  • SIB1:随机接入控制信息(RACH)和小区频点分配表(即CA 表),在BCCH 信道上发送。
  • SIB2:随机接入控制信息(RACH)和小区频点分配表(即CA 表),在BCCH 信道上发送。
  • SIB3:位置区标识、小区标识、随机接入控制信息(RACH)以及和小区选择有关的参数
  • SIB4:位置区标识、随机接入控制信息(RACH)、小区选择参数以及可选的CBCH 信道信息
  • SIB5:邻近小区的频点信息(即BA2 表
  • SIB6:位置区标识、小区标识、以及一些描述小区功能的参数
  • SIB7/8:该系统消息必选,在BCCH 上发送,包含用于该小区重选信息

3G系统消息
共有18类系统信息块:SIB1~SIB18,其中TDD常用的有9种,具体如下:
  • SIB1:NAS系统参数,定时器信息和drx cycle lengthcoefficient;
  • SIB2:URA id;
  • SIB3:小区选择/重选门限参数(用于空闲态);指示SIB4是否在本小区广播
  • SIB4:小区选择/重选门限参数(仅在连接状态下有效);
  • SIB5:公共信道配置(用于空闲态);指示SIB6是否在本小区广播
  • SIB6:公共信道配置(仅在连接状态下有效);
  • SIB7:业务接入控制参数,可能随无线环境改变经常变化,因此SIB7需要周期读取;
  • SIB11:测量控制信息,包括邻小区列表;
  • SIB12:测量控制信息,包括邻小区列表(仅在连接状态下有效)。

4G系统消息
共有13类系统信息块:SIB1~SIB13,其中TDD常用的有11种,具体如下:
SIB 1
  • Cell access related information:小区接入相关信息,包括TAC:区域跟踪码,PLMN标识
  • Cell Selection Info:小区选择信息,包括CELL ID
  • p-Max:适用于该小区的值。如果不存在,UE根据自己的能力确定最大发射功率。
  • freqBandIndicator:频率带宽指示
  • schedulingInfoList:调度信息列表
  • tdd-Configuration:用于描述TDD专用物理信道的配置

SIB 2
  • ac-BarringInfo:接入限制信息
  • radioResourceConfigCommon:公共无线资源配置
  • ue-TimersAndConstants:UE定时器和计数器
  • freqInfo:频率信息

SIB 3
  • cellReselectionInfoCommon:公共的小区重选信息包括CELL ID和频点
  • t-ReselectionEUTRA:表示TS 36.304 [4]中的参数“TreselectionEUTRAN”
  • cellReselectionServingFreqInfo:表示频间小区重选和RAT (Radio AccessTechnology)间小区的公共信息
  • intra Freq cell Reselection Info:表示频内小区的小区重选公共信息

SIB 4
  • intraFreqNeighbCellList:表示频内邻区列表,含有具体的小区重选参数
  • intraFreqBlackCellList:表示被列入黑名单的频内邻区列表

SIB 5  
  • 频间邻区列表

SIB 6 
  • UTRAN邻区列表

SIB 7  
  • Carrier Freqs Info List:提供相邻GERAN载频的列表,为相邻GERAN小区所监控
  • carrierFreqs:表示归为一组GERAN载频的GERAN 载频列表
  • commonInfo:定义GERAN载频组的小区重选参数集
  • q-RxLevMin:GSM小区要求的最小RX等级
  • p-MaxGERAN:上行载频GERAN的最大许可传输功率

SIB 8
  • systemTimeInfo:表示关于CDMA2000系统时间的信息
  • searchWindowSize:该搜索窗口为一个CDMA2000参数,用于帮助邻近导频的搜索
  • parametersHRPD:该小区重选参数仅仅适用于CDMA2000 HRPD 系统的相互作用
  • cellReselectionParametersHRPD:小区重选参数仅仅适用于CDMA2000HRPD 系统的小区重选
  • NeighCellListCDMA2000: CDMA2000 邻区列表
  • parameters1XRTT:小区重选参数仅仅适用于CDMA20001XRTT系统的交互
  • phyCellIdList:标识CDMA 2000小区id列表

SIB 9
  • HNB-Name:HNB名称

SIB 10
  • messageIdentifier:标识ETWS 通知的来源和类型
  • serialNumber:标识ETWS通知的变化
  • warningType:标识ETWS主要通知的警告类型,并提供关于紧急情况用户注意以及用户反馈的信息
  • warningSecurityInformation:提供ETWS通知安全方面的信息

SIB 11
  • warningMessageSegmentType:表示包括的ETWS警告消息分段 是否是最后一个分段
  • warningMessageSegmentNumber:表示包含在SIB中的ETWS警告消息分段的分段号码

 
跟大家分享个好工具-网优云,是我们网优俱乐部为通信行业的童鞋们倾心打造。近期网优俱乐部向各位用户免费赠送VIP特权体验,欢迎大家踊跃试用!
 请登录“网优云(http://gis.234gclub.com”,在“用户中心”的“个人信息”中输入邀请码:4mgc9k,即可获得一个月的免费VIP体验。
0.jpg

如果喜欢我发的文章或者觉得文章对您的进步有帮助,请持续关注【通信小弟】微信公众号!!
订阅号二维码.jpg

影响VoLTE语音承载建立触发点的常见因素-SDP

Jumbo 发表了文章 • 0 个评论 • 900 次浏览 • 2018-10-11 09:50 • 来自相关话题

在VoLTE中,网络侧是何时去触发建立语音专用承载呢? 这取决于很多因素。比如是否启用PRECONDITION、是在SDP Offer还是SDP Answer阶段发起建立、通话是否涉及Early Media(如呼叫失败的语音通知,彩铃)等。




之前我们向大家介绍了是否启用 PRECONDITION对语音承载建立触发点的影响,接下来,我们再来看看另一个影响语音承载建立触发点的常见因素:P-CSCF的语音专用承载预留的触发点是SDP OFFER还是SDP ANSWER。
在VOLTE的呼叫建立过程中,SDP往往都是以OFFER/ANSWER的模式成对出现的。如下图中INVITE消息中的是SDP OFFER,而183 Session Progress中的是SDP ANSWER;同理,UPDATE消息中是SDP OFFER,而 200 OK(FOR UPDATE)中的是SDP ANSWER。




某些运营商由于引入了某些补充功能,如基于PCC的主叫位置信息获取,号码补全等,需要在发起呼叫时,通过 PCRF去EPC域获取一些信息,并将这些信息放在SIP消息中传递下去。所以要求主叫侧的P-CSCF在收到INVITE时,就需要发起与PCRF的交互(如 AAR/RAR等消息),并与语音专用承载资源的预留过程合并,这就使得主叫侧 语音承载预留触发点从之前的SDP ANSWER改为了SDP OFFER,也就是从收到被叫回复的183 Session Progress 变成了收到主叫发出的INVITE;同理,主叫侧语音承载更新与激活的触发点,也从收到被叫回复的200 OK(For Update) 变成了收到主叫发出的UPDATE。
在开启了PRECONDITION以及基于PCC的主叫位置信息获取功能后,语音承载建立信令的触发点将变成下图所示。




 





如果你喜欢本公众号内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧! 查看全部
在VoLTE中,网络侧是何时去触发建立语音专用承载呢? 这取决于很多因素。比如是否启用PRECONDITION、是在SDP Offer还是SDP Answer阶段发起建立、通话是否涉及Early Media(如呼叫失败的语音通知,彩铃)等。
Volte.jpg

之前我们向大家介绍了是否启用 PRECONDITION对语音承载建立触发点的影响,接下来,我们再来看看另一个影响语音承载建立触发点的常见因素:P-CSCF的语音专用承载预留的触发点是SDP OFFER还是SDP ANSWER。
  • 在VOLTE的呼叫建立过程中,SDP往往都是以OFFER/ANSWER的模式成对出现的。
  • 如下图中INVITE消息中的是SDP OFFER,而183 Session Progress中的是SDP ANSWER;同理,UPDATE消息中是SDP OFFER,而 200 OK(FOR UPDATE)中的是SDP ANSWER。

VoLTE语音承载建立3.jpg

某些运营商由于引入了某些补充功能,如基于PCC的主叫位置信息获取,号码补全等,需要在发起呼叫时,通过 PCRF去EPC域获取一些信息,并将这些信息放在SIP消息中传递下去。所以要求主叫侧的P-CSCF在收到INVITE时,就需要发起与PCRF的交互(如 AAR/RAR等消息),并与语音专用承载资源的预留过程合并,这就使得主叫侧 语音承载预留触发点从之前的SDP ANSWER改为了SDP OFFER,也就是从收到被叫回复的183 Session Progress 变成了收到主叫发出的INVITE;同理,主叫侧语音承载更新与激活的触发点,也从收到被叫回复的200 OK(For Update) 变成了收到主叫发出的UPDATE。
在开启了PRECONDITION以及基于PCC的主叫位置信息获取功能后,语音承载建立信令的触发点将变成下图所示。
SDP对语音承载出发点影响.jpg

 

网优俱乐部1.jpg

如果你喜欢本公众号内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧!
云端拾贝.jpg

3GPP协议阅读指南【转载来源不明,貌似中兴文档中的部分内容】

Meta 发表了文章 • 0 个评论 • 677 次浏览 • 2018-10-10 14:10 • 来自相关话题

1 协议阅读指南
1.1 协议的框架
      如下图所示,在第三代移动通讯体系中,目前主要有两大阵营,即WCDMA与CDMA2000(其他一些小的阵营我们几乎可以不用关心,此处不再提及。另,TD-SCDMA可以认为是WCDMA阵营中的一种无线技术)。WCDMA的协议是由3GPP标准化组织制定的,而CDMA2000是由3GPP2标准化组织制定的,所以有时也用3GPP代指WCDMA,用3GPP2代指CDMA2000。
      在第二代移动通讯体制中,也主要有两大阵营,即GSM与窄带CDMA(IS-95)。由GSM向3G过渡是走的WCDMA技术路线,由IS-95CDMA向3G过渡是走CDMA2000的路线。





 
      我们这个项目将要做的是WCDMA的基站(Node B),所以与我们直接相关的协议是3GPP的协议。3GPP的协议分为3个版本,即R99与R4、R5,R99是第一阶段的版本,计划于2000年6月定型(FROZEN),以后只作一些微小的修改,但实际上到目前为止还没有完全定型。2001年3月版的R99可以认为已经大部分定型。而R4目前正处在标准化的阶段,2001年3月已经有一个初步定型的规范。我们要实现的就是R99(下图中加粗黑框部分)。
      R99目前有5个版本,即2000年3月份版本、6月份版本、9月份版本、12月份版本和2001年3月份版本,我们应该阅读的是9月份的版本(3GPP2000.9),3月份版本与6月份版本可以作为参考。大家阅读协议时可以看到,3月份与6月份的版本是从21系列开始的,9月份是从01系列开始的,为什么会这样呢?
      因为3GPP的协议(特别是CN侧协议)是在GSM与GPRS基础上发展的,3GPP的协议引用了很多GSM的协议,在9月份的版本中,3GPP将部分引用到的GSM的协议转化为3GPP的协议,所以在9月份的目录中多了01~12系列的协议(GSM协议是从01~12)。大家可以认为,“真正的”3GPP的协议还是从21系列开始的(当然,GSM的01~12系列也是3GPP协议的一部分)。
1.2 阅读协议的技巧
      读协议首先要抓住总体与重点,否则,任何一个人也无法阅读全部的协议。对于我们来说,3GPP的R99当然是所有协议的重点,与3GPP密切相关的协议是次重点。
1.2.1 UMTS与3GPP的关系
      UMTS是一个过时的术语,现在已经不再使用,因为UMTS的提法是在3GPP成立以前由SMG(特别移动组)提出的,在3GPP成立以后将不再使用。
1.2.2 GSM协议与3GPP协议的关系
      GSM协议的最后一个完整版本是PHASE 2+的R1998。ETSI的SMG在制定R1999时,3GPP成立,于是SMG被解散,R1999也被移交给3GPP,由3GPP继续完成R99。所以R99是GSM与3G的衔接版本(R99已经是3G)。
1.2.3 R99与R00、R4、R5的关系
      在R99协议成形的初期,将R99看作是GSM向3G过渡的版本,存在电路交换域的业务;将R00作为全IP网络版本的代名词。在2000年9月以后的版本中,就不再使用R00这个术语,而改用Release4、Release5来替代,也就意味着,在Rel5以后的版本都是全IP的网络结构。
1.2.4 在R99中原来的GSM01~12系列的协议与3GPP协议之间的关系
      应该说,R99目录中的01~12系列协议也是3GPP协议的一部分。3GPP的协议目录是与原GSM协议的目录相对应的,如01对应于21系列,02对应于22系列,……,12对应于32系列。对于转换的协议,系列号也是对应的,如原来GSM的03.02协议描述了系统框架,相应地,在3GPP协议的23.02协议中也是描述r99的系统框架。大家在看协议时可以按照这个规律去看。
      在R99中,如果一个协议因为引进3G而改变较大,则将其放在21系列以后的目录中,如果是基本引用原来的GSM协议,则仍将其放在01~12系列中。
1.2.5 在REL4以后的版本中41~52系列的协议与3GPP协议之间的关系
      41~52系列是与01~12系列相对应的。基本上是将GSM的协议直接引用过来,再将协议版本号修改为4.x.x。
1.2.6 各协议系列的功能
      在21.101与01.01中,有一个所有协议的清单(或一览表),该文件可以帮助大家迅速地查阅其他协议是什么协议。
      在23.121中,是一个对R99整体框架的一个描述协议,阅读该协议可以对R99有一个整体的了解。
      下面将各个系列所起的作用大致描述如下:
      a) 21、01、41系列是一个概述性的系列,只是提出了一些要求;
      b) 22、02、42系列是一个概述性的系列,描述了系统的特征与部分业务的,主要是stage1阶段的描述;
      c) 23、03、43系列是一个较为详细的描述,比22系列要详细,主要是stage2阶段的描述;
      d) 24、04、44系列是UE与网络之间的信令,包括层3信令;
      e) 25系列是无线部分的描述,其中,25.100系列主要是射频部分的协议,25.200序列描述物理层协议,25.300序列描述层二和层三协议,25.400序列描述了Iu、Iur、Iub接口,RNC是通过Iub口与Node B相连接的;05与45系列主要是描述GSM与EDGE的无线特征;
      f) 26、06、46系列定义了各种编码器;
      g) 27、07、47系列定义了数据业务;
      h) 08、48系列主要是定义BSS与CN之间的接口;28系列编号为保留编号,暂无,RNS与CN之间的接口在25系列中描述;
      i) 29、09、49系列定义了网络间的各种信令;
      j) 30、10系列定义了3GPP将来的一些计划与工作安排;例如,MExE在R1998 10.57中就提出了;LCS在R1998 10.71中就提出了;EDGE的计划在R1999 10.59中就提出了。
      k) 31、11、51系列定义了USIM与SIM;
      l) 32、12、52系列定义了操作与维护;
      m) 33系列定义了安全相关的部分;
      n) 34系列定义了相关的测试;
      o) 35系列定义了安全相关的算法,该系列中的算法需要licence。
      p) 13系列是接入要求,由于该系列的标准只在欧洲适用,所以3GPP未将该系列收入协议中。
1.2.7 看协议的步骤
      在看协议时,首先应该看21.101,再看23.121,然后在根据需要阅读25系列的部分协议。在初步掌握WCDMA的整体概貌的情况下,可以直接调到自己所需要的阅读的、与自己工作直接相关的协议上。
      3GPP应用了很多其他的协议,主要是ETSI的GSM协议、ITU-T的协议、IETF的RFC,可以在相关的协议目录中去查找这些协议。
1.2.8 注意协议版本号
      3GPP的协议的版本号分为三部分(如V3.0.1),最前面是大版本号,用来标识技术上的重大改变,如果这部分的版本号升号了,表明技术上的改动较大,另,所有版本号大于等于3的协议,都是正式协议,否则为草稿协议;中间的版本号用来标识技术上的小改变,如果该部分的版本号升号了,意味着该协议与上一个版本相比,技术有小的改变;最后的版本号用来标识一些错误的修订(包括编辑错误),如果只是该版本号有所改变,则几乎没有什么必要去重新阅读新版本的协议。
1.2.9 注意协议修改记录
      注意修改记录。有时候刚刚看过某一协议,又发现有新版本的协议了,怎么办?其实你没有必要将整个新协议重新看一遍,只需看看协议最后的修改记录,就能够知道协议在哪些方面有了改变,只需重新阅读做了修改的部分即可。
1.2.10 注意协议附录
      协议附录有两种附录,normative与informative目录。对于normative附录,该附录是协议的一部分,具有与协议中正文内容同等的意义,是需要执行的标准;对于informative附录,该附录只是为了读者理解该协议而附的附录,不是协议标准的一部分,实现时可以不完全遵从。
        请正确理解、区分这两种不同性质的附录。
1.2.11 注意协议的类型
      目前3GPP协议中有两类,一类为TS xx.yyy,这是技术规范(Technical Specifications),必须遵守;另一类为TR xx.yyy,这是技术报告(Technical Reports),是一些厂家做的技术报告,仅作参考,不一定遵守。 查看全部
1 协议阅读指南
1.1 协议的框架

      如下图所示,在第三代移动通讯体系中,目前主要有两大阵营,即WCDMA与CDMA2000(其他一些小的阵营我们几乎可以不用关心,此处不再提及。另,TD-SCDMA可以认为是WCDMA阵营中的一种无线技术)。WCDMA的协议是由3GPP标准化组织制定的,而CDMA2000是由3GPP2标准化组织制定的,所以有时也用3GPP代指WCDMA,用3GPP2代指CDMA2000。
      在第二代移动通讯体制中,也主要有两大阵营,即GSM与窄带CDMA(IS-95)。由GSM向3G过渡是走的WCDMA技术路线,由IS-95CDMA向3G过渡是走CDMA2000的路线。

QQ图片20181010141103.png

 
      我们这个项目将要做的是WCDMA的基站(Node B),所以与我们直接相关的协议是3GPP的协议。3GPP的协议分为3个版本,即R99与R4、R5,R99是第一阶段的版本,计划于2000年6月定型(FROZEN),以后只作一些微小的修改,但实际上到目前为止还没有完全定型。2001年3月版的R99可以认为已经大部分定型。而R4目前正处在标准化的阶段,2001年3月已经有一个初步定型的规范。我们要实现的就是R99(下图中加粗黑框部分)。
      R99目前有5个版本,即2000年3月份版本、6月份版本、9月份版本、12月份版本和2001年3月份版本,我们应该阅读的是9月份的版本(3GPP2000.9),3月份版本与6月份版本可以作为参考。大家阅读协议时可以看到,3月份与6月份的版本是从21系列开始的,9月份是从01系列开始的,为什么会这样呢?
      因为3GPP的协议(特别是CN侧协议)是在GSM与GPRS基础上发展的,3GPP的协议引用了很多GSM的协议,在9月份的版本中,3GPP将部分引用到的GSM的协议转化为3GPP的协议,所以在9月份的目录中多了01~12系列的协议(GSM协议是从01~12)。大家可以认为,“真正的”3GPP的协议还是从21系列开始的(当然,GSM的01~12系列也是3GPP协议的一部分)。
1.2 阅读协议的技巧
      读协议首先要抓住总体与重点,否则,任何一个人也无法阅读全部的协议。对于我们来说,3GPP的R99当然是所有协议的重点,与3GPP密切相关的协议是次重点。
1.2.1 UMTS与3GPP的关系
      UMTS是一个过时的术语,现在已经不再使用,因为UMTS的提法是在3GPP成立以前由SMG(特别移动组)提出的,在3GPP成立以后将不再使用。
1.2.2 GSM协议与3GPP协议的关系
      GSM协议的最后一个完整版本是PHASE 2+的R1998。ETSI的SMG在制定R1999时,3GPP成立,于是SMG被解散,R1999也被移交给3GPP,由3GPP继续完成R99。所以R99是GSM与3G的衔接版本(R99已经是3G)。
1.2.3 R99与R00、R4、R5的关系
      在R99协议成形的初期,将R99看作是GSM向3G过渡的版本,存在电路交换域的业务;将R00作为全IP网络版本的代名词。在2000年9月以后的版本中,就不再使用R00这个术语,而改用Release4、Release5来替代,也就意味着,在Rel5以后的版本都是全IP的网络结构。
1.2.4 在R99中原来的GSM01~12系列的协议与3GPP协议之间的关系
      应该说,R99目录中的01~12系列协议也是3GPP协议的一部分。3GPP的协议目录是与原GSM协议的目录相对应的,如01对应于21系列,02对应于22系列,……,12对应于32系列。对于转换的协议,系列号也是对应的,如原来GSM的03.02协议描述了系统框架,相应地,在3GPP协议的23.02协议中也是描述r99的系统框架。大家在看协议时可以按照这个规律去看。
      在R99中,如果一个协议因为引进3G而改变较大,则将其放在21系列以后的目录中,如果是基本引用原来的GSM协议,则仍将其放在01~12系列中。
1.2.5 在REL4以后的版本中41~52系列的协议与3GPP协议之间的关系
      41~52系列是与01~12系列相对应的。基本上是将GSM的协议直接引用过来,再将协议版本号修改为4.x.x。
1.2.6 各协议系列的功能
      在21.101与01.01中,有一个所有协议的清单(或一览表),该文件可以帮助大家迅速地查阅其他协议是什么协议。
      在23.121中,是一个对R99整体框架的一个描述协议,阅读该协议可以对R99有一个整体的了解。
      下面将各个系列所起的作用大致描述如下:
      a) 21、01、41系列是一个概述性的系列,只是提出了一些要求;
      b) 22、02、42系列是一个概述性的系列,描述了系统的特征与部分业务的,主要是stage1阶段的描述;
      c) 23、03、43系列是一个较为详细的描述,比22系列要详细,主要是stage2阶段的描述;
      d) 24、04、44系列是UE与网络之间的信令,包括层3信令;
      e) 25系列是无线部分的描述,其中,25.100系列主要是射频部分的协议,25.200序列描述物理层协议,25.300序列描述层二和层三协议,25.400序列描述了Iu、Iur、Iub接口,RNC是通过Iub口与Node B相连接的;05与45系列主要是描述GSM与EDGE的无线特征;
      f) 26、06、46系列定义了各种编码器;
      g) 27、07、47系列定义了数据业务;
      h) 08、48系列主要是定义BSS与CN之间的接口;28系列编号为保留编号,暂无,RNS与CN之间的接口在25系列中描述;
      i) 29、09、49系列定义了网络间的各种信令;
      j) 30、10系列定义了3GPP将来的一些计划与工作安排;例如,MExE在R1998 10.57中就提出了;LCS在R1998 10.71中就提出了;EDGE的计划在R1999 10.59中就提出了。
      k) 31、11、51系列定义了USIM与SIM;
      l) 32、12、52系列定义了操作与维护;
      m) 33系列定义了安全相关的部分;
      n) 34系列定义了相关的测试;
      o) 35系列定义了安全相关的算法,该系列中的算法需要licence。
      p) 13系列是接入要求,由于该系列的标准只在欧洲适用,所以3GPP未将该系列收入协议中。
1.2.7 看协议的步骤
      在看协议时,首先应该看21.101,再看23.121,然后在根据需要阅读25系列的部分协议。在初步掌握WCDMA的整体概貌的情况下,可以直接调到自己所需要的阅读的、与自己工作直接相关的协议上。
      3GPP应用了很多其他的协议,主要是ETSI的GSM协议、ITU-T的协议、IETF的RFC,可以在相关的协议目录中去查找这些协议。
1.2.8 注意协议版本号
      3GPP的协议的版本号分为三部分(如V3.0.1),最前面是大版本号,用来标识技术上的重大改变,如果这部分的版本号升号了,表明技术上的改动较大,另,所有版本号大于等于3的协议,都是正式协议,否则为草稿协议;中间的版本号用来标识技术上的小改变,如果该部分的版本号升号了,意味着该协议与上一个版本相比,技术有小的改变;最后的版本号用来标识一些错误的修订(包括编辑错误),如果只是该版本号有所改变,则几乎没有什么必要去重新阅读新版本的协议。
1.2.9 注意协议修改记录
      注意修改记录。有时候刚刚看过某一协议,又发现有新版本的协议了,怎么办?其实你没有必要将整个新协议重新看一遍,只需看看协议最后的修改记录,就能够知道协议在哪些方面有了改变,只需重新阅读做了修改的部分即可。
1.2.10 注意协议附录
      协议附录有两种附录,normative与informative目录。对于normative附录,该附录是协议的一部分,具有与协议中正文内容同等的意义,是需要执行的标准;对于informative附录,该附录只是为了读者理解该协议而附的附录,不是协议标准的一部分,实现时可以不完全遵从。
        请正确理解、区分这两种不同性质的附录。
1.2.11 注意协议的类型
      目前3GPP协议中有两类,一类为TS xx.yyy,这是技术规范(Technical Specifications),必须遵守;另一类为TR xx.yyy,这是技术报告(Technical Reports),是一些厂家做的技术报告,仅作参考,不一定遵守。