4 Binding Support Management Service
29.5213GPP5G SystemBinding Support Management ServiceRelease 18Stage 3TS
4.1 Service Description
4.1.1 Overview
The Binding Support Management Service as defined in 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4], is provided by the Binding Support Function (BSF).
The Nbsf_Management service is used to provide:
– a PCF for a PDU session binding functionality, which ensures that an AF request for a certain PDU Session reaches the relevant PCF holding that PDU Session information, or ensures that the same PCF is selected for multiple PDU sessions.
– a PCF for an MBS session binding functionality, which ensures that for MBS location based services an AF request for a certain MBS Session reaches the relevant PCF holding that MBS Session information.
– a PCF for a UE binding functionality, which ensures that an AF request for Access and Mobility related Policy Authorization for a UE reaches the relevant PCF for a UE holding the AM Policy Association.
– Subscription to notification events about a newly registered or deregistered PCF for a UE or PCF for a PDU session.
This service:
– allows NF service consumers to register, update and remove binding information;
– allows NF service consumers to retrieve binding information;
– allows NF service consumers to subscribe to notifications of registration/deregistration events of newly registered or deregistered PCF for a UE or PCF for a PDU session.
4.1.2 Service Architecture
The 5G System Architecture is defined in 3GPP TS 23.501 [2]. The Policy and Charging related 5G architecture is also described in 3GPP TS 23.503 [4] and 3GPP TS 29.513 [5].
The Binding Support Management Service (Nbsf_Management) is exhibited by the Binding Support Function (BSF).
The known consumers of the Nbsf_Management service are:
– Policy Control Function (PCF)
– Network Exposure Function (NEF)
– Application Function (AF);
– Multicast/Broadcast Service Function (MBSF);
– Network Data Analytics Function (NWDAF); and
– Time Sensitivy Communication and Time Synchronization Function (TSCTSF).
As described in 3GPP TS 23.503 [4], the BSF is a function that can be deployed standalone or as a functionality provided by other network functions, such as PCF, UDR, NRF, SMF.
NOTE 1: The PCF accesses the Nbsf_Management service at the BSF via an internal interface when it is collocated with BSF.
NOTE 2: The DRA decides to select a BSF based on user IP address range when the DRA has no binding information for the subscriber to get the relevant PCF for a PDU session address. DRA and BSF coexistence is described in 3GPP TS 29.513 [5], Annex A.
Figure 4.1.2-1: Reference Architecture for the Nbsf_Management service; SBI representation
NOTE 3: The PCF in the figure represents both, the PCF for a UE and the PCF for a PDU session. The PCF for a UE and the PCF for a PDU session separately and independently register themselves at the BSF, regardless they are deployed in the same NF instance or separately in different NF instances.
4.1.3 Network Functions
4.1.3.1 Binding Support Function (BSF)
The BSF:
– stores the binding information for a certain PDU Session;
– stores the binding information for a certain MBS Session;
– stores the binding information for a certain UE;
– enables the subscription to notifications of PCF for a PDU session registration/deregistration events;
– enables the subscription to notifications of PCF for a UE registration/deregistration events;and
– enables the discovery of binding information (e.g. the address information of the selected PCF for a PDU session).
The BSF allows NF service consumers (e.g. PCF) to register, update and remove a binding information, and allows NF service consumers (e.g. AF, NEF, NWDAF) to discover a binding information (e.g. the address information of the selected PCF). The BSF also allows NF service consumers (e.g. PCF for a UE, AF, NEF) to subscribe to notifications of PCF registration/deregistration events.
The BSF can be deployed standalone or collocated with other network functions, such as PCF, UDR, NRF and SMF.
4.1.3.2 NF Service Consumers
The Policy Control Function (PCF):
– The PCF for a PDU session:
a. registers binding information in the BSF for a UE when an IPv4 address and/or IPv6 prefix is allocated, or a MAC address is used for the PDU session;
b. updates binding information in the BSF when a UE address information is changed for the PDU Session; and
c. removes binding information in the BSF when an IPv4 address and/or IPv6 prefix is released, or a MAC address is not used for the PDU Session.
– The PCF for a MBS session:
a. registers binding information in the BSF for an MBS session;
b. updates binding information in the BSF for the MBS session;
c. removes binding information in the BSF for the MBS session.
– The PCF for a UE:
a. registers binding information in the BSF for a UE when an AM Policy Association is established;
b. removes binding information in the BSF when the AM Policy Association is terminated; and
c. subscribes with the BSF to notification of registration/deregistration events of the PCF for a PDU session.
The Network Exposure Function (NEF):
– provides means for the Application Functions to securely interact with the Policy framework for policy control to 3GPP network. During the procedure, it needs to discover the selected PCF for a PDU session or the selected PCF for a UE by using the Nbsf_Management_Discovery service operation and the selected PCF for a UE by using the Nbsf_Management_Subscribe/Notify service operations.
The Application Function (AF):
– discovers the selected PCF for a PDU session or the selected PCF for a UE by using the Nbsf_Management_Discovery service operation and the selected PCF for a UE by using the Nbsf_Management_Subscribe/Notify service operations when it is allowed to interact directly with the policy framework for policy control.
The Network Data Analytics Function (NWDAF):
– discovers the selected PCF for a PDU session by using the Nbsf_Management_Discovery service operation.
The Time Sensitive Communication and Time Synchronization Function (TSCTSF)
– discovers the selected PCF for a PDU session by using the Nbsf_Management_Discovery service operation and the selected PCF for a UE by using Nbsf_Management_Subscribe/Notify service operations when it is allowed to interact with the policy framework for time sensitive communication and time synchronization control.
The Multicast/Broadcast Service Function (MBSF):
– discovers the selected PCF for an MBS session by using the Nbsf_Management_Discovery service operation.
4.2 Service Operations
4.2.1 Introduction
Table 4.2.1-1: Operations of the Nbsf_Management Service
|
Service operation name |
Description |
Initiated by |
|---|---|---|
|
Nbsf_Management_Register |
This service operation is used to register the binding information for a PDU session or an MBS session or a UE. |
NF service consumer (PCF) |
|
Nbsf_Management_Deregister |
This service operation is used to deregister the binding information for a PDU session or an MBS session or a UE. |
NF service consumer (PCF) |
|
Nbsf_Management_Discovery |
This service operation is used by an NF service consumer to discover a selected PCF for a PDU session or a selected PCF for an MBS session or a selected PCF for a UE. |
NF service consumer (e.g., NEF, AF, NWDAF, MBSF, TSCTSF) |
|
Nbsf_Management_Update |
This service operation is used to update an existing binding information for a PDU session or an MBS session or a UE. |
NF service consumer (PCF) |
|
Nbsf_Management_Subscribe |
This service operation is used by an NF service consumer to subscribe or to modify a subscription for event notifications of PCF for the UE or PCF for the PDU session binding related events. |
NF service consumer (NEF, AF, PCF, TSCTSF) |
|
Nbsf_Management_Unsubscribe |
This service operation is used by an NF service consumer to terminate a previous subscription. |
NF service consumer (NEF, AF, PCF, TSCTSF) |
|
Nbsf_Management_Notify |
This service operation is used by the BSF to notify binding related event(s) to the NF service consumer which has subscribed to such event(s). |
BSF |
4.2.2 Nbsf_Management_Register Service Operation
4.2.2.1 General
This service operation allows a NF service consumer (e.g. PCF for a PDU session) to register the session binding information for a UE in the BSF by providing the user identity, the DNN, the UE address(es) and the selected PCF address for a certain PDU Session to the BSF, and BSF stores the information.
If the BindingUpdate feature is not supported and the NF service consumer (e.g. PCF for a PDU session) receives a new UE address (e.g. IPv6 prefix) and has already registered session binding information for this PDU session, the NF service consumer (e.g. PCF for a PDU session) shall register a new session binding information in the BSF.
If the SamePcf feature or the ExtendedSamePcf feature is supported, this service operation allows the NF service consumer (e.g. PCF for a PDU session) to check whether PCF addressing information for Npcf_SMPolicyControl service is already registered in the BSF by another PCF for a combination of the UE ID, DNN and S-NSSAI parameters of the PDU session.
This service operation also allows a NF service consumer (e.g. PCF for a UE) to register PCF for a UE binding information for a UE in the BSF, by providing to the BSF the user identity and the selected PCF address for a certain UE, and the BSF stores the information.
In addition, this service operation may also be used by a NF service consumer (e.g. PCF managing an MBS session) to register the session binding information for an MBS Session at the BSF, by providing the MBS Session ID, the identifier of the selected PCF for the MBS Session and the related information (e.g. PCF (service) set information), and the BSF stores the information.
The following procedures using the Nbsf_Management_Registration service operation are supported:
– Register a new PCF for a PDU Session binding information.
– Register a new PCF for a UE binding information.
– Register a new PCF for an MBS Session binding information.
4.2.2.2 Register a new PCF for a PDU Session binding information
Figure 4.2.2.2-1: NF service consumer register a new PCF for a PDU Session binding information
The NF service consumer shall invoke the Nbsf_Management_Register service operation to register the PDU session binding information for a UE in the BSF. The NF service consumer shall send for this an HTTP POST request with "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings" as Resource URI representing the "PCF for a PDU Session Bindings", as shown in figure 4.2.2.2-1, step 1, to create a binding information for an "Individual PCF for a PDU Session Binding" according to the information (e.g. UE address(es), SUPI, GPSI, DNN, S-NSSAI) in the message body. When the "ExtendedSamePcf" feature is not supported, the "PcfBinding" data structure provided in the request body shall include:
– if the "MultiUeAddr" feature is not supported or not yet known, address information of the served UE consisting of:
(i) either IP address information consisting of:
+ the IPv4 address encoded as "ipv4Addr" attribute; and/or
+ the /128 IPv6 address, the IPv6 address prefix or an IPv6 prefix shorter than /64 encoded as "ipv6Prefix" attribute; or
(ii) the MAC address encoded as "macAddr48" attribute;
Otherwise, address information of the served UE consisting of:
(i) any IP address information consisting of:
+ the IPv4 address encoded as "ipv4Addr" attribute;
+ the /128 IPv6 address, the IPv6 address prefix or an IPv6 prefix shorter than /64 encoded as "ipv6Prefix" attribute; and/or
+ the additional /128 IPv6 addresses, the IPv6 address prefixes or IPv6 prefixes shorter than /64 encoded as "addIpv6Prefixes" attribute; or
(ii) the MAC address encoded as "macAddr48" attribute and/or the additional MAC addresses encoded as "addMacAddrs" attribute;
– PCF address information consisting of:
(i) if the PCF supports the Npcf_PolicyAuthorization service:
+ the FQDN of the PCF encoded as "pcfFqdn" attribute; and/or
+ a description of IP endpoints at the PCF hosting the Npcf_PolicyAuthorization service encoded as "pcfIpEndPoints" attribute; and
(ii) if the PCF supports the Rx interface:
+ the Diameter host id of the PCF encoded as "pcfDiamHost"; and
+ the Diameter realm of the PCF encoded as"pcfDiamRealm" attributes;
– DNN encoded as "dnn" attribute;
– S-NSSAI encoded as "snssai" attribute; and
– If the "SamePcf" feature defined in clause 5.8 is supported and the PCF determines based on operator policies that the same PCF shall be selected for the SM Policy associations:
(i) PCF address information for Npcf_SMPolicyControl service consisting of:
+ the FQDN of the PCF encoded as "pcfSmFqdn" attribute; or
+ a description of IP endpoints at the PCF hosting the Npcf_SMPolicyControl service encoded as "pcfSmIpEndPoints" attribute; and
(ii) the parameters combination for selecting the same PCF encoded within the "paraCom" attribute if the PCF registers the binding information for the indicated parameter combination for the first time.
NOTE 1: When the "SamePcf" feature is supported, the PCF omits the "paraCom" attribute when creates the corresponding binding information related to the subsequent PDU sessions for the same parameter combination.
and may include:
– SUPI encoded as "supi" attribute;
– GPSI encoded as "gpsi" attribute;
– IPv4 address domain encoded as "ipDomain" attribute; and
– framed routes consisting of:
(i) one or more framed routes within the "ipv4FrameRouteList" attribute for IPv4; and/or
(ii) one or more framed routes within the "ipv6FrameRouteList" attribute for IPv6.
When the "TimeSensitiveNetworking" feature or the "TimeSensitiveCommunication" feature is supported by the PCF as defined in clause 5.8 of 3GPP TS 29.512 [21], and for Ethernet type of PDU sessions, the address information of the served UE contains the MAC address of the DS-TT port encoded in the "macAddr48" attribute as received by the PCF when the SMF reports the bridge information of the detected TSC user plane node.
NOTE 2: For the integration with time sensitive communication networks using IP type of applications, the address information of the served UE contains the UE IP address of the corresponding PDU session.
When the "ExtendedSamePcf" feature is supported the address information of the served UE may be provided if available, i.e., the "ipv4Addr", the "ipv6Prefix" and/or "addIpv6Prefixes" attributes or the "macAddr48" and/or "addMacAddrs" attributes may be provided if available.
When the "ExtendedSamePcf" feature is supported the PCF address for the Npcf_PolicyAuthorization and/or Rx interface may be provided if available, i.e., the "pcfFqdn" and/or the "pcfIpEndPoints" attributes, and/or the "pcfDiamHost" and/or the "pcfDiamRealm" attributes may be provided if available.
NOTE 3: Before requesting the BSF to check if there is an existing PCF binding information for the same UE ID, S-NSSAI and DNN combination registered by other PCF(s), the PCF determines whether the BSF supports the "SamePcf" and/or "ExtendedSamePcf" features either via local configuration or by checking the BSF profile retrieved from the NRF as specified in 3GPP TS 29.510 [12].
Upon the reception of an HTTP POST request with: "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings" as Resource URI and "PcfBinding" data structure as request body, the BSF shall:
– create new binding information;
– assign a bindingId; and
– store the binding information.
The PCF as NF service consumer may provide PCF Id in "pcfId" attribute and recovery timestamp in "recoveryTime" attribute. The BSF may use the "pcfId" attribute to supervise the status of the PCF as described in clause 5.2 of 3GPP TS 29.510 [12] and perform necessary clean up upon status change of the PCF later, and/or both the "pcfId" attribute and the "recoveryTime" attribute in clean up procedure as described in clause 6.4 of 3GPP TS 23.527 [17].
The PCF as a NF service consumer may provide PCF Set Id within the "pcfSetId" attribute and "bindLevel" attribute set to NF_SET or provide PCF Set Id within the "pcfSetId" attribute, PCF instance Id within the "pcfId" attribute and "bindLevel" attribute set to NF_INSTANCE.
If the BSF created an "Individual PCF for a PDU Session Binding" resource, the BSF shall respond with "201 Created" status code with the message body containing a representation of the created binding information, as shown in figure 4.2.2.2-1, step 2. The BSF shall include a Location HTTP header field containing the URI of the created binding information, i.e. "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings/{bindingId}".
If errors occur when processing the HTTP POST request, the PCF shall apply error handling procedures as specified in clause 5.7.
If the "SamePcf" feature defined in clause 5.8 is supported and the "paraCom" attribute is included in the HTTP POST message, the BSF shall check the received "paraCom" attribute. If the BSF detects that there is an existing PCF binding information including the same "dnn", "snssai" and "supi" attribute values as each of the corresponding attribute values within the "paraCom" attribute, the BSF shall reject the request with an HTTP "403 Forbidden" status code and shall include in the response the "ExtProblemDetails" data structure including the FQDN of the existing PCF hosting the Npcf_SMPolicyControl service within the "pcfSmFqdn" attribute or the description of IP endpoints at the existing PCF hosting the Npcf_SMPolicyControl service within the "pcfSmIpEndPoints" attribute of "BindingResp" data structure, and the "cause" attribute of the "ProblemDetails" data structure set to "EXISTING_BINDING_INFO_FOUND".
4.2.2.3 Register a new PCF for a UE binding information
Figure 4.2.2.3-1: NF service consumer registers a new PCF for a UE binding information
The NF service consumer shall invoke the Nbsf_Management_Register service operation to register the PCF for a UE binding information in the BSF. The NF service consumer shall send for this an HTTP POST request with "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings" as Resource URI representing the "PCF for a UE Bindings", as shown in figure 4.2.2.3-1, step 1, to create a binding information for an "Individual PCF for a UE Binding" according to the information in the message body.
The "PcfForUeBinding" data structure included in the request message body shall include:
– SUPI encoded as "supi" attribute; and
– if the PCF supports the Npcf_AMPolicyAuthorization service, the Npcf_AMPolicyAuthorization service address information consisting of:
a. the FQDN of the PCF encoded as "pcfForUeFqdn" attribute; and/or
b. a description of IP endpoints at the PCF hosting the Npcf_AMPolicyAuthorization service encoded as "pcfForUeIpEndPoints" attribute;
NOTE: In this release of the specification the PCF for a UE registering the binding information in the BSF supports the Npcf_AMPolicyAuthorization service.
and may include:
– GPSI encoded as "gpsi" attribute;
– PCF instance Id in "pcfId" attribute;
– the PCF Set identifier in the "pcfSetId" attribute; and
– the binding level in the "bindLevel" attribute.
Upon the reception of an HTTP POST request with: "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings" as Resource URI and "PcfForUeBinding" data structure as request body, the BSF shall:
– create new binding information;
– assign a bindingId; and
– store the binding information.
The PCF as a NF service consumer may provide information about the PCF Set and the binding level of subsequent request to the same or different PCF instances for the Npcf_AMPolicyControl service. The PCF may provide the PCF Set Id within the "pcfSetId" attribute and "bindLevel" attribute set to NF_SET, or may provide the PCF Set Id within the "pcfSetId" attribute, PCF instance Id within the "pcfId" attribute and "bindLevel" attribute set to NF_INSTANCE.
If the BSF created an "Individual PCF for a UE Binding" resource, the BSF shall respond with "201 Created" status code with the message body containing a representation of the created binding information, as shown in figure 4.2.2.3-1, step 2. The BSF shall include a Location HTTP header field containing the URI of the created binding information, i.e. "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings/{bindingId}".
If errors occur when processing the HTTP POST request, the PCF shall apply error handling procedures as specified in clause 5.7.
4.2.2.4 Register a new PCF for an MBS Session binding information
Figure 4.2.2.4-1: PCF for an MBS Session Binding information Registration procedure
1. The NF service consumer (e.g. PCF handling the MBS Session) shall invoke the Nbsf_Management_Register service operation to register a new PCF for the handling of location dependent MBS Sessions for an MBS Session binding at the BSF. The NF service consumer shall send for this purpose an HTTP POST request targeting the "PCF for an MBS Session Bindings" resource URI, i.e. "{apiRoot}/nbsf-management/<apiVersion>/pcf-mbs-bindings", with the request body containing the PcfMbsBinding data structure that shall include:
– the identifier of the MBS Session to which the MBS Session binding is related, within the "mbsSessionId" attribute;
– the FQDN of the PCF handling the MBS Session, if available, within the "pcfFqdn" attribute; and
– the IP end points of the PCF handling the MBS Session, if available, within the "pcfIpEndPoints" attribute;
and may include:
– the identifier of the PCF instance handling the concerned MBS Session, within the "pcfId" attribute;
– the identifier of the PCF set to which the PCF instance handling the concerned MBS Session belongs, within the "pcfSetId" attribute;
– the level of binding of the PCF handling the concerned MBS Session, within the "bindLevel" attribute;
– the recovery timestamp of the NF service consumer (e.g. PCF handling the MBS Session), within the "recoveryTime" attribute; and
– the list of supported features, within the "suppFeat" attribute.
If the NF service consumer (e.g. PCF handling the MBS Session) provides the PCF instance ID within the "pcfId" attribute, and optionally the recovery timestamp within "recoveryTime" attribute, the BSF may use this information to carry out the clean-up procedures defined in clause 6.4 of 3GPP TS 23.527 [17], if necessary.
2. Upon successful processing of the received HTTP POST request, the BSF shall check if there is an existing MBS Session Binding information with the same "mbsSessionId" attribute value. If it is so, the the BSF shall reject the request with an HTTP "403 Forbidden" status code and shall include in the response the "MbsExtProblemDetails" data structure including the FQDN of the existing PCF within the "pcfFqdn" attribute or the description of IP endpoints at the existing PCF within the "pcfIpEndPoints" attribute of "MbsBindingResp" data structure, and the "cause" attribute of the "ProblemDetails" data structure set to "EXISTING_BINDING_INFO_FOUND".
If there is not existing MBS Session Binding information for the provided "mbsSessionId" attribute, the BSF shall create a new "Individual PCF for an MBS Session Binding" resource to store the requested PCF for an MBS Session binding. The BSF shall then respond to the NF service consumer with an HTTP "201 Created" status code including an HTTP Location header field containing the URI of the created "Individual PCF for an MBS Session Binding" resource, and the response body containing a representation of the created resource within the PcfMbsBinding data structure.
If errors occur when processing the HTTP POST request, the BSF shall apply the error handling procedures specified in clause 5.7.
4.2.3 Nbsf_Management_Deregister Service Operation
4.2.3.1 General
This service operation allows the NF service consumer to delete existing PCF for a PDU session binding information for a UE at the BSF. It is executed by deleting the corresponding "Individual PCF for a PDU Session Binding" resource. The operation is invoked by issuing an HTTP DELETE request targeting the resource URI representing the specific PCF for a PDU session binding information that is to be deleted.
This service operation also allows the NF service consumer to delete existing PCF for a UE binding information for a UE at the BSF. It is executed by deleting the corresponding "Individual PCF for a UE Binding" resource. The operation is invoked by issuing an HTTP DELETE request targeting the resource URI representing the specific PCF for a UE binding information that is to be deleted.
This service operation also allows the NF service consumer to delete existing PCF for an MBS Session binding information for an MBS Session at the BSF. It is executed by deleting the corresponding "Individual PCF for an MBS Session Binding" resource. The operation is invoked by issuing an HTTP DELETE request targeting the resource URI representing the specific PCF for an MBS Session binding information that is to be deleted.
The following procedures using the Nbsf_Management_Deregistration service operation are supported:
– Deregister an individual PCF for a PDU Session binding information.
– Deregister an individual PCF for a UE binding information.
– Deregister an individual PCF for an MBS Session binding information.
4.2.3.2 Deregister an individual PCF for a PDU Session binding information
Figure 4.2.3.2-1: PCF for a PDU Session Binding Information Deregistration
The NF service consumer shall invoke the Nbsf_Management_Deregister service operation to deregister the PCF for a PDU session binding information for a UE in the BSF. The NF service consumer shall send an HTTP DELETE request with "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings/{bindingId}" as Resource URI, where "{bindingId}" is the "Individual PCF for a PDU Session Binding" resource identifier that is to be deleted, as shown in figure 4.2.3.2-1, step 1.
Upon the reception of an HTTP DELETE request with: "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings/{bindingId}" as Resource URI, the BSF shall:
– remove the corresponding binding information.
If the HTTP DELETE request message from the NF service consumer is accepted, the BSF shall respond with "204 No Content" status code, as shown in figure 4.2.3.2-1, step 2.
If errors occur when processing the HTTP DELETE request, the BSF shall send an HTTP error response as specified in clause 5.7.
If the Individual PCF for a PDU Session Binding resource does not exist, the BSF shall respond with "404 Not Found" error code.
If the feature "ES3XX" is supported, and the BSF determines the received HTTP DELETE request needs to be redirected, the BSF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [6].
4.2.3.3 Deregister an individual PCF for a UE binding information
Figure 4.2.3.3-1: PCF for a UE Binding Information Deregistration
The NF service consumer shall invoke the Nbsf_Management_Deregister service operation to deregister the session binding information for a UE in the BSF. The NF service consumer shall send an HTTP DELETE request with "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings/{bindingId}" as Resource URI, where "{bindingId}" is the "Individual PCF for a UE Binding" resource identifier that is to be deleted, as shown in figure 4.2.3.3-1, step 1.
Upon the reception of an HTTP DELETE request with: "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings/{bindingId}" as Resource URI, the BSF shall:
– remove the corresponding binding information.
If the HTTP DELETE request message from the NF service consumer is accepted, the BSF shall respond with "204 No Content" status code, as shown in figure 4.2.3.3-1, step 2.
If errors occur when processing the HTTP DELETE request, the BSF shall send an HTTP error response as specified in clause 5.7.
If the Individual PCF for a UE Binding resource does not exist, the BSF shall respond with "404 Not Found" error code.
If the BSF determines the received HTTP DELETE request needs to be redirected, the BSF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [6].
4.2.3.4 Deregister an individual PCF for an MBS Session binding information
Figure 4.2.3.4-1: PCF for an MBS Session Binding information Deregistration procedure
1. The NF service consumer shall invoke the Nbsf_Management_Deregister service operation to deregister an existing PCF for an MBS Session Binding at the BSF. The NF service consumer shall send for this purpose an HTTP DELETE request targeting the URI of the concerned "Individual PCF for an MBS Session Binding" resource, i.e. "{apiRoot}/nbsf-management/<apiVersion>/pcf-mbs-bindings/{bindingId}".
2. Upon success, the BSF shall delete the concerned "Individual PCF for an MBS Session Binding" resource and respond to the NF service consumer with an HTTP "204 No Content" status code.
If errors occur when processing the HTTP DELETE request, the BSF shall apply the error handling procedures specified in subclause 5.7.
4.2.4 Nbsf_Management_Discovery Service Operation
4.2.4.1 General
This service operation allows the service consumer to use the HTTP GET method to obtain the address information of the selected PCF.
– Retrieve the PCF binding information for a PDU session.
– Retrieve the PCF binding information for a UE.
– Retrieve the PCF binding information for an MBS Session.
4.2.4.2 Retrieve the PCF binding information for a PDU session
Figure 4.2.4.2-1: NF service consumer retrieve the PCF binding information for a PDU session
The NF service consumer shall invoke the Nbsf_Management_Discovery service operation to obtain address information of the selected PCF for a PDU session in the BSF. The NF service consumer shall send an HTTP GET request with "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings" as Resource URI, and "query parameters" that shall include:
– UE address;
and may include:
– SUPI or GPSI;
– DNN and optionally S-NSSAI; and
– IPv4 address domain.
NOTE: The query parameters S-NSSAI and/or IPv4 address domain are helpful in the scenario of IPv4 address overlapping where the same IPv4 address may be allocated to UE PDU sessions.
Upon the reception of an HTTP GET request with: "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings" as Resource URI, the BSF shall search the corresponding binding information. If "ipv6Prefix" is used as an UE IPv6 address in the query parameters, the BSF shall use the longest prefix match to find a matching IPv6 prefix so that the IPv6 address in the query parameters is within the address range covered by that matching IPv6 prefix. The IPv6 address in the query parameters shall be formatted as an IPv6 prefix value including the trailing prefix length "/128". If the framed routes exist in the binding information, the BSF shall use framed routes to match the UE address in the query parameters.
If the HTTP request message from the NF service consumer is accepted and a session binding resource matching the query parameters exists, the BSF shall reply with an HTTP "200 OK" response, as shown in figure 4.2.4.2-1, step 2, containing the corresponding "PcfBinding" data structure, as provided by the PCF during the Nbsf_Management_Register Service Operation, in the response body containing PCF addressing information, and if available, the related PCF Set Id and PCF instance Id. If there is no PCF binding information for a PDU session matching the query parameters, the BSF shall respond with an HTTP "204 No Content".
NOTE 2: The NF service consumer (such as the AF or NEF) uses the PCF binding information as described in 3GPP TS 29.513 [5] clause 8.4.2 (see bullets d) and e) in that clause). If the NF service consumer (such as the AF or NEF) is not able to reach the received PCF address(es), the NF service consumer can use the PCF Set Id and the PCF instance Id as specified in 3GPP TS 29.513 [5] clause 8.4.2.
If the "PCF for a PDU Session Bindings" resource does not exist, the BSF shall respond with "404 Not Found" HTTP error code. If an invalid combination of query parameters (i.e. a combination without UE address) is contained in the request URI, the BSF shall respond with an HTTP "400 Bad Request" error code containing "MANDATORY_QUERY_PARAM_MISSING" as application error within the ProblemDetails IE. If more than one Individual PCF for a PDU Session Binding resources are found, the BSF shall respond with an HTTP "400 Bad Request" error code containing "MULTIPLE_BINDING_INFO_FOUND" as application error within the ProblemDetails IE.
4.2.4.3 Retrieve the PCF binding information for a UE
Figure 4.2.4.3-1: NF service consumer retrieve the PCF binding information for a UE
The NF service consumer shall invoke the Nbsf_Management_Discovery service operation to obtain address information of the selected PCF for a UE in the BSF. The NF service consumer shall send an HTTP GET request with "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings" as Resource URI, and "query parameters" that shall include:
– SUPI and/or GPSI;
Upon the reception of an HTTP GET request with: "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings" as Resource URI, the BSF shall search the corresponding binding information.
If the HTTP request message from the NF service consumer is accepted and a binding resource matching the query parameters exists, the BSF shall reply with an HTTP "200 OK" response, as shown in figure 4.2.4.3-1, step 2, containing the corresponding "PcfForUeBinding" data structure(s), as provided by the PCF during the Nbsf_Management_Register Service Operation, in the response body containing PCF addressing information, and if available, the related PCF Set Id and PCF instance Id. If there is no PCF binding information for a UE matching the query parameters, the BSF shall respond with an HTTP "200 OK" response with an empty array (i.e. "[ ]" in JSON).
NOTE: If the NF service consumer (such as the AF or NEF) is not able to reach the received PCF address(es), the NF service consumer can use the PCF Set Id and the PCF instance Id as specified in 3GPP TS 29.513 [5] clause 6.2.
4.2.4.4 Retrieve the PCF binding information for an MBS Session
Figure 4.2.4.4-1: PCF for an MBS Session Binding Retrieval procedure
1. The NF service consumer (e.g. NEF, MBSF, AF) shall invoke the Nbsf_Management_Discovery service operation to obtain from the BSF the addressing information of the selected PCF for an MBS Session. The NF service consumer shall send for this purpose an HTTP GET request targeting the "PCF for an MBS Session Bindings" resource URI, i.e. "{apiRoot}/nbsf-management/<apiVersion>/pcf-mbs-bindings", which shall include the following query parameters:
– the identifier of the MBS Session to which the requested MBS Session binding is related, within the "mbs-session-id" query parameter;
and may include the following query parameters:
– the list of supported features, within the "sup-feat" query parameter.
2. Upon the reception of an HTTP GET request with: "{apiRoot}/nbsf-management/<apiVersion>/pcf-mbs-bindings" as Resource URI, the BSF shall search the corresponding binding information. If the HTTP GET request from the NF service consumer is accepted and a corresponding "Individual PCF for an MBS Session Binding" resource matching the provided query parameters exists, the BSF shall respond with an HTTP "200 OK" response, as shown in figure 4.2.4.4-1, step 2, containing the corresponding "PcfMbsBinding" data structure(s), as provided by the PCF during the Nbsf_Management_Register Service Operation, in the response body containing PCF addressing information, and if available, the related PCF Set Id and PCF instance Id. If there is no PCF binding information for a UE matching the query parameters, the BSF shall respond with an HTTP "200 OK" response with an empty array (i.e. "[ ]" in JSON).
NOTE: If the NF service consumer (such as the AF, NEF or MBSF) is not able to reach the received PCF address(es), the NF service consumer can use the PCF Set Id and the PCF instance Id as specified in 3GPP TS 29.513 [5] clause 8.6.
If the "PCF for an MBS Session Bindings" resource does not exist, the BSF shall respond with "404 Not Found" HTTP error code. If an invalid combination of query parameters (i.e. a combination without MBS Session Id) is contained in the request URI, the BSF shall respond with an HTTP "400 Bad Request" error code containing "MANDATORY_QUERY_PARAM_MISSING" as application error within the ProblemDetails IE. If more than one Individual PCF for an MBS Session Binding resources are found, the BSF shall respond with an HTTP "400 Bad Request" error code containing "MULTIPLE_BINDING_INFO_FOUND" as application error within the ProblemDetails IE.
4.2.5 Nbsf_Management_Update Service Operation
4.2.5.1 General
This service operation allows the NF service consumer to update an existing PCF for a PDU session binding information for a UE in the BSF by providing the information to be updated (e.g. the UE address(es)), and the BSF updates the PDU session binding information.
This service operation also allows the NF service consumer to update an existing PCF for a UE binding information for a UE in the BSF by providing the information to be updated (e.g. PCF instance, and related PCF address), and the BSF updates the UE binding information.
This service operation also allows the NF service consumer to update existing PCF for an MBS Session binding information for an MBS Session at the BSF by providing the information to be updated (e.g. PCF instance, PCF addresses), and the BSF update the MBS session binding information.
The following procedures using the Nbsf_Management_Update service operation are supported:
– Update an existing PCF for a PDU Session binding information.
– Update an existing PCF for a UE binding information.
– Update an existing PCF for an MBS Session binding information.
4.2.5.2 Update an existing PCF for a PDU Session binding information
Figure 4.2.5.2-1: NF service consumer update an existing PCF for a PDU Session binding information
If the feature "BindingUpdate" is supported, the NF service consumer shall invoke the Nbsf_Management_Update service operation to update PCF for a PDU the session binding information for a UE in the BSF. The NF service consumer shall send an HTTP PATCH request with "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings/{bindingId}" as Resource URI, where "{bindingId}" is the "Individual PCF for a PDU Session Binding" resource identifier that is to be updated, as shown in figure 4.2.5.2-1, step 1. The "PcfBindingPatch" data structure provided in the request body shall contain the information to be updated as follows.
The "PcfBindingPatch" data structure:
– for the IP address information of the served UE:
a) shall contain the "ipv4Addr" attribute if the IPv4 address is modified, or if the "ExtendedSamePcf" feature is supported, if the IPv4 address was not previously provided, and may contain the "ipDomain" attribute if the IPv4 address domain is modified or if the "ExtendedSamePcf" feature is supported, if the IPv4 address domain was not previously provided and applies. To remove the IPv4 address the "ipv4Addr" attribute shall be set to "null" and if applicable, the "ipDomain" attribute shall be set to "null"; and/or
b) shall contain the "ipv6Prefix" attribute if the IPv6 address information is modified, or if the "ExtendedSamePcf" feature is supported, if the IPv6 address information was not previously provided. The "ipv6Prefix" attribute shall be set to "null" if the IPv6 address information is removed; and/or
c) if the "MultiUeAddr" feature is supported, shall contain:
1) the "addIpv6Prefixes" attribute containing the new complete list of additional IPv6 Address Prefixes if the additional IPv6 address information is modified, or if the "ExtendedSamePcf" feature is supported, the current list of IPv6 address prefixes if it was not previously provided; or
2) the "addIpv6Prefixes" attribute set to "null" if all additional IPv6 Address Prefixes are removed; or
– for the MAC address information of the served UE:
a) shall contain the "macAddr48" attribute if the MAC address is modified, or if the "ExtendedSamePcf" feature is supported, if the MAC address was not previously provided. The "macAddr48" attribute shall be set to "null" if the MAC address is removed; and/or
b) if the "MultiUeAddr" feature is supported, shall contain:
1) the "addMacAddrs" attribute containing the new complete list of additional MAC addresses if the additional MAC address information is modified, or if the "ExtendedSamePcf" feature is supported, the current list of MAC address(es) if it was not previously provided; or
2) the "addMacAddrs" attribute set to "null" if all additional MAC addresses are removed; or
– for the PCF instance and the associated PCF address information of the PCF holding the SM policy association, should contain if a new PCF instance is selected:
a) the PCF instance ID encoded as "pcfId" attribute;
b) if the PCF supports the Npcf_PolicyAuthorization service:
1) the FQDN of the PCF encoded as "pcfFqdn" attribute; and/or
2) a description of IP endpoints at the PCF hosting the Npcf_PolicyAuthorization service encoded as "pcfIpEndPoints" attribute; and/or
c) if the PCF supports the Rx interface:
1) the Diameter host id of the PCF encoded as "pcfDiamHost"; and
2) the Diameter realm of the PCF and "pcfDiamRealm" attributes.
If the BSF cannot successfully fulfil the received HTTP PATCH request due to the internal BSF error or due to the error in the HTTP PATCH request, the BSF shall send the HTTP error response as specified in clause 5.7.
Otherwise, upon the reception of the HTTP PATCH request with: "{apiRoot}/nbsf-management/<apiVersion>/pcfBindings/{bindingId}" as Resource URI and the "PcfBindingPatch" data structure as request body, the BSF shall update the binding information.
If the BSF successfully updated an "Individual PCF for a PDU Session Binding" resource, the BSF shall respond with "200 OK" status code with the message body containing the resource representation with the updated PCF for a PDU session binding information in the "PcfBinding" data structure, as shown in figure 4.2.5.2-1, step 2.
If errors occur when processing the HTTP PATCH request, the BSF shall send an HTTP error response as specified in clause 5.7.
If the feature "ES3XX" is supported, and the BSF determines the received HTTP PATCH request needs to be redirected, the BSF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [6].
4.2.5.3 Update an existing PCF for a UE binding information
Figure 4.2.5.3-1: NF service consumer update an existing PCF for a UE binding information
The NF service consumer shall invoke the Nbsf_Management_Update service operation to update the PCF for a UE binding information for a UE in the BSF. The NF service consumer shall send an HTTP PATCH request with "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings/{bindingId}" as Resource URI, where "{bindingId}" is the "Individual PCF for a UE Binding" resource identifier that is to be updated, as shown in figure 4.2.5.3-1, step 1. The "PcfForUeBindingPatch" data structure provided in the request body shall contain the information to be updated as follows.
The "PcfForUeBindingPatch" data structure, for the PCF instance and the associated PCF address information of the PCF holding the AM policy association, shall contain if a new PCF instance is selected:
a) the PCF instance ID encoded as "pcfId" attribute; and
b) if the PCF supports the Npcf_AMPolicyAuthorization service, the Npcf_AMPolicyAuthorization service address information consisting of:
1) the FQDN of the PCF encoded as "pcfForUeFqdn" attribute; and/or
2) a description of IP endpoints at the PCF hosting the Npcf_AMPolicyAuthorization service encoded as "pcfForUeIpEndPoints" attribute.
NOTE: In this release of the specification the PCF for a UE registering the binding information in the BSF supports the Npcf_AMPolicyAuthorization service.
If the BSF cannot successfully fulfill the received HTTP PATCH request due to the internal BSF error or due to the error in the HTTP PATCH request, the BSF shall send the HTTP error response as specified in clause 5.7.
Otherwise, upon the reception of the HTTP PATCH request with: "{apiRoot}/nbsf-management/<apiVersion>/pcf-ue-bindings/{bindingId}" as Resource URI and the "PcfForUeBindingPatch" data structure as request body, the BSF shall update the binding information.
If the BSF successfully updated an "Individual PCF for a UE Binding" resource, the BSF shall respond with "200 OK" status code with the message body containing the resource representation with the updated PCF for a UEbinding information in the "PcfForUeBinding" data structure, as shown in figure 4.2.5.3-1, step 2.
If the BSF determines the received HTTP PATCH request needs to be redirected, the BSF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [6].
4.2.5.4 Update an existing PCF for an MBS Session binding information
Figure 4.2.5.4-1: NF service consumer update an existing PCF for an MBS Session binding information
1. The NF service consumer (e.g. PCF handling the MBS Session) shall invoke the Nbsf_Management_Update service operation to request the modification of an existing PCF for an MBS Session binding information for an MBS Session at the the BSF. The NF service consumer shall send for this purpose an HTTP PATCH request targeting the URI of the concerned "Individual PCF for an MBS Session Binding" resource, i.e. "{apiRoot}/nbsf-management/<apiVersion>/pcf-mbs-bindings/{bindingId}", with the request body containing the PcfMbsBindingPatch data structure including the requested modifications.
2. Upon successful modification of the PCF for an MBS Session binding, the BSF shall respond with either:
– an HTTP "200 OK" status code with the response body containing a representation of the updated "Individual PCF for an MBS Session Binding" resource wihin the PcfMbsBinding data structure; or
– an HTTP "204 No Content" status code.
If errors occur when processing the HTTP PATCH request, the BSF shall apply the error handling procedures specified in subclause 5.7.
4.2.6 Nbsf_Management_Subscribe Service Operation
4.2.6.1 General
This service operation is used by an NF service consumer to subscribe to the notifications of registration/deregistration events for the PCF for a PDU Session or PCF for a UE.
The following procedures using the Nbsf_Management_Subscribe service operation are supported:
– Creating a new subscription;
– Modifying an existing subscription.
4.2.6.2 Creating a new subscription
Figure 4.2.6.2-1 illustrates the creation of a subscription.
Figure 4.2.6.2-1: Creation of a subscription
To subscribe to event notifications, the NF service consumer shall send an HTTP POST request with: "{apiRoot}/nbsf-management/<apiVersion>/subscriptions" as Resource URI and the BsfSubscription data structure as request body that shall include:
– an URI where to receive the requested notifications within the "notifUri" attribute;
– a Notification Correlation Identifier provided by the NF service consumer for the requested notifications within the "notifCorreId" attribute;
– identification of the events to subscribe as "events" attribute;
– the SUPI within the "supi" attribute;
– if the NF service consumer subscribes to event notifications of newly registered and deregistered PCF for a PDU session, the "events" attribute indicating "PCF_PDU_SESSION_BINDING_REGISTRATION"/"PCF_PDU_SESSION_BINDING_DEREGISTRATION" and/or subscribes to the event notifications of binding registration of the first PDU session and deregistration of the last PDU session for a S-NSSAI and DNN combination indicating "SNSSAI_DNN_BINDING_REGISTRATION"/"SNSSAI_DNN_BINDING_DEREGISTRATION" respectively, and one DNN and S-NSSAI pair to which the subscription applies within the "snssaiDnnPairs" attribute and, when the subscription applies to more than one DNN and S-NSSAI, the list of the remaining DNN and S-NSSAI pairs to which the subscription applies within the "addSnssaiDnnPairs" attribute, which includes the DNN within the "dnn" attribute and the S-NSSAI within the "snssai" attribute;
NOTE 1: When the subscribed event is SNSSAI_DNN_BINDING_REGISTRATION and SNSSAI_DNN_BINDING_DEREGISTRATION, only the status of the binding for the concerned S-NSSAI and DNN combination is reported, i.e., it is not needed to report the complete binding related information, but only an indication of registration or deregistration event.
– if the NF service consumer subscribes to event notifications of newly registered and deregistered PCF for a UE, the "events" attribute indicating "PCF_UE_BINDING_REGISTRATION"/"PCF_UE_BINDING_DEREGISTRATION".
The BsfSubscription data structure as request body may also include:
– the GPSI within the "gpsi" attribute.
If the BSF cannot successfully fulfil the received HTTP POST request due to an internal BSF error or an error in the HTTP POST request, the PCF shall send an HTTP error response as specified in clause 5.7.
Upon successful reception of the HTTP POST request with "{apiRoot}/nbsf-management/<apiVersion>/subscriptions" as request URI and "BsfSubscription" data structure as request body, the BSF shall create a new "Individual Binding Subscription" resource, store the subscription and send a HTTP "201 Created" response as shown in figure 4.2.6.2-1, step 2. The BSF shall include in the "201 Created" response:
– a Location header field; and
– a "BsfSubscriptionResp" data type in the payload body.
The Location header field shall contain the URI of the created individual application session context resource i.e., "{apiRoot}/nbsf-management/<apiVersion>/subscriptions/{subId}".
The "BsfSubscriptionResp" data type shall contain:
– the representation of the created "Individual Binding Subscription" resource within the "BsfSubscription" data type; and
– when the BSF already has available the requested information at the time of the event subscription request, the related notification information within the "BsfNotification" data type as specified in clause 4.2.8.2.
The subscription to any event lasts till the NF service consumer terminates it as described in subsclause 4.2.7.2. For every subscribed event, the continuous reporting notification method shall apply.
4.2.6.3 Modifying an existing subscription
Figure 4.2.6.3-1 illustrates the modification of an existing subscription.
Figure 4.2.6.3-1: Modification of an existing subscription
To modify an existing subscription to event notifications, the NF service consumer shall send an HTTP PUT request with: "{apiRoot}/nbsf-management/<apiVersion>/subscriptions/{subId}" as Resource URI, where "{subId}" is the subscription correlation ID of the existing subscription, and BsfSubscription data structure as request body as described in clause 4.2.6.2.
NOTE 1: The "notifUri" attribute within the BsfSubscription data structure can be modified to request that subsequent notifications are sent to a new NF service consumer.
NOTE 2: This service operation does not allow the unsubscription of all subscribed events. The unsubscription of all subscribed events is described in clause 4.2.7.2.
Upon the reception of an HTTP PUT request with: "{apiRoot}/nbsf-management/<apiVersion>/subscriptions/{subId}" as Resource URI and BsfSubscription data structure as request body, if the received HTTP request is successfully processed and accepted, the BSF shall:
– update the concerned subscription; and
– send an HTTP "200 OK" response with a response body containing a representation of the updated subscription in the BsfSubscriptionResp data structure or send an HTTP "204 No Content".
If errors occur when processing the HTTP PUT request, the BSF shall send an HTTP error response as specified in clause 5.7.
If the BSF determines the received HTTP PUT request needs to be redirected, the BSF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].
4.2.7 Nbsf_Management_Unsubscribe Service Operation
4.2.7.1 General
This service operation is used by an NF service consumer to unsubscribe from event notifications.
The following procedure using the Nbsf_Management_Unsubscribe service operation is supported:
– Unsubscription from event notifications.
4.2.7.2 Unsubscription from event notifications
Figure 4.2.7.2-1 illustrates the unsubscription from event notifications.
Figure 4.2.7.2-1: Unsubscription from event notifications
To unsubscribe from all event(s) notifications, the NF service consumer shall send an HTTP DELETE request with: "{apiRoot}/nbsf-management/<apiVersion>/subscriptions/{subId}" as Resource URI, where "{subId}" is the subscription correlation ID of the existing subscription that is to be deleted.
Upon the reception of the HTTP DELETE request with: "{apiRoot}/nbsf-management/<apiVersion>/subscriptions/{subId}" as Resource URI, if the received HTTP request is successfully processed and accepted, the BSF shall:
– remove the corresponding subscription; and
– send an HTTP "204 No Content" response.
If errors occur when processing the HTTP DELETE request, the BSF shall send an HTTP error response as specified in clause 5.7.
If the BSF determines the received HTTP DELETE request needs to be redirected, the BSF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].
4.2.8 Nbsf_Management_Notify Service Operation
4.2.8.1 General
The Nbsf_Management_Notify service operation enables the BSF to send notifications to NF service consumers upon the occurrence of a previously subscribed event.
The following procedure using the Nbsf_Management_Notify service operation is supported:
– Notification about subscribed events.
4.2.8.2 Notification about subscribed events
The present "notification about subscribed events" procedure is performed by the BSF when any of the subscribed events occur.
Figure 4.2.8.2-1 illustrates the notification about subscribed events.
Figure 4.2.8.2-1: Notification about subscribed events
If the BSF observes event(s) for which an NF service consumer has subscribed, the BSF shall send an HTTP POST request as shown in figure 4.2.8.2-1, step 1, with the "{notifUri}" as request URI containing the value previously provided by the NF service consumer within the corresponding subscription, and the BsfNotification data structure.
The BsfNotification data structure shall include:
– the notification correlation ID provided by the NF service consumer during the subscription within "notifCorreId" attribute;
– the list of the reported events within the "eventNotifs" attribute. For each reported event, the BsfEventNotification data type shall include the event identifier and may include additional event information.
Within each instance of BsfEventNotification data type, the BSF shall include:
– When a subscription to "PCF_PDU_SESSION_BINDING_REGISTRATION" and "PCF_PDU_SESSION_BINDING_DEREGISTRATION" exists:
a. When the BSF detects the registration of a PCF for a PDU session for a DNN and S-NSSAI, SUPI, and GPSI, if available, matching one of the DNN, S-NSSAI pairs, the SUPI and the GPSI, if available, provided during subscription, the BSF shall set the "event" attribute to "PCF_PDU_SESSION_BINDING_REGISTRATION" and shall include the "pcfForPduSessInfos" with the binding information of the detected PDU session.
b. When the PCF detects the deregistration of a PCF for a PDU session for a DNN and S-NSSAI, SUPI, and GPSI, if available, matching one of the DNN, S-NSSAI pairs, the SUPI and the GPSI, if available, provided during subscription, the BSF shall set the "event" attribute to "PCF_PDU_SESSION_BINDING_DEREGISTRATION" and shall include the "pcfForPduSessInfos" with the binding information of the of the removed PDU session.
– When a subscription to "PCF_UE_BINDING_REGISTRATION" and "PCF_UE_BINDING_DEREGISTRATION"exists:
a. When the BSF detects the registration of a PCF for a UE for a SUPI and, if available, GPSI matching the SUPI and, if available, GPSI provided during subscription, the BSF shall set the "event" attribute to "PCF_UE_BINDING_REGISTRATION" and shall include the "pcfForUeInfo" with the binding information of the detected UE.
b. When the BSF detects the deregistration of a PCF for a UE for a SUPI and, if available, GPSI matching the SUPI and, if available, GPSI provided during subscription, the BSF shall set the "event" attribute to "PCF_UE_BINDING_DEREGISTRATION" and shall include the "pcfForUeInfo" with the binding information of the removed UE.
– When a subscription to "SNSSAI_DNN_BINDING_REGISTRATION" and "SNSSAI_DNN_BINDING_DEREGISTRATION"exists:
a. When the BSF detects the registration of PCF for a PDU session for a DNN and S-NSSAI, SUPI, and GPSI, if available, matching one of the DNN, S-NSSAI pairs, the SUPI and the GPSI, if available, provided during subscription, and this is the first PDU session for the DNN and S-NSSAI, SUPI, and GPSI, if available, combination, the BSF shall set the "event" attribute to "SNSSAI_DNN_BINDING_REGISTRATION" and the "matchSnssaiDnns" attribute with the matching S-NSSAI and DNN pairs.
b. When the BSF detects the deregistration of PCF for a PDU session for a DNN and S-NSSAI, SUPI, and GPSI, if available, matching one of the DNN, S-NSSAI pairs, the SUPI and the GPSI, if available, provided during subscription, and this is the last PDU session for the DNN and S-NSSAI, SUPI, and GPSI, if available, combination, the BSF shall set the "event" attribute to "SNSSAI_DNN_BINDING_DEREGISTRATION" and the removed S-NSSAI and DNN combinations within the "matchSnssaiDnns" attribute.
If the HTTP POST request from the BSF is accepted, the NF service consumer shall acknowledge the receipt of the event notification with a "204 No Content" response to HTTP POST request, as shown in figure 4.2.8.2-1, step 2.
If the HTTP POST request from the BSF is not accepted, the NF service consumer shall indicate in the response to HTTP POST request the cause for the rejection as specified in clause 5.7. If the NF service consumer determines the received HTTP POST request needs to be redirected, the NF service consumer shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].