7 Network Service Control protocol

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

7.1 Procedures for the transmission of NS SDUs

NS SDUs are transmitted in unacknowledged mode across the Gb interface by means of an NS-UNITDATA PDU.

The NS-UNITDATA PDU is used in both BSS-to-SGSN and SGSN-to-BSS directions.

For an IP sub-network, an NS-UNITDATA PDU for a PTP BVC may indicate a request to change the IP endpoint and/or a response to a change in the IP endpoint.

If the BSS or SGSN receives an NS-UNITDATA PDU for a signalling BVC or a PTM BVC then the BSS or SGSN shall ignore the coding of the C-bit and R-bit.

7.1.1 Abnormal Conditions

If the BSS receives an NS-UNITDATA PDU including a BVCI not associated to the NS-VC where the PDU was received, the BSS shall return an NS-STATUS PDU on that NS-VC, cause "BVC unknown on that NSE". Depending on the implementation, the BSS may then ignore the BVCI and treat the rest of the NS-UNITDATA PDU.

7.2 Blocking / unblocking procedures

The Blocking/Unblocking procedures shall not be used for an IP Sub-network.

When a BSS (or SGSN) wishes to block an NS-VC between a BSS and SGSN, the following shall be performed:

– The transmitting side at the BSS (or SGSN) shall mark the NS-VC as blocked and shall inform the load sharing function. This results in the redistribution of NS-UNIDATA PDUs to other unblocked NS-VCs of the same group, as described in the "Load sharing function" sub-clause. The NS user entity shall also be informed of the new transfer capability by means of an NS-STATUS-Indication primitive for each affected BVC. A BSS (or SGSN) then sends an NS-BLOCK PDU to the peer entity and starts timer Tns-block.

– The NS-BLOCK PDU contains the NS-VCI and a Cause element indicating the reason for blocking (typical cause values: Transit network failure, O&M intervention, Equipment failure). The NS-BLOCK PDU may be sent in any alive (blocked or unblocked) NS-VC pertaining to the same group as the NS-VC to be blocked, unless otherwise required for particular cases which may be further described in the rest of the present document.

– At the sending side of the NS-BLOCK PDU, if no failure has occurred in the receive direction (e.g. O&M intervention), the originator of the NS-BLOCK PDU shall continue to accept NS-UNITDATA PDUs received on the NS-VC being blocked, until an NS-BLOCK-ACK PDU is received for this NS-VC. The originator of the NS‑BLOCK PDU shall stop to accept NS-UNITDATA PDUs, if the number of retries of the blocking procedures is exceeded.

– Upon Receipt of an NS-BLOCK PDU at an SGSN (or BSS) the NS-VC shall be marked as blocked. The SGSN (or BSS) shall immediately inform the load sharing function. The NS user entity shall also be informed of the new transfer capability by means of an NS-STATUS-Indication primitive for each affected BVC. The SGSN (or BSS) then sends in any alive (blocked or unblocked) NS-VC of the relevant group an NS-BLOCK-ACK PDU, for the blocked NS-VC, to the BSS (or SGSN).

– On receipt of an NS-BLOCK-ACK PDU or NS-BLOCK PDU, the originator of the NS-BLOCK PDU stops timer Tns-block.

The NS-VC shall remain blocked until an NS-UNBLOCK PDU is received indicating that the NS-VC’s state has been changed.

When a BSS (or SGSN) wishes to unblock an NS-VC between a BSS and SGSN, the following shall be performed:

– The BSS (or SGSN) sends an NS-UNBLOCK PDU to the peer entity and starts timer Tns-block. The NS‑UNBLOCK PDU shall be sent on the NS-VC to be unblocked (the NS-VC must be alive, see check procedure in sub-clauses "Test of an NS-VC"). The BSS or SGSN may discard any NS-UNITDATA PDU received on the concerned NS-VC until the reception of the NS-UNBLOCK-ACK PDU.

– If an NS-UNBLOCK PDU is received by an SGSN (or BSS) for an NS-VC and the SGSN (or BSS) is able to unblock the NS-VC, the SGSN (or BSS) shall return an NS-UNBLOCK-ACK PDU on the NS-VC where the NS-UNBLOCK PDU was received, then the NS-VC shall be marked as unblocked. The load sharing function shall be informed. The NS user entity shall also be informed of the new transfer capability by means of an NS-STATUS-Indication primitive for each affected BVC.

