6 Sub-Network Service protocol

3GPP48.016Base Station System (BSS) - Serving GPRS Support Node (SGSN) interfaceGeneral Packet Radio Service (GPRS)Network serviceRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Frame Relay support of the Sub-Network Service protocol

6.1.1 Overview

The Gb interface may consist of direct point-to-point connections between the BSS and the SGSN, or an intermediate Frame Relay network may be placed between both ends of the Gb interface. Other intermediate equipments may be traversed. Several configurations are possible, the detail of which is outside the scope of the present document. For the purposes of the present document the following two types of configurations have to be considered:

– Point-to-point physical connections.

– Intermediate Frame Relay network.

In case of an intermediate Frame Relay network, both BSS and SGSN shall be treated as the user side of the user-to-network interface. The network-to network interface is outside the scope of the present document.

Only Frame Relay permanent virtual connections (PVCs) shall be used on the Gb interface. Therefore ITU‑T Recommendation Q.922 Annex A or T1.618 for PCS1900 and ITU‑T Recommendation Q.933 Annex A or T1.617 for PCS1900, permanent virtual connection procedures, shall be supported. Switched virtual connection procedures in ITU‑T Recommendation Q.922 or T1.618 for PCS1900 and ITU‑T Recommendation Q.933 or T1.617 for PCS1900 shall not be supported. ITU‑T Recommendation Q.921 or T1.602 and ITU‑T Recommendation Q.931 procedures shall not be applicable.

The Frame Relay user-to-network interface (UNI) shall be implemented on the Gb interface according to the FRF 1.1 agreement, unless otherwise stated in the present document. Selected options or deviations from FRF 1.1 are specified in the rest of this Frame Relay chapter. Where discrepancies arise between the present document and the above mentioned recommendations, the present document takes precedence.

The rest of this Frame Relay sub-clause applies only to PVC usage.

The Gb interface addressing principles shall be applied as follows:

– The physical link is the Frame Relay bearer channel.

– The NS-VL is the local link in one end (at UNI) of the Frame Relay PVC.

– The NS-VLI is the Frame Relay DLCI together with the bearer channel identifier.

– The NS-VC is the Frame Relay PVC.

– The Sub-Network Service entity is the Frame Relay entity.

6.1.2 Network configuration

The Gb interface is a User-to-Network (UNI) interface, as defined in FRF 1.1. Two configurations are possible, either a direct link configuration or PVC(s) via a Frame Relay network.

Annex A shows an example of each type of configuration.

In case of point-to-point connections, the BSS shall be considered as the user side of the user-to-network interface, the SGSN shall be considered as the network side, see figure 6.1.2.1.

Figure 6.1.2.1: Direct link configuration

In case of an intermediate Frame Relay network, both BSS and SGSN shall be treated as the user side of the user-to-network interface, see figure 6.1.2.2. The network-to network interface is outside the scope of the present document.

Figure 6.1.2.2: PVC via a Frame Relay Network

6.1.3 Services expected from layer 1

In the context of Frame Relay, the physical link is referred to as the bearer channel.

The Frame Relay protocol shall be run across permanently reserved bearer channels on the Gb interface, see 3GPP TS 48.014.

6.1.4 Options selected from FRF 1.1

6.1.4.1 Support of DL-CONTROL sub-layer

No end-to-end DL-CONTROL sub-layer shall be implemented on the Gb interface.

6.1.4.2 Frame length

The default maximum information field size of 1 600 octets shall be supported on the Gb interface. Maximum information field sizes greater than 1 600 octets may be agreed to between Frame Relay network operators and users at subscription time.

6.1.4.3 Congestion control procedures

Congestion control is defined in FRF 1.1 and consists of congestion avoidance and congestion recovery mechanisms.

Congestion control on the Gb interface consists of congestion avoidance based on the DE bit and on explicit notifications via the FECN and BECN bits within the address field of the Frame Relay frame.

Congestion avoidance based on the CLLM message (see ITU‑T Recommendation Q.922 sub-clause A.7 or T1.618 for PCS1900 and FRF 1.1 sub-clause 2.2.5) is not required at the BSS and SGSN sides.

