Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4666

Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)

Pages: 124
Proposed Standard
Errata
Obsoletes:  3332
Part 1 of 5 – Pages 1 to 12
None   None   Next

Top   ToC   RFC4666 - Page 1
Network Working Group                                  K. Morneault, Ed.
Request for Comments: 4666                                 Cisco Systems
Obsoletes: 3332                                    J. Pastor-Balbas, Ed.
Category: Standards Track                                       Ericsson
                                                          September 2006


       Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
                      User Adaptation Layer (M3UA)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP- based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332.
Top   ToC   RFC4666 - Page 2

Table of Contents

1. Introduction ....................................................6 1.1. Scope ......................................................6 1.2. Terminology ................................................6 1.3. M3UA Overview ..............................................9 1.3.1. Protocol Architecture ...............................9 1.3.2. Services Provided by the M3UA Layer ................10 1.3.2.1. Support for the Transport of MTP3-User Messages ........................10 1.3.2.2. Native Management Functions ...............11 1.3.2.3. Interworking with MTP3 Network Management Functions ......................11 1.3.2.4. Support for the Management of SCTP Associations between the ..................11 1.3.2.5. Support for the Management of Connections to Multiple SGPs ..............12 1.4. Functional Areas ..........................................12 1.4.1. Signalling Point Code Representation ...............12 1.4.2. Routing Contexts and Routing Keys ..................14 1.4.2.1. Overview ..................................14 1.4.2.2. Routing Key Limitations ...................15 1.4.2.3. Managing Routing Contexts and Routing Keys ..............................15 1.4.2.4. Message Distribution at the SGP ...........15 1.4.2.5. Message Distribution at the ASP ...........16 1.4.3. SS7 and M3UA Interworking ..........................16 1.4.3.1. Signalling Gateway SS7 Layers .............16 1.4.3.2. SS7 and M3UA Interworking at the SG .......17 1.4.3.3. Application Server ........................17 1.4.3.4. IPSP Considerations .......................18 1.4.4. Redundancy Models ..................................18 1.4.4.1. Application Server Redundancy .............18 1.4.5. Flow Control .......................................18 1.4.6. Congestion Management ..............................19 1.4.7. SCTP Stream Mapping ................................19 1.4.8. SCTP Client/Server Model ...........................19 1.5. Sample Configuration ......................................20 1.5.1. Example 1: ISUP Message Transport ..................20 1.5.2. Example 2: SCCP Transport between IPSPs ............21 1.5.3. Example 3: SGP Resident SCCP Layer, with Remote ASP .........................................22 1.6. Definition of M3UA Boundaries .............................23 1.6.1. Definition of the Boundary between M3UA and an MTP3-User .......................................23 1.6.2. Definition of the Boundary between M3UA and SCTP ...23 1.6.3. Definition of the Boundary between M3UA and Layer Management ...................................24
Top   ToC   RFC4666 - Page 3
   2. Conventions ....................................................27
   3. M3UA Protocol Elements .........................................28
      3.1. Common Message Header .....................................28
           3.1.1. M3UA Protocol Version: 8 bits (unsigned integer) ...28
           3.1.2. Message Classes and Types ..........................28
           3.1.3. Reserved: 8 Bits ...................................30
           3.1.4. Message Length: 32-Bits (Unsigned Integer) .........30
      3.2. Variable-Length Parameter Format ..........................30
      3.3. Transfer Messages .........................................33
           3.3.1. Payload Data Message (DATA) ........................33
      3.4. SS7 Signalling Network Management (SSNM) Messages .........36
           3.4.1. Destination Unavailable (DUNA) .....................36
           3.4.2. Destination Available (DAVA) .......................39
           3.4.3. Destination State Audit (DAUD) .....................40
           3.4.4. Signalling Congestion (SCON) .......................40
           3.4.5. Destination User Part Unavailable (DUPU) ...........43
           3.4.6. Destination Restricted (DRST) ......................45
      3.5. ASP State Maintenance (ASPSM) Messages ....................45
           3.5.1. ASP Up .............................................45
           3.5.2. ASP Up Acknowledgement (ASP Up Ack) ................46
           3.5.3. ASP Down ...........................................47
           3.5.4. ASP Down Acknowledgement (ASP Down Ack) ............48
           3.5.5. Heartbeat (BEAT) ...................................48
           3.5.6. Heartbeat Acknowledgement (BEAT Ack) ...............49
      3.6. Routing Key Management (RKM) Messages [Optional] ..........49
           3.6.1. Registration Request (REG REQ) .....................49
           3.6.2. Registration Response (REG RSP) ....................54
           3.6.3. Deregistration Request (DEREG REQ) .................56
           3.6.4. Deregistration Response (DEREG RSP) ................57
      3.7. ASP Traffic Maintenance (ASPTM) Messages ..................59
           3.7.1. ASP Active .........................................59
           3.7.2. ASP Active Acknowledgement (ASP Active Ack) ........60
           3.7.3. ASP Inactive .......................................61
           3.7.4. ASP Inactive Acknowledgement (ASP Inactive Ack) ....62
      3.8. Management (MGMT) Messages ................................63
           3.8.1. Error ..............................................63
           3.8.2. Notify .............................................67
   4. Procedures .....................................................70
      4.1. Procedures to Support the M3UA-User .......................70
           4.1.1. Receipt of Primitives from the M3UA-User ...........70
      4.2. Receipt of Primitives from the Layer Management ...........71
           4.2.1. Receipt of M3UA Peer Management Messages ...........72
      4.3. AS and ASP/IPSP State Maintenance .........................73
           4.3.1. ASP/IPSP States ....................................74
           4.3.2. AS States ..........................................76
           4.3.3. M3UA Management Procedures for Primitives ..........78
           4.3.4. ASPM Procedures for Peer-to-Peer Messages ..........79
                  4.3.4.1. ASP Up Procedures .........................79