– A BSS (or SGSN) shall stop timer Tns-block on receipt of an NS-UNBLOCK-ACK or NS-UNBLOCK PDU, shall mark the NS-VC as unblocked and shall inform the load sharing function in order to allow transmission of NS-UNITDATA PDUs on this NS-VC. The NS user entity shall also be informed of the new transfer capability by means of an NS-STATUS-Indication primitive for each affected BVC. An NS-UNBLOCK PDU received while a BSS (or SGSN) is waiting for an NS-UNBLOCK-ACK PDU shall be acknowledged with an NS‑UNBLOCK-ACK PDU.

– If an NS-UNBLOCK PDU is received by an SGSN (or BSS) and the SGSN (or BSS) is not able to unblock the NS-VC, the NS-VC shall remain blocked and the NS-VC blocking procedure shall be initiated by returning an NS-BLOCK PDU to the BSS (or SGSN). This NS-BLOCK PDU shall be sent on the NS-VC where the NS‑UNBLOCK PDU was received.

– If a BSS (or SGSN) receives an NS-BLOCK PDU while waiting for an NS-UNBLOCK-ACK PDU, it shall stop timer Tns-block and the NS-VC shall remain blocked. An NS-BLOCK-ACK PDU shall be returned. An indication shall be issued towards the O&M system, announcing that the unblocking of the NS-VC was not possible at the peer entity. Further actions of the O&M system are out of the scope of the present document.

7.2.1 Abnormal Conditions

If an NS-BLOCK-ACK PDU is not received for an NS-BLOCK PDU within Tns-block seconds, then the NS-BLOCK PDU procedure shall be repeated a maximum of NS-BLOCK-RETRIES attempts. After NS-BLOCK-RETRIES unsuccessful retry attempts the procedure is stopped and the O&M system is informed that the blocking procedure has failed. Further actions of the O&M system are out of the scope of the present document. The NS-VC shall be marked as blocked at the originating side of the blocking procedure.

If an NS-UNBLOCK-ACK PDU is not received for an NS-UNBLOCK PDU within Tns-block seconds, the NS-UNBLOCK PDU procedure shall be repeated a maximum of NS-UNBLOCK-RETRIES attempts. After NS-UNBLOCK-RETRIES unsuccessful retry attempts the procedure is stopped and the O&M system is informed that the unblocking procedure has failed. Further actions of the O&M system are out of the scope of the present document. The NS-VC shall be marked as blocked at the originating side of the unblocking procedure.

If an NS-UNITDATA PDU is received on an NS-VC that is marked at a BSS or an SGSN as blocked and no NS-VC unblocking procedure is pending, then an NS-STATUS PDU (Cause value: NS-VC blocked) shall be returned to the peer entity.

If an NS-BLOCK PDU is received by a BSS or an SGSN for a blocked NS-VC, an NS-BLOCK-ACK PDU shall be returned.

If an NS-UNBLOCK PDU is received by a BSS or an SGSN for an unblocked NS-VC, an NS-UNBLOCK-ACK PDU shall be returned.

If an unexpected NS-BLOCK-ACK PDU is received by a BSS or an SGSN and it is related to an NS-VC that is locally blocked, the NS-BLOCK-ACK PDU is discarded. If the NS-BLOCK-ACK PDU is related to an NS-VC that is not locally blocked, then an NS-VC unblocking procedure is initiated.

If an unexpected NS-UNBLOCK-ACK PDU is received by a BSS or an SGSN and it is related to an NS-VC that is not locally blocked, the received NS-UNBLOCK-ACK PDU is discarded. If the NS-UNBLOCK-ACK PDU is related to an NS-VC that is locally blocked, then an NS-VC blocking procedure is initiated.

If the NS-VCI received in an NS-BLOCK or NS-BLOCK-ACK PDU is unknown, then the error shall be reported to the originator of the PDU by means of an NS-STATUS PDU including the unknown NS-VCI, with the Cause value set to "NS-VC unknown", the O&M system shall be informed, then the NS-BLOCK or NS-BLOCK-ACK PDU shall be ignored. Further actions of the O&M system are out of the scope of the present document.