No congestion control mechanism based on implicit congestion detection (see ITU‑T Recommendation Q.922 sub-clause A.6.1) or T1.618 for PCS1900 is required at the BSS and SGSN sides.

6.1.4.3.1 DE bit usage

The BSS and the SGSN shall always set the DE bit to 0 (zero).

6.1.4.3.2 FECN and BECN bit usage

Setting of the FECN and BECN bits:

The FECN and BECN bits shall be set to 0 by the BSS and the SGSN.

Reaction upon receipt of FECN or BECN marked frames:

The reaction of the BSS and the SGSN upon reception of FECN or BECN marked frames is implementation dependent.

It is recommended to implement ITU‑T Recommendation Q.922 appendix I.2 or T1.618 for PCS1900 procedures or similar procedures, so that the NS entity can reduce or increase the transmission rate, depending on the FECN or BECN bits received.

The NS entity shall be able to report the congestion situation to the upper layer. The criteria to be met for congestion being reported to the upper layer are implementation dependent. The upper layer is expected to reduce or increase its transmission rate as appropriate. It shall be up to the upper layer to perform further appropriate actions e.g. flow control with its peer entity, see ITU‑T Recommendation I.370 or T1.606 for PCS1900.

6.1.4.4 Signalling procedures

ITU‑T Recommendation Revised Q.933 annex A or T1.617 for PCS1900 procedures shall be implemented at the BSS and the SGSN sides as recommended in FRF 1.1 sub-clause 2.3.

On the Gb interface, these procedures shall be initiated by the user side of the UNI, reverse procedures shall not be used.

Only periodic polling shall be used, asynchronous status message needs not to be supported.

Switched virtual connection procedures , see FRF 1.1 sub-clause 2.3.2, shall not be implemented.

6.1.4.5 C/R bit usage

The C/R bit shall not be used and shall be set to 0 by the sending entity. It shall not be checked by the receiving entity.

6.1.5 Abnormal conditions

Upon detection of the unavailability of a PVC by the Frame Relay entity or when a PVC becomes available again, the Network Service Control entity shall be informed. Unavailability cases are described in Recommendations ITU‑T Recommendation Q.922 or T1.618 for PCS1900 and ITU‑T Recommendation Q.933 annex A or T1.617 for PCS1900.

6.2 IP Support of the Sub-Network Service Protocol

6.2.1 Overview

The IP Sub-Network shall use the Internet Protocol (IP) as defined in either RFC 791 or RFC 2460 and the User Datagram Protocol (UDP) as defined in RFC 768.

The connections between the BSS and the SGSN may consist of point-to-point connections or of an intermediate IP network. Several configurations are possible, the details of which are outside the scope of the present document. For the purposes of the present document the following characteristics have to be considered:

1) The Sub-Network Service (SNS) may be configured by administrative means (i.e. static configuration) or by auto-configuration procedures (i.e. dynamic configuration). In the case of auto-configuration the operator shall ensure, in advance, that each NSE can fulfil its peer NSE requirements (e.g. maximum number of NS-VCs, maximum number of IP-endpoints).

2) Administrative configuration means the administration of the NSEs’ IP endpoints (including the Signalling Weight and Data Weight).

3) In the case of a point-to-point connection, the administrative configuration shall be used. In the case of an intermediate IP network connection, then either the administrative means or the auto-configuration procedures may be used.

4) The BSS NSE has no knowledge of the configuration of any other BSS NSEs.

5) The auto-configuration procedures are used to exchange configuration information between the BSS and the SGSN. The client/server principle applies: the SGSN is the server, while the BSS is a client. The BSS shall have knowledge of at least one SGSN IP endpoint, referred to as pre-configured endpoint hereafter, to initiate the procedures. The auto-configuration procedures consist of the following:

a) After start-up the BSS NSE reports to the peer-SGSN NSE by initiating the Size procedure.

b) Then, the BSS initiates the Configuration Procedure in which a sequence of messages are exchanged between the BSS and the SGSN containing signalling endpoints, data endpoints, and initial weights.

