Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.501  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.4…   4.4.3…   4.5…   4.5.3…   4.6…   4.7…   4.9…   5…   5.2…   5.3   5.4…   5.5…   5.6…   6…   6.2…   6.3…   6.4…   7…   8…   8.2.9…   8.3…   9…   A…   D…

 

4.6  Network slicingWord‑p. 76

4.6.1  General

The 5GS supports network slicing as described in TS 23.501. Within a PLMN or SNPN, a network slice is identified by an S-NSSAI, which is comprised of a slice/service type (SST) and a slice differentiator (SD). Inclusion of an SD in an S-NSSAI is optional. A set of one or more S-NSSAIs is called the NSSAI. The following NSSAIs are defined in TS 23.501:
  1. configured NSSAI;
  2. requested NSSAI;
  3. allowed NSSAI;
  4. subscribed S-NSSAIs; and
  5. pending NSSAI.
The following NSSAIs are defined in the present document:
  1. rejected NSSAI for the current PLMN or SNPN;
  2. rejected NSSAI for the current registration area; and
  3. rejected NSSAI for the failed or revoked NSSAA.
In roaming scenarios, rejected NSSAI for the current PLMN or SNPN, or rejected NSSAI for the current registration area also contains a set of mapped HPLMN S-NSSAI(s) if available and the S-NSSAI(s) included in the rejected NSSAI for the failed or revoked NSSAA is HPLMN S-NSSAI(s).
In case of a PLMN, a serving PLMN may configure a UE with the configured NSSAI per PLMN. In addition, the HPLMN may configure a UE with a single default configured NSSAI and consider the default configured NSSAI as valid in a PLMN for which the UE has neither a configured NSSAI nor an allowed NSSAI. In case of an SNPN, the SNPN may configure a UE with a configured NSSAI applicable to the SNPN.
The allowed NSSAI and the rejected NSSAI for the current registration area are managed per access type independently, i.e. 3GPP access or non-3GPP access, and is applicable for the registration area. If the UE does not have a valid registration area, the rejected NSSAI for the current registration area is applicable to the tracking area on which it was received. If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, the allowed NSSAI and the rejected NSSAI for the current registration area are applicable to these PLMNs in this registration area.
The allowed NSSAI that is associated with a registration area containing TAIs belonging to different PLMNs, which are equivalent PLMNs, can be used to form the requested NSSAI for any of the equivalent PLMNs when the UE is outside of the registration area where the allowed NSSAI was received.
When the network slice-specific authentication and authorization procedure is to be initiated for one or more S-NSSAIs in the requested NSSAI, these S-NSSAI(s) will be included in the pending NSSAI. When the network slice-specific authentication and authorization procedure is completed for an S-NSSAI that has been in the pending NSSAI, the S-NSSAI will be moved to the allowed NSSAI or rejected NSSAI depending on the outcome of the procedure and communicated to the UE. The pending NSSAI is managed regardless of access type i.e. the pending NSSAI is applicable to both 3GPP access and non-3GPP access for the current PLMN even if sent over only one of the accesses. If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, the pending NSSAI is applicable to these PLMNs in this registration area.
The rejected NSSAI for the current PLMN or SNPN is applicable for the whole registered PLMN or SNPN. The AMF shall only send a rejected NSSAI for the current PLMN when the registration area consists of TAIs that only belong to the registered PLMN. If the UE receives a rejected NSSAI for the current PLMN, and the registration area also contains TAIs belonging to different PLMNs, the UE shall treat the received rejected NSSAI for the current PLMN as applicable to the whole registered PLMN.
The rejected NSSAI for the failed or revoked NSSAA includes one or more S-NSSAIs that have failed the network slice-specific authentication and authorization or for which the authorization have been revoked, and are applicable for the whole registered PLMN or SNPN.
Up

4.6.2  Mobility management aspectsWord‑p. 77

4.6.2.1  General

