29.500 - Technical Realization of Service Based Architecture

sesame·2023년 4월 10일

규격

목록 보기

5/8

3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
5G System;
Technical Realization of Service Based Architecture;
Stage 3

5G Core Network의 SBA 기술 구현, SBI를 통해 지원되는 프로토콜 및 기능 설명

3GPP는 모바일 통신 네트워크에 대한 표준을 개발하고 유지하기 위해 여러 통신 표준 조직 간의 협력

3GPP 29.500
이 문서에서는 5GC 서비스 기반 아키텍처의 기술적 구현, service based interface를 통해 지원되는 프로토콜 및 서비스 기반 아키텍처에서 지원되는 기능에 대해 설명

3. Definitions and abbreviations

23.501 - 6.3.1.0
1) NRF는 SCP와 함께 배치될 수 있음
요청된 NF type 또는 NF service를 NRF를 통해 검색하려면 NF instance를 NRF에 등록해야 함

2) HSS 또는 UDM의 위임된 검색을 위해 SCP는 NRF에 의존하여 제공된 사용자 ID를 제공하는 HSS/UDM 인스턴스 그룹을 검색할 수 있음
일부 배포에서는 SCP가 먼저 제공된 사용자 ID에 대한 UDR을 쿼리할 수 있음
3단계에서는 서비스 소비자가 SCP 동작을 인식할 필요가 없도록 서비스 소비자가 제공하는 사용자 ID에 대해 단일 인코딩을 정의할 것으로 예상됨

3) 유효 기간 사용에 대한 자세한 내용은 29.510 참조

4) 주어진 PLMN에서는 직접 통신, 간접 통신 또는 둘 다 적용될 수 있음

5) 대상 PLMN ID 관련 쿼리를 사용하여 원격 PLMN의 NRF에 도달하는 방법에 대한 자세한 내용은 29.510참조

Binding Indication(consumer)
- NF 서비스 소비자는 바인딩을 사용하여 특정 알림 가입과 관련된 후속 알림 요청의 알림 대상 인스턴스 선택, 재선택 및 라우팅에 적합한 NF 서비스 소비자 인스턴스를 나타낼 수 있음
- 바인딩 표시는 NF 서비스 생산자가 저장해야 함
- NF 서비스 소비자가 NF 서비스 생산자 역할을 시작하는 경우 나중에 바인딩 표시를 사용하여 서비스 요청을 이 NF 서비스 생산자에게 보낼 수 있음
Binding Indication(producer)
- 바인딩을 사용하여 특정 NF 서비스 생산자 리소스 및 NF 서비스와 관련된 후속 요청의 NF 서비스 인스턴스 선택, 재선택 및 라우팅에 적합한 대상 NF 서비스 생산자 인스턴스를 나타낼 수 있음
- 바인딩을 사용하면 NF 서비스 생산자가 특정 컨텍스트를 NF 서비스 인스턴스, NF 인스턴스, NF 서비스 세트 또는 NF 세트에 바인딩해야 하는지 여부를 NF 소비자에게 알릴 수 있음
  바인딩 표시는 NF 서비스 소비자가 저장해야 함
Binding entity
NF service instance, NF service set, NF instance, NF set 중 하나의 식별자
Binding entity ID
Binding entity의 ID(ex: NF service instance ID, NF service set ID, NF service set ID, NF instance ID, NF set ID)
Binding level
http 사용자 지정 헤더의 매개변수로, 기본 바인딩이 존재하는 바인딩 엔티티를 나타냄
이러한 헤더에 있는 바인딩 레벨에 해당하지 않는 다른 바인딩 엔티티는 다시 선택할 수 있고 동일한 리소스 컨텍스트를 공유하는 대체 바인딩 엔티티를 나타냄
Callback URI
NF service 생산자가 알림 또는 콜백 요청을 보내는데 사용하는 URI
Endpoint address
- 대상 URI의 호스트/권한 부분을 결정하는데 사용되는 IP address,
- 전송 및 포트 정보 또는 FQDN 형식의 주소
- 이 대상 URI는 NF service 생산자의 NF service(즉, 서비스 작업 호출)에 액세스하거나 NF 서비스 소비자에게 알림을 보내는데 사용됨
- 23.501 - 3.1, 6.3.1.0
NF Instance
- NF의 식별 가능한 인스턴스
- 하나 이상의 NF 서비스 인스턴스에서 제공하는 서비스를 제공 가능
NF Service Instance
- NF의 식별 가능한 인스턴스
NF Service Set
- NF 인스턴스 내에서 동일한 서비스 유형의 교환 가능한 NF 서비스 인스턴스 그룹
동일한 NF 서비스 집합의 NF 서비스 인스턴스는 동일한 컨텍스트 데이터에 액세스 가능
NF Set
- 동일한 서비스 및 동일한 네트워크 슬라이스를 지원하는 동일한 유형의 상호 교환가능한 NF 인스턴스 그룹
- 동일한 NF 세트의 NF 인스턴스는 지리적으로 분산되어있지만 동일한 컨텍스트 데이터에 액세스할 수 있음
Notification endpoint
- 알림이 전송되는 네트워크 엔티티의 대상 URI
Routing binding indication
- 요청 또는 통지에 포함되며 SCP가 적합한 대상의 검색 및 관련 선택에 사용할 수 있는 정보
- HTTP 요청을 HTTP 요청을 처리할 수 있는 HTTP 서버로 라우팅 할 수 있는 정보를 수신기(SCP)에 제공

4. Service Based Architecture Overview

Service Framework