A pre-configured endpoint shall not be used for NSE data or signalling traffic (with the exception of Size and Configuration procedures) unless it is configured by the SGSN using the auto-configuration procedures.

6) A network connection as part of the intermediate IP network between the NSEs shall be terminated by the same type of IP addresses (e.g. IPv4 or IPv6).

7) For dynamic configurations the change of initially configured parameters shall be supported by the Add procedure, Delete procedure and ChangeWeight procedure.

8) The SNS messages (SNS SIZE, SNS CONFIG, SNS ADD, SNS DELETE, SNS CHANGEWEIGHT) serving to support the configuration, Size, Add, Delete and ChangeWeight procedures shall only be used in the case of dynamic configuration.

6.2.1a Abnormal Conditions

If the BSS or SGSN NSE receives at a given IP endpoint an SNS PDU containing an unknown NSEI or an NSEI associated to a different local IP endpoint, the BSS or SGSN NSE may simply discard such SNS PDU without further action.

6.2.2 IP Fragmentation

Fragmentation should be avoided if possible. Examples of fragmentation drawbacks are, e.g.:

– Fragmentation is inefficient, since the complete IP header is duplicated in each fragment.

– If one fragment is lost, the complete packet has to be discarded. The reason is that no selective retransmission of fragments is possible.

Mechanisms used to avoid fragmentation are outside the scope of the present document.

6.2.3 Services expected from layer 1 and layer 2

Layer one and two are unspecified. No services are defined in the present document.

6.2.4 Size Procedure

This procedure is initiated by the BSS. The Size procedure shall be performed to:

– Reset all information maintained by the BSS NSE and its peer prior to the configuration procedure.

– Verify that the number of NS-VCs that can be supported by the BSS NSE is greater than or equal to the number of NS-VCs required for full mesh connectivity to the peer SGSN NSE.

– Verify that the number of IP endpoints indicated by the BSS NSE can be supported by the SGSN NSE.

– Verify the compatibility between the type of IP addresses (IPv4/IPv6) supported by the peer NSEs.

The BSS NSE shall send an SNS-SIZE PDU to the SGSN using any of the pre-configured SGSN IP endpoints (configuring of any pre-configured SGSN IP endpoints is out of the scope of the present document). The BSS shall start timer Tsns-prov. The SNS_SIZE PDU shall contain the following information elements:

– NSEI: NSE Identifier.

– Maximum Number of NS-VCs: maximum number of NS-VCs the BSS NSE can support.

– Reset Flag: indicates whether all configuration information between the BSS NSE and its peer SGSN NSE shall be cleared prior to a forthcoming initiation of the configuration procedure by the BSS NSE (Reset-bit field of the Reset Flag IE set to "1"), or if the procedure is only initiated to ascertain the ability of the SGSN NSE to support the requested capabilities (Reset-bit field of the Reset Flag IE set to "0").

– Number of IP4 Endpoints: maximum number of BSS NSE IPv4 addresses that the BSS NSE is allowed to configure through the forthcoming configuration procedure and/or

– Number of IP6 Endpoints: maximum number of BSS NSE IPv6 addresses that the BSS NSE is allowed to configure through the forthcoming configuration procedure.

Upon receipt of an SNS-SIZE PDU, the SGSN shall:

– If the Reset-bit field of the Reset Flag IE is set to "1", clear all previous operating information about the BSS NSE (no operating information shall be affected in the SGSN if the Reset-bit field of the Reset Flag IE is set to "0").

– Send an SNS-SIZE-ACK PDU to the source IP endpoint. The SNS-SIZE-ACK PDU shall contain the NSEI IE. The SNS-SIZE-ACK PDU may contain the Cause IE as specified in sub-clause 6.2.4.1.

Upon receipt of an SNS-SIZE-ACK PDU the BSS shall:

– Stop timer Tsns-prov.

– If the Reset-bit field of the Reset Flag IE was set to "1" in the SNS-SIZE PDU sent by the BSS, initiate the configuration procedure (see sub-clause 6.2.5).

6.2.4.1 Abnormal Conditions