Top   ToC   RFC4666 - Page 4
                  4.3.4.2. ASP-Down Procedures .......................81
                  4.3.4.3. ASP Active Procedures .....................82
                  4.3.4.4. ASP Inactive Procedures ...................86
                  4.3.4.5. Notify Procedures .........................88
                  4.3.4.6. Heartbeat Procedures ......................89
      4.4. Routing Key Management Procedures [Optional] ..............90
           4.4.1. Registration .......................................90
           4.4.2. Deregistration .....................................92
           4.4.3. IPSP Considerations (REG/DEREG) ....................93
      4.5. Procedures to Support the Availability or
           Congestion Status of SS7 Destination ......................93
           4.5.1. At an SGP ..........................................93
           4.5.2. At an ASP ..........................................94
                  4.5.2.1. Single SG Configurations ..................94
                  4.5.2.2. Multiple SG Configurations ................94
           4.5.3. ASP Auditing .......................................94
      4.6. MTP3 Restart ..............................................96
      4.7. NIF Not Available .........................................97
      4.8. M3UA Version Control ......................................97
      4.9. M3UA Termination ..........................................97
   5. Examples of M3UA Procedures ....................................98
      5.1. Establishment of Association and Traffic between
           SGPs and ASPs .............................................98
           5.1.1. Single ASP in an Application Server ("1+0"
                  sparing), No Registration ..........................98
                  5.1.1.1. Single ASP in an Application
                           Server ("1+0" Sparing), No Registration ...98
                  5.1.1.2. Single ASP in Application Server
                           ("1+0" Sparing), Dynamic Registration .....99
                  5.1.1.3. Single ASP in Multiple
                           Application Servers (Each with "1+0"
                           Sparing), Dynamic Registration (Case 1
                           - Multiple Registration Requests) ........100
                  5.1.1.4. Single ASP in Multiple
                           Application Servers (each with "1+0"
                           sparing), Dynamic Registration (Case 2
                           - Single Registration Request) ...........101
           5.1.2. Two ASPs in Application Server ("1+1" Sparing) ....102
           5.1.3. Two ASPs in an Application Server ("1+1"
                  Sparing, Loadsharing Case) ........................103
           5.1.4. Three ASPs in an Application Server ("n+k"
                  Sparing, Loadsharing Case) ........................104
      5.2. ASP Traffic Failover Examples ............................105
           5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ...105
           5.2.2. 1+1 Sparing, Backup Override ......................105
           5.2.3. n+k Sparing, Loadsharing Case, Withdrawal of ASP ..106
      5.3. Normal Withdrawal of an ASP from an Application Server ...106
      5.4. Auditing Examples ........................................107