Upon registration to a PLMN or SNPN (except for the registration procedure for periodic registration update), the UE shall send to the AMF the requested NSSAI which includes one or more S-NSSAIs of the allowed NSSAI for the PLMN or SNPN or the configured NSSAI and corresponds to the network slice(s) to which the UE intends to register with, if:
  1. the UE has a configured NSSAI for the current PLMN or SNPN;
  2. the UE has an allowed NSSAI for the current PLMN or SNPN; or
  3. the UE has neither allowed NSSAI for the current PLMN nor configured NSSAI for the current PLMN and has a default configured NSSAI. In this case the UE indicates to the AMF that the requested NSSAI is created from the default configured NSSAI.
Other than S-NSSAIs contained in the NSSAIs described above, the requested NSSAI can be formed based on the S-NSSAI(s) available in the UE (see subclause 5.5.1.3.2 for further details). In roaming scenarios, the UE shall also provide the mapped S-NSSAI(s) for the requested NSSAI, if available. The AMF verifies if the requested NSSAI is permitted based on the subscribed S-NSSAIs in the UE subscription and optionally the mapped S-NSSAI(s) provided by the UE, and if so then the AMF shall provide the UE with the allowed NSSAI for the PLMN or SNPN, and shall also provide the UE with the mapped S-NSSAI(s) for the allowed NSSAI for the PLMN if available. The AMF shall ensure that there are not two or more S-NSSAIs of the allowed NSSAI which are mapped to the same S-NSSAI of the HPLMN. In case all the S-NSSAIs included in the requested NSSAI are either rejected for the current PLMN or rejected for the current registration area, or the requested NSSAI was not included by the UE and there is no subscribed S-NSSAI(s) marked as default, the AMF may reject the registration request.
The set of network slice(s) for a UE can be changed at any time while the UE is registered to a PLMN or SNPN, and the change may be initiated by the network or the UE. In this case, the allowed NSSAI and associated registration area may be changed during the registration procedure or the generic UE configuration update procedure. In addition, using the generic UE configuration update procedure, the network may trigger the registration procedure in order to update the allowed NSSAI.
The UE in NB-N1 mode does not include the requested NSSAI during the registration procedure if the 5GS registration type IE indicates "mobility registration updating", procedure is not initiated to change the slice(s) that the UE is currently registered to, and the UE is still in the current registration area. The AMF does not include the allowed NSSAI during a registration procedure with the 5GS registration type IE indicating "mobility registration updating" except if the allowed NSSAI has changed for the UE. The UE considers the last received allowed NSSAI as valid until the UE receives a new allowed NSSAI.
Up

4.6.2.2  NSSAI storageWord‑p. 78
If available, the configured NSSAI(s) shall be stored in a non-volatile memory in the ME as specified in annex C.
The allowed NSSAI(s) should be stored in a non-volatile memory in the ME as specified in annex C.
Each of the configured NSSAI stored in the UE is a set composed of at most 16 S-NSSAIs. Each of the allowed NSSAI stored in the UE is a set composed of at most 8 S-NSSAIs and is associated with a PLMN identity or SNPN identity and an access type. Each of the configured NSSAI except the default configured NSSAI, and the rejected NSSAI is associated with a PLMN identity or SNPN identity. Each of the pending NSSAI stored in the UE is a set composed of at most 16 S-NSSAIs and is associated with a PLMN identity or SNPN identity. The S-NSSAI(s) in the rejected NSSAI for the current registration area are further associated with one or more tracking areas where the rejected S-NSSAI(s) is not available. The S-NSSAI(s) in the rejected NSSAI for the current PLMN or SNPN shall be considered rejected for the current PLMN or SNPN regardless of the access type. The S-NSSAI(s) in the rejected NSSAI for the failed or revoked NSSAA shall be considered rejected for the current PLMN regardless of the access type. There shall be no duplicated PLMN identities or SNPN identities inside each of the list of configured NSSAI(s), allowed NSSAI(s), rejected NSSAI(s) for the current PLMN or SNPN, and rejected NSSAI(s) for the current registration area.
The UE stores NSSAIs as follows:
a)
The configured NSSAI shall be stored until a new configured NSSAI is received for a given PLMN or SNPN. The network may provide to the UE the mapped S-NSSAI(s) for the new configured NSSAI which shall also be stored in the UE. When the UE is provisioned with a new configured NSSAI for a PLMN or SNPN, the UE shall:
  1. replace any stored configured NSSAI for this PLMN or SNPN with the new configured NSSAI for this PLMN or SNPN;
  2. delete any stored mapped S-NSSAI(s) for the configured NSSAI and, if available, store the mapped S-NSSAI(s) for the new configured NSSAI;
  3. delete any stored allowed NSSAI for this PLMN or SNPN and, if available, the stored mapped S-NSSAI(s) for the allowed NSSAI, if the UE received the new configured NSSAI for this PLMN or SNPN and the Configuration update indication IE with the Registration requested bit set to "registration requested", in the same CONFIGURATION UPDATE COMMAND message but without any new allowed NSSAI for this PLMN or SNPN included;
  4. delete any stored rejected NSSAI for the current PLMN or SNPN, rejected NSSAI for the current registration area and rejected NSSAI for the failed or revoked NSSAA; and
  5. delete any stored pending NSSAI, if not already included in the new configured NSSAI for the current PLMN or SNPN;