If the maximum number of NS-VCs indicated in the SNS-SIZE PDU is less than the number of NS-VCs required for full mesh connectivity between the peer NSEs, the SGSN shall send an SNS-SIZE-ACK PDU with a cause code "Invalid number of NS-VCs". The number of NS-VCs required for full mesh connectivity between peer NSEs is the product of the number of IPv4 endpoints supported on each of the peer NSEs plus the product of the number of IPv6 endpoints supported on each of the peer NSEs.

Upon receiving the SNS-SIZE-ACK PDU with a cause code "Invalid number of NS-VCs" the BSS NSE may notify the O&M system and abort the procedure.

If the SGSN does not support the type of IP addresses (IPv4/IPv6) offered by the BSS, the SGSN shall send an SNS-SIZE-ACK PDU with a cause code "Invalid number of IP4 Endpoints" or "Invalid number of IP6 Endpoints". Upon receiving the SNS-SIZE-ACK PDU with a cause code "Invalid number of IP4 Endpoints" or "Invalid number of IP6 Endpoints" the BSS NSE may notify the O&M system and abort the procedure.

If the SGSN does not support the number of IPv4 endpoints indicated in the SNS-SIZE PDU, the SGSN shall send an SNS-SIZE-ACK PDU with a cause code set to "Invalid number of IP4 Endpoints". If the SGSN does not support the number of IPv6 endpoints indicated in the SNS-SIZE PDU, the SGSN shall send an SNS-SIZE-ACK PDU with a cause code set to "Invalid number of IP6 Endpoints". Upon receiving the SNS-SIZE-ACK PDU with a cause code set to "Invalid number of IP4 Endpoints" or "Invalid number of IP6 Endpoints", the BSS NSE may notify the O&M system and abort the procedure.

Upon expiry of timer Tsns-prov the NSE may retry the operation SNS-SIZE-RETRIES times. If the operation has been attempted SNS-SIZE-RETRIES times without acknowledgement from the peer NS entity, then the NS entity may notify the O&M system and abort the procedure. Whether the NS entity would restart the size procedure using any pre-configured SGSN IP endpoints after abortion is left implementation dependent. Further actions are outside the scope of the present document.

6.2.5 Configuration Procedure

The configuration procedure is used on the Gb interface to exchange configuration information between an NSE and its peer NSE. To start the configuration procedure, the client/server principle is used, with the BSS as the client. Upon start-up/restart of a BSS NSE or following the detection of a restart of a peer SGSN NSE (e.g. by means of the test procedure – see sub-clause 7.4b), the Size procedure with the Reset-bit field of the Reset Flag IE set to "1" in the SNS-SIZE PDU shall be performed upon initiation by the BSS NSE before the configuration procedure is started.

After completion on the BSS side of the Size procedure having indicated a reset, the BSS NSE shall send an SNS-CONFIG PDU to the same pre-configured SGSN IP endpoint used in the Size procedure.

NOTE: This does not imply that the SNS-CONFIG PDU has to be sent from the same IP endpoint used in the Size procedure.

The BSS shall start timer Tsns-prov. The SNS-CONFIG PDU shall contain the following information elements:

NSEI: NSE Identifier.

End Flag: identifies the last SNS-CONFIG PDU sent by the BSS NSE.

List of IP4 Elements: one or more IPv4 endpoints, or

List of IP6 Elements: one or more IPv6 endpoints.

Upon receipt of an SNS-CONFIG PDU sent by the BSS, the SGSN shall send an SNS-CONFIG-ACK PDU to the source IP endpoint.

Upon receipt of an SNS-CONFIG-ACK PDU sent by the SGSN, the BSS shall:

– Stop timer Tsns-prov.

– Repeat the above SNS-CONFIG PDU sequence to the SGSN if the BSS has more IP endpoints to configure.

After completion on the SGSN side of the Size procedure, the SGSN shall send an SNS-CONFIG PDU to the BSS NSE using any known signalling IP endpoints (i.e., from information contained within an SNS-CONFIG PDU sent by the BSS). The SGSN shall start timer Tsns-prov. The SNS-CONFIG PDU shall contain the following information elements:

NSEI: NSE Identifier.

End Flag: identifies the last SNS-CONFIG PDU sent by the SGSN NSE.