Top   ToC   RFC4666 - Page 5
           5.4.1. SG State: Uncongested/Available ...................107
           5.4.2. SG State: Congested (Congestion Level=2) /
                  Available .........................................107
           5.4.3. SG State: Unknown/Available .......................107
           5.4.4. SG State: Unavailable .............................108
      5.5. M3UA/MTP3-User Boundary Examples .........................108
           5.5.1. At an ASP .........................................108
                  5.5.1.1. Support for MTP-TRANSFER
                           Primitives at the ASP ....................108
           5.5.2. At an SGP .........................................109
                  5.5.2.1. Support for MTP-TRANSFER Request
                           Primitive at the SGP .....................109
                  5.5.2.2. Support for MTP-TRANSFER
                           Indication Primitive at the SGP ..........110
                  5.5.2.3. Support for MTP-PAUSE,
                           MTP-RESUME, MTP-STATUS Indication
                           Primitives ...............................110
      5.6. Examples for IPSP Communication ..........................112
           5.6.1. Single Exchange ...................................112
           5.6.2. Double Exchange ...................................113
   6. Security Considerations .......................................113
   7. IANA Considerations ...........................................114
      7.1. SCTP Payload Protocol Identifier .........................114
      7.2. M3UA Port Number .........................................114
      7.3. M3UA Protocol Extensions .................................114
           7.3.1. IETF-Defined Message Classes ......................115
           7.3.2. IETF Defined Message Types ........................115
           7.3.3. IETF-Defined Parameter Extension ..................115
   8. Acknowledgements ..............................................115
   9. Document Contributors .........................................116
   10. References ...................................................116
      10.1. Normative References ....................................116
      10.2. Informative References ..................................117
   Appendix A .......................................................119
   A.1. Signalling Network Architecture .............................119
   A.2. Redundancy Models ...........................................121
        A.2.1. Application Server Redundancy ........................121
        A.2.2. Signalling Gateway Redundancy ........................122
Top   ToC   RFC4666 - Page 6

1. Introduction

This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol [18]. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database [12], or between two IP-based applications.

1.1. Scope

There is a need for Switched Circuit Network (SCN) signalling protocol delivery from an SS7 Signalling Gateway (SG) to a Media Gateway Controller (MGC) or IP-resident Database as described in the Framework Architecture for Signalling Transport [12]. The delivery mechanism should meet the following criteria: * Support for the transfer of all SS7 MTP3-User Part messages (e.g., ISUP [1,2,3], SCCP [4,5,6], TUP [13], etc.) * Support for the seamless operation of MTP3-User protocol peers * Support for the management of SCTP transport associations and traffic between an SG and one or more MGCs or IP-resident Databases * Support for MGC or IP-resident database process failover and load sharing * Support for the asynchronous reporting of status changes to management In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 protocol layers [7,8,9] and deliver ISUP, SCCP, and/or any other MTP3-User protocol messages, as well as certain MTP network management events, over SCTP transport associations to MTP3-User peers in MGCs or IP-resident databases.

1.2. Terminology