If the UE receives an S-NSSAI associated with a PLMN ID from the network during the PDN connection establishment procedure in EPS as specified in TS 24.301 or via ePDG as specified in TS 24.302, the UE may store the received S-NSSAI in the configured NSSAI for the PLMN identified by the PLMN ID associated with the S-NSSAI, if not already in the configured NSSAI;
The UE may continue storing a received configured NSSAI for a PLMN and associated mapped S-NSSAI(s), if available, when the UE registers in another PLMN.
b)
The allowed NSSAI shall be stored until a new allowed NSSAI is received for a given PLMN or SNPN, or until the CONFIGURATION UPDATE COMMAND message with the Registration requested bit of the Configuration update indication IE set to "registration requested" is received and contains no other parameters (see subclauses 5.4.4.2 and 5.4.4.3). The network may provide to the UE the mapped S-NSSAI(s) for the new allowed NSSAI (see subclauses 5.5.1.2 and 5.5.1.3) which shall also be stored in the UE. When a new allowed NSSAI for a PLMN or SNPN is received, the UE shall:
  1. replace any stored allowed NSSAI for this PLMN or SNPN with the new allowed NSSAI for this PLMN or SNPN;
  2. delete any stored mapped S-NSSAI(s) for the allowed NSSAI and, if available, store the mapped S-NSSAI(s) for the new allowed NSSAI;
  3. remove from the stored rejected NSSAI for the current PLMN or SNPN and the rejected NSSAI for the current registration area, the S-NSSAI(s), if any, included in the new allowed NSSAI for the current PLMN or SNPN;
  4. remove from the stored rejected NSSAI for the failed or revoked NSSAA, the S-NSSAI(s), if any, included in the new allowed NSSAI for the current PLMN or SNPN (if the UE is not roaming) or the mapped S-NSSAI(s) for the new allowed NSSAI for the current PLMN or SNPN (if the UE is roaming); and
  5. remove from the stored pending NSSAI, one or more S-NSSAIs, if any, included in the new allowed NSSAI for the current PLMN or SNPN and its equivalent PLMN(s) (if the UE is not roaming) or the mapped S-NSSAI(s) for the new allowed NSSAI for the current PLMN or SNPN and its equivalent PLMN(s) (if the UE is roaming).