Service Framework 기능에는 서비스 등록/등록 취소, 소비자 인증, 서비스 검색 및 서비스 간 통신이 포함되며, 여기에는 선택 및 메시지 전달이 포함됨
NF service는 NF가 service based interface를 통해 다른 공인 NF에 노출하는 기능 유형 중 하나
NF 서비스 지정 기준

end to end 기능을 설명하는 시스템 절차에서 파생됨

서비스는 또한 다른 3GPP 사양의 정보 흐름을 기반으로 정의
NF service는 NF service 소비자와 NF service 생산자 간에

4.1. NF Services

3GPP TS 23.501에서는 5G 시스템 아키텍처 : 서비스 기반 아키텍처로 정의
→ 시스템 기능이 다른 인가된 NF에 서비스를 제공하여 그들의 서비스에 액세스하는 NF set에 의해 달성되는 시스템 아키텍처
5G 시스템 아키텍처의 Control Plane(CP) Network Function은 서비스 기반 아키텍처를 기반함
NF 서비스는 NF(NF Service Producer)가 서비스 기반 인터페이스를 통해 다른 공인 NF(NF Service Consumer)에 노출하는 기능 유형 중 하나
NF 서비스는 하나 이상의 NF 서비스 작업을 지원할 수 있음
Network Function은 서로 다른 기능을 제공할 수 있으므로 서로 다른 NF 서비스를 제공할 수 있음
Network Function에 의해 제공되는 각 NF 서비스는 동일한 네트워크 기능에 의해 제공되는 다른 NF 서비스(scaling, healing)와는 독립적으로 자체적으로 포함, 조치 및 관리되어야 함

4.2 Service Based Interfaces

서비스 기반 인터페이스는 특정 NF에 의해 서비스 집합이 제공되거나 노출되는 방식을 나타냄
NF 서비스 작업이 호출되는 인터페이스

4.3. NF Service Framework

4.3.1. General

서비스 기반 아키텍처는 NF Service의 사용을 가능하게 하는 NF 서비스 프레임워크를 지원해야함

NF 서비스 프레임워크에는 다음과 같은 메커니즘이 포함됨:

NF service registration and de-registration
NRF가 사용 가능한 NF instance와 지원되는 서비스를 인식하도록 함
NF service discovery
NF service consumer가 예상되는 NF service를 제공하는 NF service producer instance를 검색할 수 있도록 함
NF service authorization
NF service consumer가 NF service producer가 제공하는 NF service에 액세스 할 수 있도록 승인
Inter service communication
NF service consumer와 NF service producer는 SCP를 통해 직간접적으로 통신할 수 있음
NF가 SCP를 통한 직접 통신 또는 간접 통신을 사용하는지 여부는 NF 구성을 기반함

SCP
서비스 통신 프록시

4.3.2. NF Service Advertisement URI

message body(ex: PUT, POST)와 함께 HTTP method를 사용하는
NF service producer의 서비스 작업을 호출할 때,
NF service consumer는 운영자 정책에 따라 서비스 작업 request에 'NF service advertisement URI'를 제공할 수 있음
NF service producer가 NF service consumer가 제공할 수 있는 NF 서비스 후속 절차에서 NF 서비스 소비자가 생산한 NF 서비스를 검색하기 위해 서비스 광고 URI를 저장하고 사용할 수 있음
서비스 request 요청에서 NF service advertisement URI를 수신하는 경우
NF service producer는 운영자 정책에 따라 후속 절차에서 NF service consumer가 생산한 NF service를 검색하기 위해 service advertisement URI를 저장하고 사용할 수 있음
NF service advertisement URI는 NRF에서 NF service producer에 의해 등록된 nfInstance 리소스를 식별함
NF service advertisement URI 예
{apiRoot}/nnrf-disc/nf-instances?nfInstanceId={nfInstanceId}

참고
NF service advertisement URI는 예를 들어 PLMN에 서로 다른 NRF가 배치된 경우에 사용할 수 있음
해당되는 경우 NF service advertisement URI는 HTTP message body로 전달되어야 함

5. Protocols Over Service Based Interfaces

5.1. Protocol Stack Overview

SBI Protocol Stack

서비스 기반 인터페이스는 application layer 직렬화 프로토콜로 JSON이 포함된 HTTP/2 protocol을 사용
전송계층(TCP ..)의 보안을 위해, 모든 3GPP NF는 TLS를 지원해야함
네트워크 보안이 다른 수단으로 제공되지 않는 경우 PLMN에서 TLS를 사용해야함

PLMN
공중육상이동망, 공중육상이동통신망
: 사업자의 네트워크 식별번호
해외로밍 서비스 이용 시, 선호하는 사업자의 식별번호를 등록하면 해당 이동통신 사업자의 네트워크로 접속

5.2. HTTP/2 Protocol

5.2.1. General

RFC7540

5.2.2. HTTP standard headers

5.2.2.1. General

SBI에서 지원되어야하는 HTTP 표준 헤더
- RFC 에 정의된 HTTP 표준 헤더는 NF에서 지원될 수 있음
- 이는 각각 식별된 header의 처리를 지원해야한다는 것을 의미

5.2.2.2. Mandatory to support HTTP standard headers

SBI에서 지원되는 HTTP request/response header
- 모든 HTTP request/response header가 Mandatory를 따라야하진 않음
- 이는 각각 식별된 header의 처리를 지원해야한다는 것을 의미

SBI (Server Based Interface)

5.2.3. HTTP custom headers

3GPP 서비스 기반 NF에 적용되는 사용자 지정 HTTP 헤더목록

5.2.4. HTTP error handling

RFC7540
- connection error, stream error
29.501 - 4.8
- NF 서비스의 API 호출에 대한 오류 대응 지침