7.3 Reset procedure

The reset procedure shall not be used for an IP Sub-network.

The reset procedure shall be used when a new NS-VC is set-up between a BSS and an SGSN, after processor re-start, after failure recovery or any local event restoring an existing NS-VC in the dead state or when its state is undetermined between remote NS entities. Upon completion of the reset procedure, the successfully reset NS-VC is marked as blocked and alive at both sides of the Gb interface.

When a BSS (or SGSN) wishes to reset an NS-VC, the following shall be performed:

– The NS entity at the BSS (or SGSN) informs the NS user entity of the new transfer capability by means of an NS-STATUS-Indication primitive for each affected BVC. The BSS (or SGSN) then sends an NS-RESET PDU to its peer entity indicating the NS-VCI and the NSEI. The NS-RESET PDU is sent on the NS-VC being reset. The NS-RESET PDU includes a Cause information element.

– The sending entity of the NS-RESET PDU then marks the NS-VC as blocked and dead and starts timer Tns-reset.

– Receipt of an NS-RESET PDU at an SGSN (or BSS) shall be acknowledged with an NS-RESET-ACK PDU including the NS-VCI and the NSEI, provided that the receiving side is able to reset the NS-VC (i.e. no local condition prevents the receiving side from resetting the NS-VC). The NS-RESET-ACK PDU shall be sent on the NS-VC being reset.

– The entity receiving the NS-RESET PDU then marks the acknowledged NS-VC as blocked and alive and informs the NS user entity of the new transfer capability by means of an NS-STATUS-Indication primitive for each affected BVC. The test procedure is then initiated on this NS-VC.

– When the sending entity of an NS-RESET PDU receives the NS-RESET-ACK PDU, it stops timer Tns-reset, marks the NS-VC as blocked and alive and initiates the test procedure on this NS-VC. The originator of the NS-RESET PDU is then responsible for unblocking this NS-VC.

In case of collision between reset procedures initiated at both sides of the Gb interface, the following shall apply:

– When an NS entity awaiting an NS-RESET-ACK PDU in response to an NS-RESET PDU receives an NS-RESET PDU, it shall acknowledge it as described above, and in addition, it shall treat it as an NS-RESET-ACK PDU.

When an NS entity is awaiting an NS-RESET-ACK PDU, any PDU other than NS-RESET or NS-RESET-ACK received on one of the NS-VCs being reset shall be ignored.

The reset procedure overrides any other pending procedure on the affected NS-VC i.e. other pending procedures are stopped, other running timers are stopped.

7.3.1 Abnormal conditions

If the sending entity of an NS-RESET PDU receives no NS-RESET-ACK PDU before timer Tns-reset expires the corresponding NS-VCs shall remain blocked and dead and the entire reset procedure shall be repeated. If the reset procedure remains unsuccessful for a period of time established by the operator, the O&M system shall be informed, and the reset procedure shall be stopped. Further actions of the O&M system are out of the scope of the present document.

If the NS-VCI received in an NS-RESET PDU is different from the NS-VCI locally associated to this NS-VC, the O&M system shall be informed, an NS-RESET-ACK PDU shall be returned including the NS-VCI locally associated to this NS-VC, then the NS-RESET PDU shall be ignored as if not received.

If the NSEI received in an NS-RESET PDU is different from the NSEI locally associated to this NS-VC, the O&M system shall be informed, an NS-RESET-ACK PDU shall be returned including the NSEI locally associated to this NS-VC, then the NS-RESET PDU shall be ignored as if not received.

If the NS-VCI received in an NS-RESET-ACK PDU is different from the NS-VCI locally associated to this NS-VC or if the NSEI received in an NS-RESET-ACK PDU is different from the NSEI locally associated to this NS-VC, the O&M system shall be informed, then the reset procedure shall be stopped. Further actions of the O&M system are out of the scope of the present document.

If an NS-RESET-ACK PDU is received when not expected, it shall be ignored.

7.4 Test procedure for a Frame Relay Sub-network

The test procedure shall be used when a BSS (or SGSN) wishes to check that end-to-end communication with its peer entity exists on an NS-VC.

Both sides of the Gb interface may initiate this procedure independently from each other. This procedure shall be initiated upon successful completion of the reset procedure (as specified in sub-clause "Reset procedure") and shall then be periodically repeated.