List of IP4 Elements: one or more IPv4 endpoints, or

List of IP6 Elements: one or more IPv6 endpoints.

Upon receipt of an SNS-CONFIG PDU sent by the SGSN, the BSS shall send an SNS-CONFIG-ACK PDU to the source IP endpoint.

Upon receipt of an SNS-CONFIG-ACK PDU sent by the BSS, the SGSN shall:

– Stop timer Tsns-prov.

– Repeat the above SNS-CONFIG PDU sequence to the BSS if the SGSN has more IP endpoints to configure. The SGSN shall start timer Tsns-prov.

Neither the SGSN nor the BSS shall initiate any other procedure before receiving the peer’s end-flag.

6.2.5.1 Abnormal Conditions

Upon receiving an SNS-CONFIG PDU with the E-bit field in the End Flag IE set to "1", if the total number of IPv4 elements sent to the SGSN by the BSS NSE is greater than the number of IPv4 endpoints sent by the BSS NSE in the SIZE PDU, the SGSN shall send an SNS-CONFIG-ACK PDU with a cause code of "Invalid number of IP4 Endpoints". The SGSN shall clear all information associated with the peer BSS NSE.

Upon receiving an SNS-CONFIG-ACK PDU with a cause code set to "Invalid number of IP4 Endpoints" the BSS may notify the O&M system and abort the procedure. Further actions are outside the scope of the present document. The BSS shall clear all information associated with the peer SGSN NSE.

Upon receiving an SNS-CONFIG PDU with the E-bit field in the End Flag IE set to "1", if the total number of IPv6 elements sent to the SGSN by the BSS NSE is greater than the number of IPv6 endpoints sent by the BSS NSE in the SIZE PDU, the SGSN shall send an SNS-CONFIG-ACK PDU with a cause code of "Invalid number of IP6 Endpoints". The SGSN shall clear all information associated with the peer BSS NSE.

Upon receiving an SNS-CONFIG-ACK PDU with a cause code set to "Invalid number of IP6 Endpoints" the BSS may notify the O&M system and abort the procedure. Further actions are outside the scope of the present document. The BSS shall clear all information associated with the peer SGSN NSE.

Upon receiving an SNS-CONFIG PDU with the E-bit field in the End Flag IE set to "1", if the total number of IPv4 elements sent to the BSS by the SGSN NSE is greater than the number of IPv4 endpoints supported by the BSS NSE, the BSS shall send an SNS-CONFIG-ACK PDU with a cause code set to "Invalid number of IP4 Endpoints" and clear all information associated with the peer SGSN NSE.

Upon receiving an SNS-CONFIG PDU with the E-bit field in the End Flag IE set to "1", if the total number of IPv6 elements sent to the BSS by the SGSN NSE is greater than the number of IPv6 endpoints supported by the BSS NSE, the BSS shall send an SNS-CONFIG-ACK PDU with a cause code set to "Invalid number of IP6 Endpoints" and clear all information associated with the peer SGSN NSE.

Upon receiving an SNS-CONFIG-ACK PDU with a cause code set to "Invalid number of IP4 Endpoints" or "Invalid number of IP6 Endpoints" the SGSN may notify the O&M system and abort the procedure. Further actions are outside the scope of the present document. The SGSN shall clear all information associated with the peer BSS NSE.

Upon receiving an SNS-CONFIG PDU with the E-bit field in the End Flag IE set to "1", if the resulting sum of the signalling weights of all the peer IP endpoints configured for this NSE is equal to zero or if the resulting sum of the data weights of all the peer IP endpoints configured for this NSE is equal to zero the NSE shall send an SNS-CONFIG-ACK PDU with a cause code of "Invalid weights". The NSE shall clear all information associated with the peer NSE. Upon receiving an SNS-CONFIG ACK PDU with cause code set to "Invalid weights" the NSE shall clear all information associated with the peer NSE and may notify the O&M system.

Upon expiry of timer Tsns-prov the NSE may retry the operation SNS-CONFIG-RETRIES times. If the operation has been attempted SNS-CONFIG-RETRIES times without acknowledgement from the peer NSE, then the NSE may notify the O&M system and abort the procedure. Further actions are outside the scope of the present document.