5.2.5. HTTP server push

RFC7540

5.2.6. HTTP connection management

RFC7540
HTTP request/response 교환 메커니즘은 NF간에 연결되어야 함

5.2.7. HTTP status code

RFC7540
NF as HTTP Server
- HTTP 서버 역할을 하는 NF는 명시된 HTTP 방법에 따라 명시된 HTTP 상태 코드를 생성할 수 있어야 함
- 3xx/4xx/5xx
  - 정의되지 않은 경우
    - client → 400 Bad Request
    - server → 500 Server Internal Error
NF as HTTP Client
- HTTP 클라이언트의 역할을 하는 NF는 수신된 HTTP 상태 코드가 정의된 해당 IETF RFC의 클라이언트 동작에 따라 처리해야 함
- 수신된 HTTP response message에 알 수 없는 IE가 포함된 경우, NF는 이러한 IE 폐기 가능
- 1xx/3xx/4xx/5xx
  - 정의되지 않은 경우
    - 1xx ( Informational )
    - 응답 취소하고 최종 응답 기다림
    - 2xx ( Successful )
      - 후속 절차에서 응답 페이로드에서 필수 정보가 예상되지 않는 경우 서비스 작업이 성공적이라고 간주함
      - 그렇지 않으면 오류로 간주
    - 3xx ( Redirection )
      - 동일한 요청 방법을 사용하여 location header에 참조된 directed resource에 대한 요청을 다시 시도
    - 4xx ( Client Error )
      - 다시 보내기 전에 request message의 유효성을 확인하고 수정 or 프로세스 중지 후 오류 절차
    - 5xx ( Server Error )
      - 프로세스 중지하고 오류 처리
SCP/SEPP
- SCP/SEPP는 HTTP 상태 코드를 HTTP 서버에서 HTTP 클라이언트로 전달
- 가장 유사한 3xx/4xx/5xx HTTP 상태 코드에 매핑 가능
  - 정의되지 않은 경우
    - client → 400 Bad Request
    - server → 500 Server Internal Error

5.2.8. HTTP request retries

모든 NF 서비스는 SBI에 API를 노출하고 API는 리소스에서 작동
HTTP method를 통해 API를 호출하면 요청 유형에 따라 리소스 상태가 변경될 수 도 있음

HTTP/2 client 요청 지연 발생시 서버에서 처리되지 않았음을 보장 x
HTTP/2 client는 재시도 요청 가능
HTTP/2 client로 동작하는 NF 요청이 처리되지 않은 경우(GOAWAY frame의 last-stream-id 보다 큰 경우), 비등재 요청을 재시도
재시도 횟수는 제한됨

5.2.9. Handling of unsupported query parameters

API에 대해 달리 명시되지 않는한 하나 이상의 지원되지 않는 쿼리 매개 변수를 가진 HTTP 요청을 수신하는 NF 서비스 producer는 다음을 수행:

안전한 HTTP method
- 지원되지 않는 쿼리 매개 변수를 무시, 요청의 나머지 부분을 기준으로 request에 response
안전하지않은 HTTP method
- 원인 특성이 INVALID_QUERY_PARAM으로 설정됨
- 지원되지 않는 쿼리 매개 변수를 나타내는 잘못된 Params
  - HTTP 응답에 대해 지정된 대로 설정된 NF 서비스 생산자가 지원하는 기능을 나열하는 supportedFeatures 특성

5.2.10. URL Encoding of data

RFC3986

5.3. Transport Protocol

RFC793 ( RFC7540 )

NF가 NRF에 포트 번호를 등록하지 않는 경우
- 기본 포트 번호
  - http :80
  - https :443

5.4. Serialization Protocol

RFC8259

5.5. Interface Definition Language

Open API 규격은 SBI의 인터페이스 정의 언어(IDL)로 사용되어야 함

6. General Functionalities in Service Based Architecture

6.1. Routing Mechanisms

6.1.1. General

이 절은 5GC의 일반 라우팅 메커니즘을 지정
→ 간접 통신(Indirect Communication)을 지원하기 위한 구체적인 요구 사항은 6.10

Inbound (RFC7230)
HTTP를 사용하면 중개자를 사용하여 연결 체인을 통해 요청을 충족할 수 있음
HTTP intermediary: proxy, gateway, and tunnel.

user agenet와 original server 사이의 세가지 중개자 (A,B,C)
전체 체인을 이동하는 요청 똔느 응답 메시지는 4개의 개별 연결을 통과
일부 HTTP 통신 옵션은 가장 가까운 터널이 아닌 이웃과의 연결, 체인의 끝점에만 적용되거나, 체인을 따라 모든 연결에 적용될 수 있음
다이어그램은 선형이지만 각 참가자는 여러 동시 통신에 참여할 수 있음
예)
B는 A 이외의 많은 클라이언트로 부터 요청을 수신하거나 A의 요청을 처리하는 동시에 c가 아닌 서버로 요청을 전달할 수 있음

메시지 흐름과 관련된 방향성 요구사항 설명시: 업스트림, 다운스트림
→ 모든 메시지는 업스트림에서 다운스트림으로 흐름

요청 경로와 관련된 방향성 요구사항 설명시: 인바운드, 아웃바운드
→ 인바운드: original server, 아웃바운드: agent

proxy: 특정 유형의 절대 URI에 대한 요청을 수신하고 HTTP 인터페이스를 통한 변환을 통해 해당 요청을 충족하려고 시도하기 위해 일반적으로 로컬 구성 규칙을 통해 클라이언트가 선택한 메시지 전달 에이전트
일부 변환은 'http' URI에 대한 프록시 요청과 같이 최소 수준이 ㄴ반면 다른 요청은 완전히 다른 애플리케이션 수준 프로토콜과의 변환이 필요할 수 있음

