WiMAX: Technology for Broadband Wireless Access

11.6 Network Entry

Systems must follow a list of procedures for entering and registering a new SS or, more generally, a new node to the network. The network entry procedures described in this section apply only to the PMP topology. The network entry procedure for Mesh (not included in WiMAX profiles for the moment) is described in the standard.

Figure 11.18 shows an illustration of the network entry sequence of procedures. The sequence of procedures for network entry is described in the following:

  1. Scan for a downlink channel and establish synchronisation with the BS. On initialisation or after signal loss, the SS must acquire a downlink channel. The SS has nonvolatile storage in which the last operational parameters are stored. It first tries to reacquire this downlink channel. If this fails, the SS begins to scan the possible channels of the downlink frequency band of operation continuously until it finds a valid downlink signal.

    The frame start preamble is a repetitive well-known pattern and the SS may use it in order to synchronise timing and frequency parameters with the BS. The BS may further employ active scanning or diversity methods to speed up and enhance the process of downlink synchronisation. At this stage, the SS needs the DL-MAP, DCD, UCD and UL-MAP messages.

  2. Synchronisation. The SS MAC searches for the DL-MAP message. The SS achieves MAC synchronisation once it has received at least one DL-MAP message. An SS MAC remains in synchronisation as long as it continues to successfully receive the DL-MAP and DCD messages of the downlink channel. If the standard-defined Lost DL-MAP interval is elapsed without a valid DL-MAP message, an SS must try to reestablish synchronisation. The Lost DL-MAP interval (denoted T21 in the standard) is equal to 11 s, as updated in 802.16e.

    Obtain transmit (uplink) parameters from the UCD message. After synchronisation, the SS waits for a UCD message from the BS in order to obtain the set of transmission parameters needed for a possible uplink channel. UCD and uplink transmission parameters (UL-MAP) messages are transmitted periodically by the BS (see Chapters 9 and 10).

  3. Perform initial ranging. The main objective of initial ranging is the adjustment of each SS timing offset and power parameters in the initialisation phase. Initial ranging (see Section 11.1 at the beginning of this chapter for details of this procedure) takes place when an SS wishes to enter a network. The SS sends an RNG-REQ message in a contention-based initial ranging interval. The CID field is set to the noninitialized SS value (initial ranging CID=0).

    The CIDs for the basic and primary management connections are assigned during this initial ranging procedure (see Section 11.1.2)

  4. Negotiate basic capabilities. This is the phase where SS and BS exchange their supported parameters. After completion of ranging, the SS informs the BS of its basic capabilities by transmitting an SBC-REQ (SS Basic Capability Request) message with its capabilities. The SBC-REQ message is transmitted by the SS during the initialisation (Network Entry) phase to inform the BS of its basic capabilities. The following parameters are included in the basic capabilities request:

    • Bandwidth allocation: support for full frequency duplexing if each of the H-FDD and FDD is supported (for a TDD profile there is no alternative).

    • Physical parameters: maximum transmit power (for each of the four possible modulations: BPSK, QPSK, 16-QAM and 64-QAM), current transmit power (used for the burst that carries the SBC-REQ Message), focused contention support (OFDM PHY specific), SS demodulator support (64-QAM, CTC, BTC, STC and AAS), SS modulator support (64-QAM, BTC, CTC, subchannelisation and focused contention BW request), SS focused contention support (see Chapter 10) and SS TC sublayer support, the FFT size (OFDMA PHY specific), permutations support, MIMO parameters support, AAS parameters support, security parameters support, power control parameters support, power save parameters support, handover parameters support, etc.

    • Size of FSN (Fragment Sequence Number) values used when forming MAC PDUs on non-ARQ connections, such as the ability to receive requests piggybacked with data, etc.

    The BS responds with an SBC-RSP (SS Basic Capability Response) message with the intersection of the SS and BS capabilities. The SBC-RSP message is transmitted by the BS in response to a received SBC-REQ. Its role is to confirm or not the proposed parameters in the SBC-REQ. If the BS does not recognise an SS capability, it may return this as ‘off’ in the SBC-RSP.

  5. Authorise the SS and perform keys exchange. Next, the SS has to exchange secure keys which is part of the authentication mechanism. This is realised through the PKM protocol. The SS sends a PKM-REQ (Privacy Key Management Request) message to the BS. The BS responds with a PKM-RSP (Privacy Key Management Response) message. This exchange is detailed in Chapter 15.

  6. Perform registration. Registration is the process by which the SS is allowed entry into the network and, specifically, a managed SS receives its secondary management CID and thus becomes a manageable SS. This part of the Network Entry process is detailed in Section 11.6.1 below.

    Basic MAC and primary MAC management connections are established during the SS initial ranging (see above). These connections are not secure. A secondary management connection is established when the authorisation procedure is finished during SS registration. This connection is used for the IP connectivity establishment and for the Trivial File Transfer Protocol (TFTP) file configuration loading (see the following steps). The secondary management connection is secure. Figure 11.19 illustrates the sequence between initial ranging and registration of the SS Network Entry process.

    Figure 11.18: SS Network Entry procedures. (Figure by G. Assaf and L. Nuaymi.)

    Figure 11.19: Initial ranging until registration part of the SS Network Entry process. This figure shows the case of a managed SS, i.e. having a secondary management connection

    Implementation of phases 7, 8 and 9 at the SS is optional. These phases have to be performed only if the SS has indicated in the REG-REQ message that it is a managed SS.

  7. Establish IP connectivity. At this point, the SS uses the Dynamic Host Configuration Protocol (DHCP) [17],[18] mechanisms in order to obtain an IP address, from the DHCP server and any other parameters needed to establish IP connectivity. If the SS has a configuration file (containing, for example, tables of QoS filters), the DHCP response contains the name of a file that contains further configuration parameters. The IP parameters of the SS are set up based on the DHCP server response. Establishment of IP connectivity is performed on the SS secondary management connection. The secondary management messages are carried in IP datagrams (see Section 5.2.6 of the standard for IP CS PDU formats).

  8. Establish the time of day. The SS needs to have the current date and time from the BS. This is required for time-stamping logged events. It can be needed, for example, for some encryption algorithms. Accuracy is to the nearest second. The protocol by which the SS retrieves the time of day from a time server through the BS (no authentication is needed) is defined in IETF RFC 868 [19], which gives the number of seconds starting from year 1900, on 4 bytes. The request and response are transferred using the User Datagram Protocol (UDP).

    The time retrieved from the server, the Universal Coordinated Time (UTC), must be combined with the time offset received from the DHCP response to create the SS current local time. Establishment of the time of day is performed on the SS secondary management connection.

    9. Transfer operational parameters. After the DHCP procedure is successful, the SS downloads its configuration file using the Trivial File Transfer Protocol (TFTP) [20] on the SS secondary management connection, as shown in Figure 11.20, if specified in the DHCP response (the TFTP configuration file server is specified in the DHCP response). The TFTP is a rather simple protocol used to transfer files, working over the UDP.

    Figure 11.20: Transfer of the SS configuration file (operational procedure)

    When the configuration file download has been completed successfully, the SS notifies the BS by transmitting a TFTP-CPLT (Config File TFTP Complete Message) MAC management message on the SS primary management connection. Transmissions of TFTP-CPLT messages by the SS continue periodically until a TFTP-RSP (Config File TFTP Complete Response) MAC management message is received with an ‘OK’ response from the BS or the SS terminates retransmission due to retry exhaustion. The SS configuration file includes many system informations such as boot information.

  9. Set up connections. After the transfer of operational parameters (for a managed SS) or after registration (for an unmanaged SS), the BS sends DSA-REQ messages to the SS to set up connections for preprovisioned service flows belonging to the SS. The SS responds with DSA-RSP messages as detailed in Section 11.3 above.

