홈 [IMS] Cx Interface AVP 정리
포스트
취소

[IMS] Cx Interface AVP 정리

게시 2021/08/13
By Youngwoo Lee
11 분읽는 시간

Cx Interface AVPs

틀린 부분이 있을 수 있습니다. 지적 부탁드립니다.

Cx Interface의 AVPs 중 일부를 발췌해서 정리

- Visited-Network-Identifier AVP

접기/펼치기 The Visited-Network-Identifier AVP is of type OctetString. This AVP contains an identifier that helps the HSS to identify the visited network (e.g. the visited network domain name). Coding of octets is H-PLMN operator specific. The I-CSCF maps a received P-Visited-Network-ID onto an Octet String value that is consistently configured in I-CSCF and HSS to uniquely identify the visited network.


type : UTF8OctectString

방문한 홈 네트워크를 식별하는데 도움을 주는 식별자가 포함되어 있음

(예를 들면, visited network domain name)

- User-Authorization-Type AVP

type : Enumerated

User Authorization operation(사용자 권한 부여 작업)에서 사용자 권한 유형을 나타낸다. (i.e. UAR)
아래 값들 중 하나가 정의된다.

TypeValueDescription
REGISTRATION0최초 Regi 또는 Re-Regi 시에 사용
DE_REGISTRATION1Regi 취소 시에 사용
REGISTRATION_AND_CAPABILITIES2I-CSCF가 HSS에게 S-CSCF 정보를 명시적으로 요청할 때 사용 (I-CSCF는 HSS에 저장된 사용자의 현재 S-CSCF에 연결할 수 없고 새로운 S-CSCF를 선택해야 할 때 REGI_AND_CAPA를 사용)
접기/펼치기 The User-Authorization-Type AVP is of type Enumerated, and indicates the type of user authorization being performed in a User Authorization operation, i.e. UAR command. The following values are defined:

REGISTRATION (0)
This value is used in case of the initial registration or re-registration. I-CSCF determines this from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is not equal to zero.
This is the default value.

DE_REGISTRATION (1)
This value is used in case of the de-registration. I-CSCF determines this from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is equal to zero.

REGISTRATION_AND_CAPABILITIES (2)
This value is used when the I-CSCF explicitly requests S-CSCF capability information from the HSS. The I-CSCF shall use this value when the user's current S-CSCF, which is stored in the HSS, cannot be contacted and a new S-CSCF needs to be selected

[29.228] If the request corresponds to a de-registration, i.e. Expires field or expires parameter in Contact field in the REGISTER method is equal to zero, this AVP shall be present in the command and the value shall be set to DE-REGISTRATION. If the request corresponds to an initial registration or a re-registration, i.e. Expires field or expires parameter in Contact field in the REGISTER method is not equal to zero then this AVP may be absent from the command. If present its value shall be set to REGISTRATION. If the request corresponds to an initial registration or a re-registration or a de-registration and the I-CSCF explicitly queries the S-CSCF capabilities, then this AVP shall be present in the command and the value shall be set to REGISTRATION_AND_CAPABILITIES. The I-CSCF shall use this value when the S-CSCF currently assigned to the Public User Identity in the HSS, cannot be contacted and a new S-CSCF needs to be selected. The I-CSCF shall also use this value for RLOS related registrations when the S-CSCF currently assigned to the Public User Identity in the HSS does not support RLOS (see 3GPP TS 23.228 [1] annex Z) and a new S-CSCF (supporting RLOS) needs to be selected. RLOS support of the different S-CSCFs shall be locally configured in the I-CSCF, and this capability is independent on the subscribed capabilities received from HSS.


- Server-Capabilities AVP

type : Grouped

I-CSCF가 S-CSCF를 선택하는데 assist하는 정보를 포함하고 있음.
(만약 Public User Identity와 연관된 S-CSCF가 없다면, HSS는 I-CSCF가 적절한 S-CSCF를 선택하는 것을 허용하는 S-CSCF 기능(capabilities)과 관련된 정보를 응답할 수 있음.)

  • Mandatory-Capability AVP

    type : Unsigned32

    single determined mandatory capability or a set of capabilities of an S-CSCF

  • Optional-Capability AVP

    type : Unsigned32

    single determined mandatory capability or a set of capabilities of an S-CSCF

접기/펼치기 The Server-Capabilities AVP is of type Grouped. This AVP contains information to assist the I-CSCF in the selection of an S-CSCF.
AVP format
Server-Capabilities ::= \<AVP header: 603 10415\>
*[Mandatory-Capability]
*[Optional-Capability]
*[Server-Name]
*[AVP]

6.3.5 Mandatory-Capability AVP
The Mandatory-Capability AVP is of type Unsigned32. Each value included in this AVP can be used to represent a single determined mandatory capability or a set of capabilities of an S-CSCF, as described in 3GPP TS 29.228 [1] (clause 6.7).