gateway (reverse proxy)
아웃바운즈 연결을 위한 원본 서버 역할을 하지만 수신된 요청을 변환하여 다른 서버로 인바운드로 전달하는 중개자
게이트 웨이 레거시 또는 신뢰할 수 없는 정보 서비스를 캡슐화하고, 가속시 캐싱을 통해 서버 성능을 개선하고, 여러 시스템에서 HTTP 서비스의 분할 또는 부하 분산을 활성화하는데 자주 사용됨

interception proxy(transparent proxy)
클라이언트가 선택하지 않기 때문에 HTTP 프록시와 다름
대신 차단 프록시가 나가는 TCP 포트 80패킷을 필터링하거나 리디렉션
가로채기 프록시는 일반적으로 공용 네트워크 액세스 포인트에서 찾아볼 수 있음

6.1.2. Identigying a target resource

target resource는 target URI로 식별됨
- 3gpp TS 29.501 4.4

6.1.3. Connecting inbound

request가 local cache에 충족되지 않는 경우, client는 target resource에 대한 권한 server 또는 proxy에 연결해야함
- proxy가 target URI에 적용 가능한 경우, client는 RFC7230에 정의된 대로 해당 proxy에 대한 연결을 설정(또는 재사용)하여 인바운드에 연결
  - 동일한 PLMN이 없는 기관에 인바운드를 연결하는 경우 client는 Security Edge Protection Proxy에 연결
- 적용 가능한 proxy가 없는 경우, client는 RFC7230에 정의된 대로 target resource에 대한 권한 server에 직접 연결

6.1.4. Pseudo-header setting

6.1.4.1. General

inbound 연결이 되면 client는 유선을 통해 request message를 보냄
message는 요청 대상을 식별하는 pseudo-header-field가 포함된 HEADLES frame으로 시작
:method 항상 존재

[ origin server 또는 proxy에 직접 request 전송 시 포함 pseudo-header ]

CONNECT request
- :authority
server-wide OPTIONS request
- :scheme
- :authority
- :path
else
- :scheme
- :authority
- :path

6.1.4.2. Routing within a PLMN

General

target URI 구성 요소가 client와 동일한 PLMN에 있는
origin server를 지정하는 HTTP/2 request message의 경우

":authority" = uri-host [":" port]

여기서 uri-host

target NF service의 FQDN
target NF service의 IP address

target NF service의 FQDN에 PLMN 식별자가 포함될 필요는 없음

6.1.4.3. Routing across PLMN

6.1.4.3.1 General

올바른 PLMN에서 올바른 target NF service에 도달하고
target URI 기관 구성 요소가 client와 동일한 PLMN에 없는
origin server를 지정하는 HTTP/2 request message의 경우

":authority" = uri-host [":" port]

:authority HTTP/2 pseudo-header는 PLMN ID를 포함하는 FQDN을 포함해야 함

여기서 uri-host

target NF service의 FQDN, callback URI 또는 지정된 링크 관계의 FQDN(권한) 부분에는 PLMN 식별자 포함
target NF service의 FQDN 형식은 3GPP TS 23.003 - 28.5

PLMN 내에서 SEPP와 Network Function 기능 간의 TLS 보호를 허용하기 위해 SEPP는 다음을 지원해야함:

도메인 이름과 telescopic FQDN 생성을 위한 TLS 와일드 카드 인증서 - 3GPP TS 33.501 - 13.1, 6.1.4.3.2
3gpp-Sbi-Target-apiRoot header를 사용하여 SEPP의 PLMN 내의 NF에 의해 발생한 HTTP request를 원격 PLMN으로 전달 - 6.1.4.3.3

6.1.4.3.2 Use of telescopic FQDN between NFs and SEPP within a PLMN

SEPP의 PLMN 내에서 SEPP와 NF 간에 TLS 와일드 카드 인증서와
telescopic FQDN을 사용할 때,
HTTP/2 client 측의 SEPP는 다음과 같은 경우에 대해 3GPP TS 23.003에 명시된 telescopic FQDN을 형성해야 함

HPLMN에서 target NF service의 FQDN은 VPLMN에서 SEPP에 의해 telescopic FQDN으로 수정됨
VPLMN에서 target NF service의 FQDN은 HPLMN에서 SEPP에 의해 telescopic FQDN으로 수정됨
VPLMN의 NF 서비스 리소스 콜백 URI의 FQDN(authority) 부분은 HPLMN의 SEPP에 의해 망원 FQDN으로 수정됨
HPLMN에서 NF 서비스 리소스의 콜백 URI 중 FQDN(authority) 부분은 VPLMN에서 SEPP에 의해 망원 FQDN으로 수정됨
VPLMN에서 NF 서비스 리소스의 링크 관계 URI 중 FQDN(authority) 부분은 HPLMN에서 SEPP에 의해 텔레스코픽 FQDN으로 수정됨
HPLMN에서 NF 서비스 리소스의 링크 관계 URI 중 FQDN(authority) 부분은 VPLMN에서 SEPP에 의해 텔레스코픽 FQDN으로 수정됨

6.1.4.3.3 Use of 3gpp-Sbi-Target-apiRoot between NFs and SEPP within a PLMN

6.1.4.3.4 Routing between SEPPs

6.1.5 Host header

HTTP/2 request를 생성하는 client는 Host header field 대신에 ":authority" pseudo-header field를 사용

6.1.6 Message forwarding