6.2.6 Add Procedure

The Add procedure is used by an NSE to configure additional IP endpoints.

To add new IP endpoints, the NSE shall send an SNS-ADD PDU to a peer NSE signalling endpoint. Upon sending the SNS-ADD PDU the NSE shall start timer Tsns-prov. The SNS-ADD PDU shall contain the following information elements:

NSEI: NSE Identifier.

Transaction ID: identifies a unique transaction within an NSE.

List of IP4 Elements: one or more IPv4 endpoints, or.

List of IP6 Elements: one or more IPv6 endpoints.

Upon receipt of an SNS-ADD PDU the NSE shall send an SNS-ACK PDU to the source IP endpoint from which the SNS-ADD PDU was sent. The SNS-ACK PDU shall contain the Transaction ID set to the same value as that in the SNS-ADD PDU.

Upon receipt of an SNS-ACK PDU the NSE shall stop timer Tsns-prov.

6.2.6.1 Abnormal Conditions

Upon receiving an SNS-ADD PDU, if the consequent number of NS-VCs exceeds the maximum own supported number of NS-VCs then the NSE shall send an SNS-ACK PDU with cause code set to "Invalid number of NS-VCs".

Upon receiving an SNS-ADD PDU, if the consequent number of IPv4 endpoints exceeds the number of IPv4 endpoints supported by the NSE, the NSE shall send an SNS-ACK PDU with a cause code set to "Invalid number of IP4 Endpoints".

Upon receiving an SNS-ADD PDU, if the consequent number of IPv6 endpoints exceeds the number of IPv6 endpoints supported by the NSE, the NSE shall send an SNS-ACK PDU with a cause code set to "Invalid number of IP6 Endpoints".

Upon receiving an SNS-ADD PDU containing an already configured IP endpoint the NSE shall send an SNS-ACK PDU with the cause code "Protocol error – unspecified".

For any of the abnormal cases specified above:

– The whole content of the received SNS-ADD PDU shall be ignored.

– The SNS-ACK PDU shall be sent to the source IP endpoint from which the SNS-ADD PDU was sent. The SNS-ACK PDU shall contain the Transaction ID set to the same value as that in the SNS-ADD PDU.

Upon expiry of timer Tsns-prov the NSE may retry the operation SNS-ADD-RETRIES times. If the operation has been attempted SNS-ADD-RETRIES times without acknowledgement from the peer NSE, then the NSE may notify the O&M system and abort the procedure. Further actions are outside the scope of the present document.

6.2.7 Delete Procedure

The delete procedure is used by an NSE to remove previously configured IP endpoints from service.

To delete IP endpoints, the NSE shall send an SNS-DELETE PDU to a peer NSE signalling endpoint. Upon sending the SNS-DELETE PDU the NSE shall start timer Tsns-prov. The SNS-DELETE PDU shall contain the following information elements:

NSEI: NSE Identifier.

Transaction ID: identifies a unique transaction within the NSE.

IP Address: all IP endpoints that use this IP address shall be deleted or

List of IP4 Elements: one or more IPv4 endpoints, or

List of IP6 Elements: one or more IPv6 endpoints.

Upon receipt of an SNS-DELETE PDU the NSE shall send an SNS-ACK PDU to the source IP endpoint from which the SNS-DELETE PDU was sent. The SNS-ACK PDU shall contain the Transaction ID set to the same value as that in the SNS-DELETE PDU.

Upon receipt of an SNS-ACK PDU the NSE shall stop timer Tsns-prov.

6.2.7.1 Abnormal Conditions

Upon receiving an SNS-DELETE PDU containing one or more IP endpoints that has not been previously configured with an SNS-ADD PDU or an SNS-CONFIG PDU, the NSE shall send an SNS-ACK PDU with a cause code of "Unknown IP endpoint" to the source IP endpoint from which the SNS-DELETE PDU was sent. The SNS-ACK PDU shall contain the Transaction ID set to the same value as that in the SNS-DELETE PDU. The NSE shall also include, in the SNS-ACK PDU, all IPv4 endpoints in the SNS-DELETE PDU that have not been previously configured in the List of IP4 Elements IE, or all IPv6 endpoints in the SNS-DELETE PDU that have not been previously configured in the List of IP6 Elements IE. All previously configured IP endpoints contained in the SNS-DELETE PDU shall be deleted.