Application Server (AS) - A logical entity serving a specific Routing Key. An example of an Application Server is a virtual switch element handling all call processing for a signalling relation, identified by an SS7 DPC/OPC. Another example is a virtual database element, handling all HLR transactions for a particular SS7 SIO/DPC/OPC combination. The AS contains a set of one or more unique Application Server Processes, of which one or more is normally actively processing traffic. Note that there is a 1:1 relationship between an AS and a Routing Key.
Top   ToC   RFC4666 - Page 7
   Application Server Process (ASP) - A process instance of an
   Application Server.  An Application Server Process serves as an
   active or backup process of an Application Server (e.g., part of a
   distributed virtual switch or database).  Examples of ASPs are
   processes (or process instances) of MGCs, IP SCPs, or IP HLRs.  An
   ASP contains an SCTP endpoint and may be configured to process
   signalling traffic within more than one Application Server.

   Association - An association refers to an SCTP association.  The
   association provides the transport for the delivery of MTP3-User
   protocol data units and M3UA adaptation layer peer messages.

   IP Server Process (IPSP) - A process instance of an IP-based
   application.  An IPSP is essentially the same as an ASP, except that
   it uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does
   not use the services of a Signalling Gateway node.

   Failover - The capability to reroute signalling traffic as required
   to an alternate Application Server Process, or group of ASPs, within
   an Application Server in the event of failure or unavailability of a
   currently used Application Server Process.  Failover also applies
   upon the return to service of a previously unavailable Application
   Server Process.

   Host - The computing platform that the process (SGP, ASP or IPSP) is
   running on.

   Layer Management - Layer Management is a nodal function that handles
   the inputs and outputs between the M3UA layer and a local management
   entity.

   Linkset - A number of signalling links that directly interconnect two
   signalling points, which are used as a module.

   MTP - The Message Transfer Part of the SS7 protocol.

   MTP3 - MTP Level 3, the signalling network layer of SS7.

   MTP3-User - Any protocol normally using the services of the SS7 MTP3
   (e.g., ISUP, SCCP, TUP, etc.).

   Network Appearance - The Network Appearance is a M3UA local reference
   shared by SG and AS (typically an integer) that, together with an
   Signaling Point Code, uniquely identifies an SS7 node by indicating
   the specific SS7 network to which it belongs.  It can be used to
   distinguish between signalling traffic associated with different
   networks being sent between the SG and the ASP over a common SCTP
   association.  An example scenario is where an SG appears as an
Top   ToC   RFC4666 - Page 8
   element in multiple separate national SS7 networks and the same
   Signaling Point Code value may be reused in different networks.

   Network Byte Order - Most significant byte first, a.k.a Big Endian.
   Routing Key - A Routing Key describes a set of SS7 parameters and
   parameter values that uniquely define the range of signalling traffic
   to be handled by a particular Application Server.  Parameters within
   the Routing Key cannot extend across more than a single Signalling
   Point Management Cluster.

   Routing Context - A value that uniquely identifies a Routing Key.
   Routing Context values are configured either using a configuration
   management interface, or by using the routing key management
   procedures defined in this document.

   Signaling End Point (SEP) - A node in the SS7 network associated with
   an originating or terminating local exchange (switch) or a gateway
   exchange.

   Signalling Gateway Process (SGP) - A process instance of a Signalling
   Gateway.  It serves as an active, backup, load-sharing, or broadcast
   process of a Signalling Gateway.

   Signalling Gateway (SG) - An SG is a signaling agent that
   receives/sends SCN native signaling at the edge of the IP network
   [12].  An SG appears to the SS7 network as an SS7 Signalling Point.
   An SG contains a set of one or more unique Signalling Gateway
   Processes, of which one or more is normally actively processing
   traffic.  Where an SG contains more than one SGP, the SG is a logical
   entity, and the contained SGPs are assumed to be coordinated into a
   single management view to the SS7 network and to the supported
   Application Servers.

   Signalling Process - A process instance that uses M3UA to communicate
   with other signalling processes.  An ASP, an SGP, and an IPSP are all
   signalling processes.

   Signalling Point Management Cluster (SPMC) - The complete set of
   Application Servers represented to the SS7 network under a single MTP
   entity (Signalling Point) in one specific Network Appearance.  SPMCs
   are used to aggregate the availability, congestion, and user part
   status of an MTP entity (Signalling Point) that is distributed in the
   IP domain, for the purpose of supporting MTP3 management procedures
   towards the SS7 network.  In some cases, the SG itself may also be a
   member of the SPMC.  In this case, the SG
   availability/congestion/User_Part status should also be taken into
   account when considering any supporting MTP3 management actions.