HTTP/2 proxy는 ":authority" pseudo-header를 사용하여 request가 proxy cache에 의해 충족될 수 없는 경우

origin server 또는 다른 proxy에 inbound를 연결해야함
다른 header 및 payload content를 사용하여 origin server 또는 다른 proxy에 inbound를 연결할 수 있음

6.2. Server-Initiated Communication

6.2.1 General

NF 간의 양방향 통신 필요로함
방향당 하나씩 두개의 TCP 연결로 지원됨
- NF consumer가 NF producer의 Notification에 Subscribe할 때
  NF consumer는 HTTP client, NF producer는 HTTP server 역할
- NF producer가 NF consumer에게 Notification을 전달할 때
  NF producer는 HTTP client, NF consumer는 HTTP server 역할
Subscribe-Notify interaction은 NF consumer에게 "notification endpoint"와 "notification correlation ID"를 제공할 것을 요구 : callback URI라고도 불림
NF consumer와 NF producer간의 상호작용은 NF producer가 보낸 Notification 이전에 발생하지 않거나
다른 서비스 또는 API에서 상호작용을 통해 발생할 수 있음
이 경우 Notification은 "standalone notification"라고 하며 3GPP 29.501-5.3.7

6.2.2 Subscription on behalf of NF Service Consumer

NF consumer가 target NF에 직접 감지하고 보고할 수 있는 이벤트에 대해 intermediate NF에 가입하는 경우
(ex: NEF는 UDM을 통해 AMF의 위치 보고 이벤트에 가입하고 AMF는 NEF에 직접 보고함)

NF consumer는 "3gpp-Sbi-Consumer-Info" header를 Subscribe 생성 request에 포함하여 target NF에 지원되는 API 버전, 기능 및 승인된 인코딩을 나타낼 수 있음

target NF에 Subscribe하여 target NF가 NF consumer에게 직접 보고하도록 요구하는 경우

intermediate NF는
NF consumer와 intermediate NF가 지원하는 대상 NF에서
가장 높은 API 버전을 호출해야함
intermediate NF는
수신된 모든 "3gpp-Sbi-Consumer-Info" header를
target NF로 전송되는 Subscribe request에 포함해야 함

target NF가 이벤트 Subscribe 생성 header를 수신한 경우
target NF는 NF consumer에게 직접 전송되는 Notification에 대해 지원되는 기능 및 NF 서비스 소비자의 수락된 인코딩에 따라 request body를 생성해야 함

NF consumer는 "3gpp-Sbi-Consumer-Info" header에 다음 정보를 포함할 수 있음

intra-PLMN Notification을 수신하기 위한 콜백 루트를 포함하는 intraPlmnCallbackRoot 매개변수

inter-PLMN Notification을 수신하기 위한 콜백 루트를 포함하는 intraPlmnCallbackRoot 매개변수

"3gpp-Sbi-Consumer-Info" header에 포함한 Subscribe request를 수신하면
intermediate NF는 target NF가 VPLMN또는 HPLMN에 있는지 확인하고 NF consumer로부터 수신된 정보에 따라 콜백 URI의 콜백 루트를 조정해야함
//ex: NF consumer가 Subscribe request에 PLMN간 콜백 URI를 포함하는 경우

target NF가 HPLMN에 있는 경우
intermediate NF로 Subscribe request를 보내는 동안 제공된 intraPlmnCallbackRoot = Subscribe request의 콜백 URI 루트를 대체
target NF가 VPLMN에 있는 경우
intermediate NF는 Notification/Callback URI를 변경하지 않음

두 경우 모두 intermediate NF로 전송되는 구돋ㄱ 작성 요청에서 "3gpp-Sbi-Consumer-Info" header 전달해야함

target NF가 AMF인 경우
source AMF는 수신된 "3gpp-Sbi-Consumer-Info" header의 정보를 AMF로 전달
intraPlmnCallbackRoot 및 interPlmnCallbackRoot 매개 변수를 수신한 경우
taget AMF는 NF consumer의 PLMN을 결정하고 그에 따라 콜백 URI의 콜백 루트를 조정해야 함

6.2.3 Notification error handling

Notification request를 보내는 NF producer는 다음 response code 및 응용 프로그램 오류 중 하나를 수신하는 경우
Subscribe가 더 이상 유효하지 않다고 간주하고 Subscribe 종료

400 Bac Request "RESOURCE_CONTENT_NOT_FOUND"
응용 프로그램 오류 "SUB_SCRIBE_NOT_FOUND"
404 Not Found

6.3. Load Control

6.3.1 General

Load control을 통해 NF producer는 NRF를 통해 또는 NF consumer에게 직접 load information을 전달할 수 있음
load information은 NF producer의 리소스 작동 상태를 반영

load control을 통해 NF producer간에 로드 밸런싱을 개선하여 과부하를 방지할 수 있음
load control은 NF 서비스 생산자가 높은 부하를 보고하더라도 과부화 완화 조치를 트리거하지 않음

NOTE
load control은 3GPP TS 29.303 4A.2에서
노드 수준 load control에 대해 설명한 것과 유사한 원칙에 따라 사용될 수 있지만 NRF에서 얻은 후보 NF의 우선 순위 및 용량 매개변수를 사용할 수 있음

6.3.2 Load Control based load signalled via the NRF

NRF를 통해 전달되는 부하 제어 기반의 부하 신호

→ NRF 솔루션을 통해 신호된 부하를 기준으로 부하 제어의 세부사항을 지정

NRF에서

NF discovery 절차 동안
NRF는 NF 서비스 등록 또는 NF 서비스 업데이트 절차 중에 통지되는 NF 용량 정보와 함께
NF instance 또는 NF service instance 정보를 제공할 수 있음
NRF는 또한 NF discovery response에서
NF instance 또는 NF service instance의 load information을 제공할 수 있음