11.6.1 Registration

Registration is then the process by which the SS is allowed entry into the network and, specifically, a managed SS receives its secondary management CID and thus becomes a manageable SS. To register with a BS, the SS sends the REG-REQ MAC management message to the BS. The general format of the REG-REQ message is shown in Figure 11.21.

Figure 11.21: General format of the REG-REQ message. Not all possible TLV encodings are represented in this figure

In the REG-REQ message, the SS indicates the following:

The BS responds with a REG-RSP (REGistration RESponse) message. For an SS that has indicated being a managed SS in its REG-REQ message, the REG-RSP message includes the BS-allocated secondary management CID. The general format of the REG-RSP message is shown in Figure 11.22. The response field indicates message authentication success or failure. Message authentication verification is based on HMAC or CMAC (see Chapter 15 for message authentication).

Figure 11.22: General format of the REG-RSP message. Not all possible TLV encodings are represented in this figure

In this message, the BS indicates the mode of SS management operation, the MAC version used in the network, Vendor ID Encoding of the BS, response to the REG-REQ indication of whether or not the requester wishes to accept IP-based traffic on the secondary management connection, once the initialisation process has been completed. Also included in the REG-RSP is a response to the capabilities of the requesting SS provided in the REG-REQ (if the request included capabilities information) if they can be used. If a capability is not recognised, the response indicates that this capability will not be used by the requesting SS. Capabilities returned in the REG-RSP cannot be set to require greater capability of the requesting SS than indicated in the REG-REQ.

11.6.2 De-registration and Re-registration

The DREG-CMD (De/Re-register Command) MAC management message is transmitted by the BS to force the SS to change its access state: stop using the current channel, use it with restrictions, return to normal mode, etc. The DREG-CMD can be unsolicited or in response to an SS DREG-REQ message. The DREG-REQ SS de-registration MAC management is sent by the SS to the BS in order to notify the BS of the SS de-registration request from the BS and the network.

11.6.3 SS Reset

The BS may transmit the RES-CMD (Reset Command) MAC management message on an SS Basic CID to force this SS to reset itself, reinitialise its MAC and then repeat initial system access. This message may be used if an SS does not respond to the BS or if the BS detects continued abnormalities in the transmissions of an SS.

The main parameter of RES-CMD is the message authentication. This is done with the HMAC key sequence number concatenated with an HMAC-Digest (see Chapter 15).

[17]IETF RFC 2131, Dynamic Host Configuration Protocol (DHCP), R Droms, March 1997.

[18]IETF RFC 2132, DHCP options and BOOTP Vendor Extensions, S. Alexander and R. Droms, March 1997.

[19]IETF RFC 868, Time Protocol, J. Postel and K. Harrenstien, May 1983.

[20]IETF RFC 1350, The TFTP Protocol (Revision 2), K. Sollins, July 1992.

Related

Категории