Top   ToC   RFC4666 - Page 9
   Signaling Transfer Point (STP) - A node in the SS7 network that
   provides network access and performs message routing, screening and
   transfer of signaling messages.

   Stream - An SCTP stream; a unidirectional logical channel established
   from one SCTP endpoint to another associated SCTP endpoint, within
   which all user messages are delivered in-sequence except for those
   submitted to the unordered delivery service.

1.3. M3UA Overview

1.3.1. Protocol Architecture

The framework architecture that has been defined for SCN signalling transport over IP [12] uses multiple components, including a common signalling transport protocol and an adaptation module to support the services expected by a particular SCN signalling protocol from its underlying protocol layer. Within the framework architecture, this document defines an MTP3-User adaptation module suitable for supporting the transfer of messages of any protocol layer that is identified to the MTP Level 3 as an MTP User. The list of these protocol layers includes but is not limited to ISDN User Part (ISUP) [1,2,3], Signalling Connection Control Part (SCCP) [4,5,6], and Telephone User Part (TUP) [13]. TCAP [14,15,16] or RANAP [16] messages are transferred transparently by the M3UA protocol as SCCP payload, as they are SCCP-User protocols. It is recommended that M3UA use the services of the Stream Control Transmission Protocol (SCTP) [18] as the underlying reliable common signalling transport protocol. This is to take advantage of various SCTP features, such as: - Explicit packet-oriented delivery (not stream-oriented) - Sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages - Optional multiplexing of user messages into SCTP datagrams - Network-level fault tolerance through support of multi-homing at either or both ends of an association - Resistance to flooding and masquerade attacks - Data segmentation to conform to discovered path MTU size Under certain scenarios, such as back-to-back connections without redundancy requirements, the SCTP functions above might not be a requirement, and TCP MAY be used as the underlying common transport protocol.
Top   ToC   RFC4666 - Page 10

1.3.2. Services Provided by the M3UA Layer

The M3UA Layer at an ASP or IPSP provides the equivalent set of primitives at its upper layer to the MTP3-Users as provided by the MTP Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 services are offered remotely from an MTP3 Layer at an SGP, and not by a local MTP3 layer. The MTP3 layer at an SGP may also be unaware that its local users are actually remote user parts over M3UA. In effect, the M3UA extends access to the MTP3 layer services to a remote IP-based application. The M3UA layer does not itself provide the MTP3 services. However, in the case where an ASP is connected to more than one SG, the M3UA layer at an ASP should maintain the status of configured SS7 destinations and route messages according to the availability and congestion status of the routes to these destinations via each SG. The M3UA layer may also be used for point-to-point signalling between two IP Server Processes (IPSPs). In this case, the M3UA layer provides the same set of primitives and services at its upper layer as the MTP3. However, in this case the expected MTP3 services are not offered remotely from an SGP. The MTP3 services are provided, but the procedures to support these services are a subset of the MTP3 procedures, due to the simplified point-to-point nature of the IPSP- to-IPSP relationship.
1.3.2.1. Support for the Transport of MTP3-User Messages
The M3UA layer provides the transport of MTP-TRANSFER primitives across an established SCTP association between an SGP and an ASP or between IPSPs. At an ASP, in the case where a destination is reachable via multiple SGPs, the M3UA layer must also choose via which SGP the message is to be routed or support load balancing across the SGPs, thereby minimizing missequencing. The M3UA layer does not impose a 272-octet signalling information field (SIF) length limit as specified by the SS7 MTP Level 2 protocol [7,8,9]. Larger information blocks can be accommodated directly by M3UA/SCTP, without the need for an upper layer segmentation/ re-assembly procedure as specified in recent SCCP or ISUP versions. However, in the context of an SG, the maximum 272-octet block size must be followed when interworking to a SS7 network that does not support the transfer of larger information blocks to the final destination. This avoids potential ISUP or SCCP fragmentation requirements at the SGPs. The provisioning and configuration of the SS7 network determines the restriction placed on the maximum block
Top   ToC   RFC4666 - Page 11
   size.  Some configurations (e.g., Broadband MTP [19,20,22]) may
   permit larger block sizes.