6.3.6 Optional-Capability AVP
The Optional-Capability AVP is of type Unsigned32. Each value included in this AVP can be used to represent a single determined optional capability or a set of capabilities of an S-CSCF, as described in 3GPP TS 29.228 [1] (clause 6.7).
6.7 S-CSCF Assignment
The list of mandatory and optional capabilities received by an I-CSCF from the HSS allows operators to distribute users between S-CSCFs, depending on the different capabilities (e.g. features, role, geographical location) that each S-CSCF may have. Alternatively, an operator has the possibility to steer users to certain S-CSCFs.
The operator shall define (possibly based on the functionality offered by each S-CSCF installed in the network) the exact meaning of the S-CSCF mandatory and optional capabilities available in his network. It is an operator task to allocate a unique value to represent a single capability (e.g. support of "wildcarded PSI") or a set of capabilities (e.g. support of "alias" and "Shared IFC sets" and "wildcarded PSI") and to use these values to identify capabilities that are mandatory and/or optional to support for a given subscription. It is a configuration task for the operator to ensure that the I-CSCF has a correct record of the capabily values received from the HSS for each S-CSCF available in his network. The I-CSCF and the HSS do not need to know the semantic of these values. This semantic is exclusively an operator issue.
As a first choice, the I-CSCF shall select an S-CSCF that has all the mandatory and optional capabilities for the user. Only if that is not possible shall the I-CSCF apply a 'best-fit' algorithm. If more than one S-CSCF is identified that supports all mandatory capabilities the I-CSCF may then consider optional capabilities in selecting a specific S-CSCF. The 'best-fit' algorithm is implementation dependent and out of the scope of this specification.
It is the responsibility of the operator to ensure that there are S-CSCFs which have mandatory capabilities indicated by the HSS for any given user. However, configuration errors may occur. If such errors occur and they prevent the I-CSCF from selecting an S-CSCF which meets the mandatory capabilities indicated by the HSS, the I-CSCF shall inform the operator via the O&M subsystem.
As an alternative to selecting an S-CSCF based on the list of capabilities received from the HSS, it is possible to steer users to certain S-CSCFs. To do this, the operator may include one or more S-CSCF names as part of the capabilities of the user profile. The reason for the selection (e.g. all the users belonging to the same company/group could be in the same S-CSCF to implement a VPN service) and the method of selection are operator issues and out of the scope of this specification. If this alternative is chosen, the HSS shall include Server-Name AVPs in the Server-Capabilities AVP and should not include Mandatory-Capability AVPs or Optional-Capability AVPs in the Server-Capabilities AVP, and the I-CSCF when receiving Server-Name AVPs within the Server-Capabilities AVP shall discard any Mandatory-Capability AVP and any Optional-Capability AVP received within the Server-Capabilities AVP.
The following table is a guideline for operators that records S-CSCF capabilities that need to be supported by an S-CSCF in order to serve a user or a service (identified by a Public User Identity or Public Service Identity), that cannot be served by an S-CSCF which is only compliant to a previous 3GPP release.


- SIP-Number-Auth-Items AVP

type : Unsigned32

  • Request 메시지에 포함된 경우, S-CSCF가 요청하는 인증 벡터의 수
  • Response 메시지에 포함된 경우, HSS(UDM)에서 제공하는 SIP-Auth-Data-Item AVP의 실제 수(actual number)
접기/펼치기 6.3.8 SIP-Number-Auth-Items AVP
The SIP-Number-Auth-Items AVP is of type Unsigned32.
When used in a request, the SIP-Number-Auth-Items indicates the number of authentication vectors the S-CSCF is requesting. This can be used, for instance, when the client is requesting several pre-calculated authentication vectors. In the answer message, the SIP-Number-Auth-Items AVP indicates the actual number of SIP-Auth-Data-Item AVPs provided by the Diameter server.


- SIP-Authenticate AVP

type : OctecString

authentication challenge RAND와 token AUTN가 binary encoded 되어 연결된 값이 포함된다.

인증 정보의 고정 길이는 32 octets (RAND 16 octets + AUTN 16 octets)

(RAND와 AUTN에 대한 정보는 3GPP TS 33.203 참고)

접기/펼치기 6.3.10 SIP-Authenticate AVP
The SIP-Authenticate AVP is of type OctetString and contains specific parts of the data portion of the WWW-Authenticate or Proxy-Authenticate SIP headers that are to be present in a SIP response.
It shall contain, binary encoded, the concatenation of the authentication challenge RAND and the token AUTN. See 3GPP TS 33.203 [3] for further details about RAND and AUTN. The Authentication Information has a fixed length of 32 octets; the 16 most significant octets shall contain the RAND, the 16 least significant octets shall contain the AUTN.


- SIP-Authorization AVP

type : OctetString

  • Authentication Request 메시지에 포함된 경우, RAND(16 octets) 와 AUTS(14 octets)가 binary encoded 되어 연결된 값이 포함된다. 그래서 인증 정보는 30 octets의 고정 길이를 가진다.
  • Authentication Request Response 메시지에 포함된 경우, 예상 응답 XRES가 binary encoded된 값이 포함된다.
접기/펼치기 6.3.11 SIP-Authorization AVP
The SIP-Authorization AVP is of type OctetString and contains specific parts of the data portion of the Authorization or Proxy-Authorization SIP headers suitable for inclusion in a SIP request.
When included in an Authentication Request, it shall contain the concatenation of RAND, as sent to the terminal, and AUTS, as received from the terminal. RAND and AUTS shall both be binary encoded. See 3GPP TS 33.203 [3] for further details about RAND and AUTS. The Authorization Information has a fixed length of 30 octets; the 16 most significant octets shall contain the RAND, the 14 least significant octets shall contain the AUTS.
When included in an Authentication Request Response, it shall contain, binary encoded, the expected response XRES. See 3GPP TS 33.203 [3] for further details about XRES.


참고 자료

Radio, IMS
radio ims cx
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.
최근 업데이트
바로가기

[Markdown] 마크다운에서 접기/펼치기(details) 사용하기

[3GPP] UE ID 정의 및 종류(PLMN, IMSI, GUTI, SUPI/SUCI)