// TODO

6.3.3 Load Control based on LCI Header(LC-H)

LCI Header 기반 부하 제어

6.3.3.1 General

NOTE1
operator 정책에 따라 load control과 overload control은 네트워크에서 독립적으로 지원될 수 있음

NOTE2
LC-H 기능을 지원하는 NF 서비스 소비자는
NRF에서 타임스탬프 없이 로드 정보를 수신하고
NF 서비스 생산자로부터 LCI(타임스탬프 포함)를 수신할 수 있음
NF 서비스 소비자가 가장 최근의 로드 정보를 포함하는 항목을 결정하는 방법은 구현 문제

NOTE3
NF 서비스 소비자는
스코프가 SCP 또는 SEPP FQDN으로 설정된 LCI를
넥스트 홉 SCP 또는 SEPP에서만 수신할 수 있음

6.3.3.2 Conveyance of Load Control Information

LCI는 "3gpp-Sbi-Lci" HTTP header내에서 전달되어야 함

LCI header는 NF consumer에게 전송되는 신호 메시지 위에 업혀있어야함

NF producer, SCP, SEPP는 peer NF consumer가 해당 기능을 지원하는지 여부에 관계없이 "3gpp-Sbi-Lci" header를 전송해야 함
NF consumer가 해당기능 사용하지 않을 때는 무시함

6.3.3.3 Frequency of Conveyance

전송 빈도
sender가 LCI 전달하는 빈도는 구현에 따라 다름

LCI receiver의 처리 요구사항 고려할 때
sender는 receiver에 NF producer 선택 로직을 유용하게 개선하지 못하는 로드메트릭에서 모든 작은 변화를 통지하는 것을 자제해야 함
부하 메트릭의 큰변동만 통지

6.3.3.4 Load Control Information

6.3.3.4.1 General Description

NF producer는
response, notify/callback request에
하나 이상의 LCI 헤더 포함 가능

각 LCI에는 항상 timestamp, load metric, scope if LCI가 포함되어야 함

6.3.3.4.2 Load Control Timestamp

LCI가 생성된 시간
LCI receiver는 HTTP/2 multi stream, priority, flow control 등으로 인해 순서가 잘못된 LCI를 적절하게 대조하고, 새로 수신된 load control information이 이전에 동일한 범위로 수신된 load control information과 비교하여 변경되었는지 여부를 결정하는데 사용되어야 함

6.3.3.4.3 Load Metric

LCI 범위에 대한 현재 부하 레벨
LCI에 표시된 스코프가 NF Instance를 0~100범위 내의 백분율로 나타내야 함

6.3.3.4.4 Scope of LCI

6.3.3.4.4.1 Introduction

LCI 범위는 LCI의 적용 가능성

6.3.3.4.4.2 Scope of LCI signalled by NF Service Producer

6.3.3.4.4.2.1 Genral

NF 서비스 생산자가 신호를 보내는 LCI에 대해 지원되는 범위

6.3.3.4.4.2.2 Additional scope parameters for S-NSSAI/DNN based load control by SMF

// TODO

6.4. Overload Control

과부하 제어는
NF 서비스 소비자에게 서비스 요청 전송을 줄이라고 지시하거나
NF 서비스 소비자에게 알림 요청 전송을 줄이라고 요청함으로써
NF Producer, NF Consumer, SCP, SEPP가 수신 부하를 우아하게 감소시킬 수 있도록 함
NF consumer로 부터 과부하 제어를 적용하라는 지시를 받은 경우
NF producer는 과부하 범위에 따른 notification 또는 callback request에 대해서만 NF consumer 대상으로 신호 감소 수행

오버로드 제어는 일반적으로 오버로드가 발생했을 때 수신 트래픽을 트래픽 소스에 최대한 가깝게 차단하여 네트워크 내부에 문제가 확산되는 것을 방지하고 오버로드된 엔티티가 제공할 수 없는 신호 전달을 위해 네트워크 내 중간 엔티티의 리소스를 사용하지 않도록 하는 것을 목표로합니다.

과부하 제어는 HTTP response로 반환된 HTTP status code 또는 HTTP request 또는 response로 시그널링된 OCI(Overload Control Information)를 기반으로 수행될 수 있음

Status Code

HTTP status code를 기반으로 한 과부하 제어
NF producer는 과부하 상황이 발생하는 동안 수신된 request에 대한 응답으로 NF 서비스 소비자에게 다음 HTTP status code를 전송하여 잠재적 과부하 완화할 수 있음

503 Service Unavailable
429 Too Many Requests
NF 소비자에게 서버가 현재 수신된 트래픽 속도를 처리할 수 없으므로
NF 소비자에서 로컬로 이 트래픽의 일부를 조절하여 NF 서비스 생산자에게 전송되는 트래픽을 줄임
또는 오버로드되지 않는 대체 대상으로 전환함

307 Temporary Redirect

// NF consumer가 NF producer 정책에 따라 우선순위 트래픽(ex: MPS) 및 비상사태와 관련된 요청은 고객이 마지막으로 제한

클라언트가 사용 가능한 트래픽의 특정 부분을 제거해야 할 경우, 각 메시지의 결정된 우선순위에 따라 이를 수행해야함

6.4.3 Overload Control based on OCI Header

HTTP status code 기반 과부하 제어와 독립적

요구사항

NF producer/consumer는
수신 서비스 request의 수 > 수신 엔티티가 지원하는 최대 메시지 수 초과 시
과부하 상태 감지