Upon successful completion of an NS-VC reset procedure, a BSS (or SGSN) shall start timer Tns-test, then:

– Upon Tns-test expiry, a BSS (or SGSN) sends an NS-ALIVE PDU on the NS-VC to be checked, starts timer Tns-alive and waits for an NS-ALIVE-ACK PDU on this NS-VC.

– Upon receipt of an NS-ALIVE PDU on an alive NS-VC, an SGSN (or BSS) shall return an NS-ALIVE-ACK PDU on the NS-VC where the NS-ALIVE PDU was received.

– Upon receipt of the NS-ALIVE-ACK PDU in response to an NS-ALIVE PDU, the originator of the NS-ALIVE PDU, shall stop timer Tns-alive and shall start again timer Tns-test.

The procedure is repeated each time Tns-test expires.

7.4.1 Abnormal conditions

If an NS-ALIVE-ACK PDU is received when not expected, it shall be ignored.

If no NS-ALIVE-ACK PDU is received before Tns-alive expires, the test procedure shall be repeated a maximum of NS-ALIVE-RETRIES attempts. After NS-ALIVE-RETRIES unsuccessful retry attempts, the procedure is stopped, the NS-VC is marked as dead and blocked, the O&M system and the load sharing function are informed, and an NS‑STATUS-Indication is sent to the NS user entity. If the NS-VC is not already blocked, a blocking procedure is initiated using an alive NS-VC, if any. Further actions of the O&M system are out of the scope of the present document.

7.4b Test Procedure for an IP Sub-network

The test procedure is used on the Gb interface to verify the communications paths between the SGSN and the BSS. At least one of the signalling endpoints of the SGSN shall be tested by the BSS, by sending the NS-ALIVE PDU on any NS-VC terminating at any of the SGSN signalling endpoints. An NSE may test any peer NSE IP endpoint at any time.

It is recommended that all remote IP endpoints of an NSE (signalling and data endpoints) are tested periodically, regardless of their operational status (operational or non-operational).

Upon successful completion of the Size and configuration procedures when configured by auto-configuration procedures, or upon completion of administrative configuration, the NSE shall start timer Tns-test. Upon expiry of the timer Tns-test the NSE shall:

– send an NS-ALIVE PDU to a peer IP endpoint.

– start timer Tns-alive.

– upon receiving an NS-ALIVE-ACK PDU from the peer NSE IP endpoint, the NSE shall stop timer Tns-alive and shall start again timer Tns-test.

The procedure is repeated each time that the Tns-test expires.

Upon receipt of an NS-ALIVE PDU, on any configured IP endpoint, the NSE shall send an NS-ALIVE-ACK PDU to the source UDP/IP endpoint of the NS-ALIVE PDU.

Upon receipt of an NS-ALIVE-ACK PDU, on an IP endpoint marked as non-operational, the NSE communication path is marked as operational.

7.4b.1 Abnormal Conditions

If an NS-ALIVE-ACK PDU is received when not expected, it shall be discarded.

7.4b.1.1 Abnormal Conditions for signalling endpoints

If the NSE timer Tns-alive expires, the test procedure shall be repeated a maximum of NS-ALIVE-RETRIES times. After NS-ALIVE-RETRIES unsuccessful attempts the NSE communication path is marked as non-operational.

The O&M system and the load sharing function are informed, and an NS-STATUS-Indication is sent to the NS user entity. If more than one signalling endpoint is available at the SGSN, an NS-STATUS PDU may be sent to the SGSN using one of the available signalling endpoints of the peer NSE. The NS-STATUS includes the two IP endpoints that comprise the NS-VC and a cause code "IP test failed". Further actions of the O&M system is out of the scope of the present document.

If more than one signalling endpoints are available at the SGSN the test procedure shall continue on one or more of these endpoints.

If all signalling UDP/IP endpoints of a peer SGSN NSE are marked non-operational and if the NSE is configured by auto-configuration procedures, then the BSS NSE shall start the Size procedure with the Reset-bit field of the Reset Flag IE set to "1" followed by the configuration procedure.