If the UE receives the CONFIGURATION UPDATE COMMAND message with the Registration requested bit of the Configuration update indication IE set to "registration requested" and contains no other parameters (see subclauses 5.4.4.2 and 5.4.4.3), the UE shall delete any stored allowed NSSAI for this PLMN or SNPN, and delete any stored mapped S-NSSAI(s) for the allowed NSSAI, if available;
c)
When the UE receives the S-NSSAI(s) included in rejected NSSAI in the REGISTRATION ACCEPT message, the REGISTRATION REJECT message, the DEREGISTRATION REQUEST message or in the CONFIGURATION UPDATE COMMAND message, the UE shall:
  1. store the S-NSSAI(s) into the rejected NSSAI based on the associated rejection cause(s);
  2. remove from the stored allowed NSSAI for the current PLMN or SNPN, the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the current PLMN or SNPN, for each and every access type; and
    2. rejected NSSAI for the current registration area, associated with the same access type;
  3. remove from the stored mapped S-NSSAI(s) for the allowed NSSAI if available, the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the failed or revoked NSSAA, for each and every access type;
  4. remove from the stored pending NSSAI for the current PLMN or SNPN and its equivalent PLMN(s), the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the current PLMN or SNPN, for each and every access type; and
    2. rejected NSSAI for the current registration area, associated with the same access type; and
  5. remove from the stored mapped S-NSSAI(s) for the pending NSSAI, the S-NSSAI(s), if any, included in the:
    1. rejected NSSAI for the failed or revoked NSSAA, for each and every access type.
When the UE:
  1. deregisters with the current PLMN using explicit signalling or enters state 5GMM-DEREGISTERED following an unsuccessful registration for 5GMM causes other than #62 "No network slices available" for the current PLMN;
  2. successfully registers with a new PLMN; or
  3. enters state 5GMM-DEREGISTERED following an unsuccessful registration with a new PLMN;
and the UE is not registered with the current PLMN over another access, the rejected NSSAI for the current PLMN and the rejected NSSAI for the failed or revoked NSSAA shall be deleted.
When the UE:
  1. deregisters over an access type;
  2. successfully registers in a new registration area over an access type; or
  3. enters state 5GMM-DEREGISTERED or 5GMM-REGISTERED following an unsuccessful registration in a new registration area over an access type;
the rejected NSSAI for the current registration area corresponding to the access type shall be deleted;
d)
When the UE receives the pending NSSAI in the REGISTRATION ACCEPT message, the UE shall replace any stored pending NSSAI for this PLMN or SNPN with the new pending NSSAI received in the REGISTRATION ACCEPT message for this PLMN or SNPN.
If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, then for each of the equivalent PLMNs, the UE shall replace any stored pending NSSAI with the pending NSSAI received in the registered PLMN.
When the UE:
  1. deregisters with the current PLMN using explicit signalling or enters state 5GMM-DEREGISTERED for the current PLMN;
  2. successfully registers with a new PLMN;
  3. enters state 5GMM-DEREGISTERED following an unsuccessful registration with a new PLMN; or
  4. successfully initiates an attach or tracking area update procedure in S1 mode and the UE is operating in single-registration mode;
and the UE is not registered with the current PLMN over another access, the pending NSSAI for the current PLMN and its equivalent PLMN(s) shall be deleted; and
e)
In case of a PLMN, when the UE receives the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed" in the REGISTRATION ACCEPT message or in the CONFIGURATION UPDATE COMMAND message, the UE shall delete the network slicing information for each of the PLMNs that the UE has slicing information stored for (excluding the current PLMN). The UE shall not delete the default configured NSSAI. Additionally, the UE shall update the network slicing information for the current PLMN (if received) as specified above in bullets a), b), c) and e).
Up

4.6.2.3  Provision of NSSAI to lower layers in 5GMM-IDLE modeWord‑p. 80
The UE NAS layer may provide the lower layers with an NSSAI (either requested NSSAI or allowed NSSAI) when the UE in 5GMM-IDLE mode sends an initial NAS message.
The AMF may indicate, via the NSSAI inclusion mode IE of a REGISTRATION ACCEPT message, an NSSAI inclusion mode in which the UE shall operate over the current access within the current PLMN or SNPN, if any (see subclauses 5.5.1.2.4 and 5.5.1.3.4), where the NSSAI inclusion mode is chosen among the following NSSAI inclusion modes described in table 4.6.2.3.1.
Initial NAS message
NSSAI inclusion mode A
NSSAI inclusion mode B
NSSAI inclusion mode C
NSSAI inclusion mode D

REGISTRATION REQUEST message:
  1. including the 5GS registration type IE set to "initial registration"
Requested NSSAI
Requested NSSAI
Requested NSSAI
No NSSAI
REGISTRATION REQUEST message:
  1. including the 5GS registration type IE set to "mobility registration updating"; and
  2. initiated by case other than case g) or n) in subclause 5.5.1.3.2