1.3.2.2. Native Management Functions
The M3UA layer provides the capability to indicate errors associated with received M3UA messages and to notify, as appropriate, local management and/or the peer M3UA.
1.3.2.3. Interworking with MTP3 Network Management Functions
At the SGP, the M3UA layer provides interworking with MTP3 management functions to support seamless operation of the user SCN signalling applications in the SS7 and IP domains. This includes - providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is not reachable; - providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is now reachable; - providing an indication to MTP3-Users at an ASP that messages to a destination in the SS7 network are experiencing SS7 congestion; - providing an indication to the M3UA layer at an ASP that the routes to a destination in the SS7 network are restricted; and - providing an indication to MTP3-Users at an ASP that a MTP3-User peer is unavailable. The M3UA layer at an ASP keeps the state of the routes to remote SS7 destinations and may initiate an audit of the availability and the restricted or the congested state of remote SS7 destinations. This information is requested from the M3UA layer at the SGP. The M3UA layer at an ASP may also indicate to the SG that the M3UA layer itself or the ASP or the ASP's Host is congested.
1.3.2.4. Support for the Management of SCTP Associations between the SGP and ASPs
The M3UA layer at the SGP maintains the availability state of all configured remote ASPs, to manage the SCTP Associations and the traffic between the M3UA peers. Also, the active/inactive and congestion state of remote ASPs is maintained. The M3UA layer MAY be instructed by local management to establish an SCTP association to a peer M3UA node. This can be achieved using the
Top   ToC   RFC4666 - Page 12
   M-SCTP_ESTABLISH primitives (see Section 1.6.3 for a description of
   management primitives) to request, indicate, and confirm the
   establishment of an SCTP association with a peer M3UA node.  In order
   to avoid redundant SCTP associations between two M3UA peers, one side
   (client) SHOULD be designated to establish the SCTP association, or
   M3UA configuration information maintained to detect redundant
   associations (e.g., via knowledge of the expected local and remote
   SCTP endpoint addresses).

   Local management MAY request from the M3UA layer the status of the
   underlying SCTP associations using the M-SCTP_STATUS request and
   confirm primitives.  Also, the M3UA MAY autonomously inform local
   management of the reason for the release of an SCTP association,
   determined either locally within the M3UA layer or by a primitive
   from the SCTP.

   Also, the M3UA layer MAY inform the local management of the change in
   status of an ASP or AS.  This MAY be achieved using the M-ASP_STATUS
   request or M-AS_STATUS request primitives.

1.3.2.5. Support for the Management of Connections to Multiple SGPs
As shown in Figure 1, an ASP may be connected to multiple SGPs. In such a case, a particular SS7 destination may be reachable via more than one SGP and/or SG; i.e., via more than one route. As MTP3 users only maintain status on a destination and not on a route basis, the M3UA layer must maintain the status (availability, restriction, and/or congestion of route to destination) of the individual routes, derive the overall availability or congestion status of the destination from the status of the individual routes, and inform the MTP3 users of this derived status whenever it changes.


(page 12 continued on part 2)

Next Section