If an SGSN tests IP endpoints of a peer BSS NSE and all signalling IP endpoints of a peer BSS NSE are marked non-operational and if the NSE is configured by auto-configuration procedures, then the SGSN NSE shall not respond to NS-ALIVE messages from that BSS NSE. If the NSE is configured by administrative means, then the SGSN NSE shall respond to NS-ALIVE messages from that BSS NSE.

When the SGSN recovers after a restart or a network failure and if the NSE is configured by auto-configuration procedures, it shall not respond on any NS-PDUs until the Size and configuration procedures have been completed successfully.

7.4b.1.2 Abnormal Conditions for data endpoints

If the test procedure is being performed on a data IP endpoint and timer Tns-alive expires, depending on the implementation, the test procedure may be repeated. After NS-ALIVE-RETRIES unsuccessful retry attempts, the O&M system and the load sharing function are informed, and an NS-STATUS-Indication is sent to the NS user entity. An NS-STATUS procedure may be initiated towards a signalling IP endpoint. The NS-STATUS includes the two IP endpoints that comprise the NS-VC and a cause code "IP test failed". Further actions of the O&M system is out of the scope of the present document.

When an NS-ALIVE fails for a path, the sending side is allowed to change both the local IP endpoint and the remote IP endpoint.

Traffic may be processed if received on an IP endpoint after an unsuccessful test procedure.

7.5 Procedure for error reporting

The reporting of protocol errors to the remote entity is done by means of the NS-STATUS PDU, as further described in the rest of the present document.

Upon receipt of an NS-STATUS PDU, the O&M system is informed. Further actions of the O&M system are out of the scope of the present document.

7.5.1 Abnormal conditions

If an error is detected in a received NS-STATUS PDU, then the error shall not be reported to the remote NS entity.

7.6 Resource Distribution Procedure

Each NS entity is responsible for determining when to trigger the Resource Distribution Function and to which IP endpoint resource distribution can occur. This sub-clause only describes the mechanism for informing the peer NS entity the IP endpoint at which NS user data for an MS or for an MBMS session is to be received. Recommended usage of the Resource Distribution Function for an IP sub-network when Resource Distribution is to be performed on a data flow concerning an MS can be found in annex B.

The resource distribution function at an NSE may choose to change the IP endpoint at which it receives NS user data for an MS or MBMS session. To achieve this, the NS user entity shall notify the load sharing function and subsequently the NS entity to send an NS-UNITDATA with the R-bit field set to "1" in the NS SDU Control Bits IE from the new IP endpoint. Note: the BSS may set the R-bit field to "1" in the initial PDU for NS user data for an MS. If an NSE has no NS SDU to send for some period of time, or if Resource Distribution is to be performed on a data flow concerning an MBMS session, then the NSE shall send an NS‑UNITDATA PDU containing a BSSGP DL-UNITDATA (BSSGP UL-UNITDATA) or, in case of an MBMS session, a BSSGP UL-MBMS-UNITDATA with an LLC-PDU Length Indicator set to 0 (see 3GPP TS 48.018).

When the NSE receives an NS-UNITDATA PDU with R-bit field set to "1" in the NS SDU Control Bits IE, it shall inform the higher layers to change the destination IP endpoint for that MS or MBMS session. All subsequent NS SDUs for the same MS or MBMS session shall be sent to this destination. The receiving NSE may optionally send an NS-UNITDATA PDU with the C-bit field set to "1" in the NS SDU Control Bits IE to confirm acknowledgement of the request to change the IP endpoint.

The NSE initiating the Resource Distribution Function for an MS shall not set the R-bit field to "1" in an NS-UNITDATA PDU for this MS once it has received an NS-UNITDATA PDU for the same MS, irrespective of the C-bit field value, at the requested IP endpoint.

7.6.1 Abnormal Conditions

If a peer NSE continues to send NS-UNITDATA for a given MS or MBMS session to an IP endpoint after receipt of a NS-UNITDATA with R-bit that directs traffic to a different IP endpoint, then the action taken by the NSE is implementation dependent.. The BSS maintains the MS context for a subscriber for a finite period of time. When uplink data is received for a mobile and the BSS has no MS context with the SGSN preferred IP endpoint then the BSS may choose to send the NS user data on one of the IP endpoints determined by the load sharing function. However, the SGSN maintains the MS context for as long as it has location information for the MS on cell level.