Requested NSSAI
Requested NSSAI
Requested NSSAI
No NSSAI
REGISTRATION REQUEST message:
  1. including the 5GS registration type IE set to "mobility registration updating"; and
  2. initiated by case g) or n) in subclause 5.5.1.3.2
Allowed NSSAI
Allowed NSSAI
No NSSAI
No NSSAI
REGISTRATION REQUEST message:
  1. including the 5GS registration type IE set to "periodic registration updating"
Allowed NSSAI
Allowed NSSAI
No NSSAI
No NSSAI
SERVICE REQUEST message
Allowed NSSAI
See NOTE 1
No NSSAI
No NSSAI


The UE shall store the NSSAI inclusion mode:
  1. indicated by the AMF, if the AMF included the NSSAI inclusion mode IE in the REGISTRATION ACCEPT message; or
  2. decided by the UE, if the AMF did not include the NSSAI inclusion mode IE in the REGISTRATION ACCEPT message;
together with the identity of the current PLMN or SNPN and access type in a non-volatile memory in the ME as specified in annex C.
The UE shall apply the NSSAI inclusion mode received in the REGISTRATION ACCEPT message over the current access within the current PLMN and its equivalent PLMN(s) or the current SNPN, if any, in the current registration area.
When a UE performs a registration procedure to a PLMN which is not a PLMN in the current registration area or an SNPN, if the UE has no NSSAI inclusion mode for the PLMN or the SNPN stored in a non-volatile memory in the ME, the UE shall provide the lower layers with:
  1. no NSSAI if the UE is performing the registration procedure over 3GPP access; or
  2. requested NSSAI if the UE is performing the registration procedure over non-3GPP access.
When a UE performs a registration procedure after an inter-system change from S1 mode to N1 mode, if the UE has no NSSAI inclusion mode for the PLMN stored in a non-volatile memory in the ME and the registration procedure is performed over 3GPP access, the UE shall not provide the lower layers with any NSSAI over the 3GPP access.
Up

4.6.2.4  Network slice-specific authentication and authorization |R16|Word‑p. 82
The UE and network may support network slice-specific authentication and authorization.
A serving PLMN shall perform network slice-specific authentication and authorization for the S-NSSAI(s) of the HPLMN which are subject to it based on subscription information. The UE shall indicate whether it supports network slice-specific authentication and authorization in the 5GMM Capability IE in the REGISTRATION REQUEST message as specified in subclauses 5.5.1.2.2 and 5.5.1.3.2.
The upper layer stores an association between each S-NSSAI and its corresponding credentials for the network slice-specific authentication and authorization.
The network slice-specific authentication and authorization procedure shall not be performed unless:
  1. the primary authentication and key agreement procedure as specified in the subclause 5.4.1 has successfully been completed; and
  2. the initial registration procedure or the mobility and periodic registration update procedure has been completed.
