08.163GPPBase Station System (BSS) - Serving GPRS Support Node (SGSN) interfaceGeneral Packet Radio Service (GPRS)Network serviceRelease 1999TS
6.1 Frame Relay support of the Sub-Network Service protocol
Frame Relay shall be the network used on the Gb interface.
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 this Technical Specification. For the purposes of this Technical Specification 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 this Technical Specification.
Only Frame Relay permanent virtual connections (PVCs) shall be used on the Gb interface. Therefore ITU‑T Q.922 Annex A or T1.618  for PCS1900 and ITU‑T Q.933  Annex A or T1.617  for PCS1900, permanent virtual connection procedures, shall be supported. Switched virtual connection procedures in ITU‑T Q.922  or T1.618  for PCS1900 and ITU‑T Q.933  or T1.617  for PCS1900 shall not be supported. ITU‑T Q.921  or T1.602  and ITU‑T 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 this Technical Specification. Selected options or deviations from FRF 1.1  are specified in the rest of this Frame Relay chapter. Where discrepancies arise between this Technical Specification and the above mentioned recommendations, this Technical Specification takes precedence.
The rest of this Frame Relay 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 4/3GPP TS 08.16.
Figure 5/3GPP TS 08.16: 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 5/3GPP TS 08.16. The network-to network interface is outside the scope of this Technical Specification.
Figure 6/3GPP TS 08.16: 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 08.14 .
6.1.4 Options selected from FRF 1.1
188.8.131.52 Support of DL-CONTROL sub-layer
No end-to-end DL-CONTROL sub-layer shall be implemented on the Gb interface.
184.108.40.206 Frame length
The default maximum information field size of 1600 octets shall be supported on the Gb interface. Maximum information field sizes greater than 1600 octets may be agreed to between Frame Relay network operators and users at subscription time.
220.127.116.11 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 Q.922  clause A.7 or T1.618  for PCS1900 and FRF 1.1  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 Q.922  clause A.6.1) or T1.618  for PCS1900 is required at the BSS and SGSN sides.
18.104.22.168.1 DE bit usage
The BSS and the SGSN shall always set the DE bit to 0 (zero).
22.214.171.124.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 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 I.370  or T1.606  for PCS1900.
126.96.36.199 Signalling procedures
ITU‑T 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  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  clause 2.3.2, shall not be implemented.
188.8.131.52 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 Q.922  or T1.618  for PCS1900 and ITU‑T Q.933  annex A or T1.617  for PCS1900.