NF producer/consumer는 구현 종속 과부하 임계값에 도달 시
과부하 제어 정보를 동종 업체(producer or consumer)에 전달해야함

과부하 발생하는 SCP/SEPP는 SCP/SEPP로 전송되는 신호 트래픽을 조정하기 위해 HTTP request 또는 response message에서 SCP FQDN/SEPP FQDN으로 설정된 scope로 OCI를 추가로 피

OLC-H 기능 지원하지 않는 경우 헤더는 수신기에 의해 무시됨

Frequency of Conveyance

보낸사람이 OCI를 전달하는 빈도는 구현에 따라 다름
주기적으로 OCI 전달 가능

Overload Control Information

NF 서비스 인스턴스, NF 서비스 세트 및/또는 NF 인스턴스에 대한 OCI를 보고합니다;
SMF(서비스) 인스턴스 또는 SMF(서비스) 세트 수준에서 특정 S-NSSAI/DNN에 대한 OCI 보고;
SMF(서비스) 인스턴스 또는 SMF(서비스) 세트의 서로 다른 S-NSSAI/DNN에 대한 OCI를 보고합니다.

Timestamp
OCI가 생성된 시간
OCI 수신기는 HTTP2 multi stream, priority, flow control 등으로 인해 순서가 잘못된 OCI 헤더를 적절히 대조하고 새로 수신된 OCI 이전에 동일한 범위로 수신된 OCI와 비교하여 변경되었는지 여부를 결정하는데 사용되어야함

새로 수신한 OCI timestamp가 이전에 수신한 OCI와 동일하거나 이전의 동일한 범위인 경우, 다음 수신기는 새로 수신된 OCI를 폐기하고 가장 최근의 timestamp값으로 이전에 수신된 OCI 값을 기반으로 과부하 제저 절차를 계속 적용해야함

Overload Reduction Metric
0~100
OCI 송신기가 수신기에 적용을 요청하는 트래픽 감소 비율

OCI 전송은 과부하 상태가 발생하고 있다는 신호를 보내며,
0이 아닐 떄 과부하(오버로드) 상태가 발생하고 있다는 신호를 보냄
메시지 OCI 헤더가 없다고 해서 과부하가 완료된것은 아님

Overload Control Period of Valildity
유효기간 매개변수는 타이머이며
이는 OCI 헤더에 의해 지정된 과부하 조건이 유효한 것으로 간주되는 시간을 나타냄
과부하 조건은 과부하 제어 유효 기간이 만료될 때까지 또는 동일한 범위에 대해 새로운 정보 세트를 가진 다른 OCI가 수신될 때까지 유효한 것으로 간주해야함

Scope of OCI

OCI가 적용되는 서비스 request 또는 Notification을 나타냄
OCI에 따라 처리를 요청하는 트래픽을 식별함

6.5. Support of Stateless NFs

6.5.2. Stateless AMFs

6.5.2.1. General

AMF는 UE 관련 정보를 UDSF에 저장함으로써 비저장이 될 수 있다
AMF 계획 제거 또는 AMF 자동 복구를 위한 절차는 3GPP TS 23.501

6.5.2.2. AMF as Service consumer

AMF는 NF 서비스 생산자에게 알림을 구독할 때 GUAMI와 콜백 URI를 제공해야 한다.
NF 서비스 생산자는 Nnrf_NFDiscovery 서비스를 사용하여 AMF를 발견할 수 있다. 서비스 이름이 제공된 경우 해당 서비스의 엔드포인트 주소를 사용해야 한다.
NF 서비스 생산자는 AMFStatusChange 서비스 동작을 사용하여 GUAMI 변경 사항을 구독할 수 있다.
AMF 변경 사항은 AMFStatusChange 알림, HTTP 오류 응답, 링크 장애, NRF의 알림을 통해 인지할 수 있다.
AMF 변경 사항을 인지하고 새 AMF를 모르는 경우, AMF 세트 내에서 선택해야 한다.
AMF 변경 사항을 인지하면 알림 URI의 권한 부분을 교체해야 한다.
AMF는 알림을 처리할 수 있도록 준비되어야 한다. 알림 URI 처리, 리디렉션 응답, 오류 응답 등이 있다.
NF 서비스 생산자는 세트 내의 모든 AMF로부터 리소스 업데이트를 받을 준비가 되어야 한다.
다른 AMF 세트로 이동하거나 알림 처리가 불가능한 AMF로 이동하는 경우, 새로운 AMF는 새 콜백 URI로 동료 NF를 업데이트해야 한다.

6.5.2.3. AMF as service producer

AMF가 백업 AMF에 대한 정보를 제공할 수 있음.
NF 서비스 소비자는 Nnrf_NFDiscovery 서비스를 사용하여 AMF를 찾을 수 있음.
NF 서비스 소비자는 AMFStatusChange 서비스를 사용하여 GUAMI 변경 사항을 구독할 수 있음.
NF 서비스 소비자는 AMF 변경 사항을 인식할 수 있음 (AMFStatusChange 알림, 오류 응답, 링크 장애, NRF 알림 등을 통해).
AMF 변경 시 새로운 AMF를 알지 못하는 경우, NF 서비스 소비자는 AMF 세트 내의 다른 AMF나 백업 AMF를 선택해야 함.
AMF 변경 시, NF 서비스 소비자는 새로운 AMF의 apiRoot로 교체된 URI를 사용해야 함.
각 AMF는 NF 서비스 소비자로부터의 리소스 업데이트를 처리할 수 있어야 함.
AMF로부터의 알림을 포함하는 서비스의 경우, NF 서비스 소비자는 세트 내의 모든 AMF로부터 알림을 수신할 수 있어야 함.