The AMF informs the UE about S-NSSAI(s) for which network slice-specific authentication and authorization will be performed in the pending NSSAI. The AMF informs the UE about S-NSSAI(s) for which NSSAA procedure is completed as success in the allowed NSSAI. The AMF informs the UE about S-NSSAI(s) for which NSSAA procedure is completed as failure in the rejected NSSAI for the failed or revoked NSSAA. The AMF stores and handles allowed NSSAI, pending NSSAI, rejected NSSAI, and 5GS registration result in the REGISTRATION ACCEPT message according to subclauses 5.5.1.2.4 and 5.5.1.3.4.
To perform network slice-specific authentication and authorization for an S-NSSAI, the AMF invokes an EAP-based network slice-specific authentication and authorization procedure for the S-NSSAI, see subclause 5.4.7 and TS 23.502 using the EAP framework as described in TS 33.501.
The AMF updates the allowed NSSAI and the rejected NSSAI using the generic UE configuration update procedure as specified in the subclause 5.4.4 after the network slice-specific authentication and authorization procedure is completed.
The AMF shall send the pending NSSAI containing all S-NSSAIs for which the network slice-specific authentication and authorization procedure will be performed or is ongoing in the REGISTRATION ACCEPT message. The AMF shall also include in the REGISTRATION ACCEPT message the allowed NSSAI containing one or more S-NSSAIs from the requested NSSAI which are allowed by the AMF and for which network slice-specific authentication and authorization is not required, if any.The network slice-specific authentication and authorization procedure or the network slice-specific authorization revocation procedure can be invoked by the network for a UE supporting NSSAA at any time. After the network performs the network slice-specific re-authentication and re-authorization procedure or network slice-specific authorization revocation procedure:
  1. if network slice-specific authentication and authorization fails or network slice-specific authorization is revoked for some but not all S-NSSAIs in the allowed NSSAI, the AMF updates the allowed NSSAI and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the subclause 5.4.4 and inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked;
  2. if network slice-specific authentication and authorization fails or network slice-specific authorization is revoked for all S-NSSAIs in the allowed NSSAI but there are one or more subscribed S-NSSAIs marked as default which are not subject to network slice-specific authentication and authorization or for which the network slice-specific authentication and authorization has been successfully performed, the AMF updates the allowed NSSAI containing these subscribed S-NSSAIs marked as default and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the subclause 5.4.4. The AMF shall also inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked; or
  3. if network slice-specific authentication and authorization fails or network slice-specific authorization is revoked for all S-NSSAIs in the allowed NSSAI and all subscribed S-NSSAIs marked as default are subject to network slice-specific authentication and authorization, then AMF performs the network-initiated de-registration procedure and includes the rejected NSSAI in the DEREGISTRATION REQUEST message as specified in the subclause 5.5.2.3 except when the UE has an emergency PDU session established or the UE is establishing an emergency PDU session. In this case the AMF shall send the CONFIGURATION UPDATE COMMAND message containing rejected NSSAI and inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked. After the emergency PDU session is released, the AMF performs the network-initiated de-registration procedure as specified in the subclause 5.5.2.3.
When performing the network slice-specific re-authentication and re-authorization procedure if the S-NSSAI is included in the allowed NSSAI for both 3GPP and non-3GPP accesses, and the UE is registered to both 3GPP and non-3GPP accesses in the same PLMN, then the AMF selects an access type to perform network slice-specific authentication and authorization based upon operator policy.
If network slice-specific authorization is revoked for an S-NSSAI that is in the current allowed NSSAI for an access type, the AMF shall:
  1. provide a new allowed NSSAI, excluding the S-NSSAI for which the network slice-specific authorization is revoked; and
  2. provide a new rejected NSSAI for the failed or revoked NSSAA, including the S-NSSAI for which the network slice-specific authorization is revoked, with the reject cause "S-NSSAI is not available due to the failed or revoked network slice-specific authentication and authorization",
to the UE using the generic UE configuration update procedure as specified in the subclause 5.4.4 and inform the SMF to release all PDU sessions associated with the S-NSSAI for which the network slice-specific authorization is revoked for this access type.
If the UE requests the establishment of a new PDU session or the modification of a PDU session for an S-NSSAI for which the AMF is performing network slice-specific authentication and authorization procedure, the AMF may determine to not forward the 5GSM message to the SMF as described in subclause 5.4.5.2.4.
Up

4.6.3  Session management aspectsWord‑p. 83
In order to enable PDU transmission in a network slice, the UE may request establishment of a PDU session in a network slice towards a data network (DN) which is associated with an S-NSSAI and a data network name (DNN) if there is no established PDU session adequate for the PDU transmission. The S-NSSAI included is part of allowed NSSAI of the serving PLMN or SNPN, which is an S-NSSAI value valid in the serving PLMN or SNPN, and in roaming scenarios the mapped S-NSSAI is also included for the PDU session if available. See subclause 6.4.1 for further details. The UE determines whether to establish a new PDU session or use one of the established PDU session(s) based on the URSP rules which include S-NSSAIs, if any (see subclause 6.2.9), or based on UE local configuration, as described in subclause 4.2.2 of TS 24.526.
Up


Up   Top   ToC