A Flexible Architecture for Broadcast Broadband: Proposed Signalling Service-Based Architecture

Table of Links

• Abstract and Introduction
• Proposed Signalling Service-Based Architecture
• System Model
• Performance Evaluation
• Convergence of 3GPP 5G and N3BN in SSBA
• Conclusion, Acknowledgement, and References

II. PROPOSED SIGNALLING SERVICE-BASED ARCHITECTURE

In this section, we present an overview of the proposed SSBA, as shown in Fig. 1. Before delivering the details of the proposed SSBA, let us first understand the basic principles of an SSBA (a detailed explanation is available in [8]). In SSBA, a Service Function (SF) handles signalling exchange with the UE through the user plane for network services (i.e. RRC/NAC service, broadcast service). The SF then communicates with the network control plane to establish the data path through the network data plane.

Fig. 1. Proposed signalling service-based mobile network architecture.

In the context of Fig.1, the preceding explanation can be linked as follows: the Broadcast Service Function (BSF) functions as an independent SF responsible for exchanging multicast/broadcast-related signalling messages with UEs. These include membership requests, content delivery requests, and other associated operations. The BSF interfaces with the control plane (Broadcast Controller (BCC)) to initiate data path establishment. Further, the BCC communicates with the RAN/CN controller to configure the data path for efficient content delivery. However, the decision for delivery methods (unicast or broadcast) is governed by BCC and switching between delivery methods is handled by the Broadcast Data Plane (BDP).

The information flow in the proposed SSBA is as follows: UE-1 is associated with the broadcast RAN (RAN-DP (BC)), whereas UE-2 is connected to the unicast (UC) RAN (RANDP (UC)). Notably, the BSF facilitates UE (both UE-1 and UE-2) interaction via the DP. Therefore, the signalling path for UC/BC transmission involves the following: UE-2/UE-1 - RAN-DP (UC) - User Plane Function (UPF) - BSF as shown in Fig. 1 with the blue dotted line. Furthermore, the RAN controller controls the RAN data planes (RAN-DP (UC) and RAN-DP (BC)), while the CN controller supervises the CN data planes (UPF and Multicast/Broadcast UPF (MB-UPF)).

A. MBS Session Establishment Call flow for the Proposed SSBA

Fig. 2 illustrates the MBS session establishment call flow for the proposed SSBA. Conversely, the call flow for MBS session establishment in the 3GPP 5G architecture is available in [11] (Section 7.1.1.2 and 7.2.1.3). This section provides a concise comparison between the call flows of the proposed and 3GPP 5G MBS session establishment, highlighting the significant reduction in the number of signalling messages achieved in the proposed SSBA.

A Temporary Mobile Group Identity (TMGI) allocation process (messages 1-2) is carried out between Application Function (AF) and BCC as shown in Fig. 2. The session create request (message 3) is sent to BCC by AF. In response, BCC forwards this request to the CN controller. CN controller confirms the resource availability from the RAN controller (messages 5 and 7) and the RAN controller sends the session command (message 6) to RAN-DP to set up the session on the RAN side. On receiving confirmation from the RAN controller, the CN controller sends the session command to MB-UPF (message 8) to set up the session on the core network side as well. Messages 13-15 are related to UE joining the MBS session. Here, UE initiates the MBS session join request to BSF, which is then forwarded to the RRC/NAS SF and eventually processed by this SF to send the Radio Resource Control (RRC) reconfiguration message in response, to UE via RAN-DP.

The controllers in the proposed SSBA do not call for response messages from the user plane, as they have global information about the user plane resources. Therefore, messages 6, 8 and 11 (as shown in Fig. 2) are sent as commands without requiring corresponding response messages. As a result, the modified call flow significantly reduces the total number of signalling messages. Similarly, message 14 (Fig. 2) also does not require a response message. Therefore, the procedure for MBS session establishment call flow is appreciably simplified, enhancing the overall modularity of the network.