6.5.3. Stateless NFs(for any 5GC NF type)

NF는 자신의 컨텍스트를 비구조적 데이터로 User Data Storage Function(UDSF)에 저장함으로써 상태 없는 상태로 전환할 수 있습니다.
UDM, PCF, NEF와 같은 일부 NF는 User Data Repository(UDR)에 자체 구조화된 데이터를 저장할 수도 있습니다.
NF 인스턴스는 상태 없는 상태로 NF 인스턴스의 집합 내에 배치될 수 있습니다.
NF 서비스가 동일한 컨텍스트 데이터를 공유하는 경우, NF 서비스의 여러 인스턴스는 NF 서비스 세트로 그룹화될 수 있습니다.

consumer

NF 서비스 소비자는 NF 서비스 생산자로부터의 알림에 대해 바인딩 표시 및 Callback URI를 제공함으로써 알림을 다른 NF 서비스 소비자에게 보낼 수 있도록 합니다.
Nnrf_NFDiscovery 서비스를 사용하여 NF(서비스) 세트 내의 NF 서비스 소비자를 찾을 수 있습니다.
NF 서비스 생산자는 HTTP 요청 메시지, 오류 또는 NRF로부터의 알림을 통해 NF 서비스 소비자의 변경 사항을 알 수 있습니다.
변경 사항이 발생하면 NF 서비스 생산자는 사용 가능한 바인딩 정보를 기반으로 새로운 NF 서비스 소비자를 선택합니다.
Notification/Callback URI의 인증 부분을 새로운 NF 서비스 소비자 정보로 대체합니다.
새로운 NF 서비스 소비자가 알림을 지원하지 않는 경우, 새로운 알림 URI로 NF 서비스 생산자에게 업데이트를 제공합니다.
NF(서비스) 세트 내의 모든 NF 서비스 소비자는 자체 주소를 인증 부분으로 사용하여 알림을 처리하거나 위에서 알림된 알림 URI를 처리하거나 새로운 NF 서비스 소비자를 가리키는 HTTP 3xx 리디렉션 또는 다른 HTTP 오류로 응답하는 준비가 되어야 합니다.
NF 서비스 생산자는 NF(서비스) 세트 내의 모든 NF 서비스 소비자로부터 관련 서비스의 리소스 업데이트를 수신할 준비가 되어야 합니다.
알림/Callback 요청의 대상 NF 서비스 소비자가 사용 불가능한 경우, 라우팅 및 검색 정보를 기반으로 새로운 NF 서비스 소비자가 선택됩니다.

producer

NF 서비스 생산자는 서비스를 설정할 때 바인딩 정보를 제공합니다.
Nnrf_NFDiscovery 서비스를 사용하여 NF(서비스) 세트 내의 NF 서비스 생산자를 찾을 수 있습니다.
NF 서비스 소비자는 HTTP 요청 메시지, 오류 또는 NRF로부터의 알림을 통해 NF 서비스 생산자의 변경 사항을 알 수 있습니다.
변경 사항이 발생하면 NF 서비스 소비자는 사용 가능한 바인딩 정보를 기반으로 새로운 NF 서비스 생산자를 선택합니다.
리소스 URI의 apiRoot를 새로운 NF 서비스 생산자의 apiRoot로 대체합니다.
새로운 NF 서비스 생산자는 알림/Callback 요청에서 업데이트된 바인딩 표시를 포함시킬 수 있으며 새로운 리소스 URI를 생성할 수도 있습니다.
NF(서비스) 세트 내의 모든 NF 서비스 생산자는 자체 주소를 인증 부분으로 사용하여 업데이트와 알림을 수신할 준비가 되어야 합니다.
대상 NF 서비스 생산자가 사용 불가능한 경우, 라우팅 및 검색 정보를 기반으로 새로운 NF 서비스 생산자가 선택됩니다.

6.6. Extensibility Mecahisms

3GPP 5GC의 서비스 기반 아키텍처에서 지원되는 feature negotiation, vendor-specific extensions 등과 같은 확장성 메커니즘을 설명함

6.6.2. Feature negotiation

서로 다른 시스템 또는 구성 요소 간에 상호 작용할 때 지원되는 기능을 협상하는 과정을 의미함
feature negotiation은 client와 server간의 통신에서 지원되는 feature set을 결정하고 어떤 기능이 사용 가능한지를 확인하기 위해 사용됨

ex) client가 server에 요청을 보낼 때 지원할 수 있는 기능을 명시적으로 지정하고
server는 해당 기능을 확인하여 요청된 기능 중 어떤 것을 지원할 수 있는지 결정함
이를 통해 client와 server는 서로 다른 기능을 가진 시스템 간에 호환성을 유지하면서 상호 작용할 수 있음

소비자는 3gpp-Sbi-Consumer-Info 헤더를 사용하여 API 버전 및 지원되는 기능을 중간 NF 및 생산자에 표시할 수 있음
알 수 없는 특성 및 값은 무시하고 지원되지 않는 쿼리 매개변수는 지정된 대로 처리해야함

6.6.3. Vendor-specific extensions

6.6.4. Extensibility for Query paramters

6.7. Security Mecahnisms

6.8. SBI Message Priority Mechanism

6.9. Discovering the supported communication options

6.10. Support of Indirect Communication

6.11. Detection and handling of late arriving requests

6.12. Blinding between an NF Service Consumer and an NF Service Resource

6.13. SBI messages correlation for network troubleshooting

6.14. Indicating the purpose of Inter-PLMN signaling

sesame

이전 포스트

5GC

다음 포스트