Upon receiving an SNS-DELETE PDU containing an IP address for which no IP endpoints have been previously configured with an SNS-ADD PDU or an SNS-CONFIG PDU, the NSE shall send an SNS-ACK PDU with a cause code of "Unknown IP address" to the source IP endpoint from which the SNS-DELETE PDU was sent. The SNS-ACK PDU shall contain the Transaction ID set to the same value as that in the SNS-DELETE PDU. The NSE shall also include, in the SNS-ACK PDU, the IP address received in the SNS-DELETE PDU.

Upon expiry of timer Tsns-prov the NSE may retry the operation SNS-DELETE-RETRIES times. If the operation has been attempted SNS-DELETE-RETRIES times without acknowledgement from the peer NSE, then the NSE may notify the O&M system and abort the procedure. Further actions are outside the scope of the present document.

6.2.8 ChangeWeight Procedure

The ChangeWeight procedure is used by an NSE to change the signalling weight and/or data weight of the specified IP endpoints.

To change the signalling weight and/or data weight of an IP endpoint, the NSE shall send an SNS-CHANGEWEIGHT PDU to a peer NSE signalling endpoint. Upon sending the SNS-CHANGEWEIGHT PDU the NSE shall start timer Tsns-prov. The SNS-CHANGEWEIGHT PDU shall contain the following information elements:

NSEI: NSE Identifier.

Transaction ID: identifies a unique transaction within the NSE.

List of IP4 Elements: one of more IPv4 endpoints, or

List of IP6 Elements: one or more IPv6 endpoints.

Upon receipt of an SNS-CHANGEWEIGHT PDU the NSE shall send an SNS-ACK PDU to the source IP endpoint from which the SNS-CHANGEWEIGHT PDU was sent. The SNS-ACK PDU shall contain the Transaction ID set to the same value as that in the SNS-CHANGEWEIGHT PDU.

Upon receipt of an SNS-ACK PDU the NSE shall stop timer Tsns-prov.

6.2.8.1 Abnormal Conditions

Upon receiving an SNS-CHANGEWEIGHT PDU, if the resulting sum of the signalling weights of all the peer IP endpoints configured for this NSE is equal to zero or if the resulting sum of the data weights of all the peer IP endpoints configured for this NSE is equal to zero, the BSS/SGSN shall send an SNS-ACK PDU with a cause code of "Invalid weights". The whole content of that SNS-CHANGEWEIGHT PDU shall be ignored.

Upon receiving an SNS-CHANGEWEIGHT PDU containing one or more IP endpoints that has not been previously configured with an SNS-ADD PDU or an SNS-CONFIG PDU, the NSE shall send an SNS-ACK PDU with a cause code of "Unknown IP endpoint" to the source IP endpoint from which the SNS-CHANGEWEIGHT PDU was sent. The SNS-ACK PDU shall contain the Transaction ID set to the same value as that in the SNS-CHANGEWEIGHT PDU. The NSE shall also include, in the SNS-ACK PDU, all IPv4 endpoints sent in the SNS-CHANGEWEIGHT PDU that have not been previously configured in the List of IP4 Elements IE, or all IPv6 endpoints sent in the SNS-CHANGEWEIGHT PDU that have not been previously configured in the List of IP6 Elements IE. The NSE shall discard the information in the SNS-CHANGEWEIGHT PDU associated with all IP endpoints that have not been previously configured. All previously configured IP endpoints contained in the SNS-CHANGEWEIGHT PDU shall be changed.

Upon expiry of timer Tsns-prov the NSE may retry the operation SNS-CHANGEWEIGHT-RETRIES times. If the operation has been attempted SNS-CHANGEWEIGHT-RETRIES times without acknowledgement from the peer NSE, then the NSE may notify the O&M system and abort the procedure. Further actions are outside the scope of the present document.