A wireless transmit / receive unit (WTRU) and method of implementing the same

Abstract

A wireless transmit / receive unit (WTRU) and method of implementing the same are disclosed. One exemplary method includes sending, by the WTRU, a service request (SR) to change the WTRU to a connected mode; receiving, by the WTRU, a command including information indicating a new or changed type of network part associated with a service serving the WTRU and one or more candidate network parts associated with the service; determining whether a first network part of the candidate network parts associated with the service is rejected; receiving, by the WTRU, a connection release message; and sending, by the WTRU, a registration request including information indicating a request for the first network part associated with the service serving the WTRU in the event that the first network part is not rejected.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 201680064175.6, filed on October 31, 2016, entitled "Method for Selecting Enhanced Dedicated Core Network (DNC), Core Network Entity and Wireless Transmit / Receive Unit (WTRU)".

[0002] Cross-references to related applications

[0003] This application claims priority to U.S. Provisional Application No:62 / 252,117, filed November 6, 2015, the contents of which are incorporated herein by reference. Technical Field

[0004] This invention relates to the field of wireless communication, and more particularly to methods, apparatus, and systems using enhanced DCN selection. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following specific embodiments given in conjunction with the accompanying drawings. The figures in these drawings, as with the specific embodiments, are exemplary. Thus, the figures and detailed description are not to be considered limiting, and other equivalent and effective examples are feasible and possible. Furthermore, the same numbers in the figures indicate the same elements, and wherein:

[0006] Figure 1 This is a system diagram illustrating an exemplary communication system in which one or more of the disclosed embodiments can be implemented;

[0007] Figure 2 It shows that it can be shown Figure 1 The diagram shows an example of a wireless transmit / receive unit (WTRU) used in a communication system.

[0008] Figure 3 It shows that it can be shown Figure 1 The diagram shows an example radio access network and another example core network (CN) used in a communication system.

[0009] Figure 4 It shows that it can be shown Figure 1 The system diagram shown is of another example of a radio access network and another example of a CN used in a communication system;

[0010] Figure 5 It shows that it can be shown Figure 1 The diagram shows another example of a radio access network and another example of a CN used in a communication system.

[0011] Figure 6 This is a diagram illustrating the Non-Access Stratum (NAS) message redirection process;

[0012] Figure 7 This is a diagram illustrating the DCN reselection process initiated by the Mobility Management Entity (MME) / Serving GPRS Support Node (SGSN) or Home Subscriber Service (HSS);

[0013] Figure 8 This is a block diagram illustrating typical MME behavior associated with redirection to a new CN node;

[0014] Figure 9 This is a flowchart illustrating the operations of various entities during a redirect to another CN node;

[0015] Figure 10 This is a diagram illustrating the NAS message used to initiate the redirection process;

[0016] Figure 11 This is a diagram illustrating a typical blocking process;

[0017] Figure 12 This is a flowchart illustrating a typical method implemented by a CN entity;

[0018] Figure 13 This is a flowchart illustrating another typical method implemented by a CN entity;

[0019] Figure 14 This is a flowchart illustrating a typical method implemented by a network entity;

[0020] Figure 15 This is a flowchart illustrating a typical method for implementing WTRU;

[0021] Figure 16 This is a flowchart illustrating another typical method of WTRU implementation;

[0022] Figure 17 This is a flowchart illustrating further typical methods implemented by a network or CN entity;

[0023] Figure 18 This is a flowchart illustrating a further typical approach to WTRU implementation;

[0024] Figure 19 This is a flowchart illustrating an additional typical method for implementing WTRU;

[0025] Figure 20 This is a flowchart illustrating additional typical methods implemented by network entities;

[0026] Figure 21 This is a flowchart illustrating further typical methods implemented by network entities; and

[0027] Figure 22 This is a flowchart illustrating a further typical method implemented by a network entity. Detailed Implementation

[0028] A detailed description of illustrative embodiments can now be described with reference to the accompanying drawings. However, although the invention may be described in conjunction with exemplary embodiments, it is not limited thereto, and it should be understood that other embodiments may be used, or modifications and additions may be made to the described embodiments to perform the same function of the invention without departing from the invention.

[0029] Although typical implementations are generally shown hereafter using a wireless network architecture, any number of different network architectures can be used, including networks with wired and / or wireless components.

[0030] Figure 1 This is an illustration of an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 allows multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 can employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), etc.

[0031] like Figure 1 As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, CN 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless context. For example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronic devices, and so on. WTRU 102a, 102b, 102c and 102d can be interchangeably referred to as UE.

[0032] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to facilitate access to one or more communication networks, such as CN 106 / 107 / 109, the Internet 110, and / or other networks 112, by wirelessly interfacing with at least one of WTRUs 102a, 102b, 102c, and 102d. As an example, base stations 114a and 114b may be base transceiver stations (BTS), node Bs, e-node Bs (also known as eNBs), home node Bs, home e-node Bs, site controllers, access points (APs), wireless routers, etc. Although each base station 114a and 114b is described as a single component, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network components.

[0033] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network components (not shown), such as Base Station Controller (BSC), Radio Network Controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals within a specific geographical area called a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, each transceiver corresponds to one sector of the cell. In another embodiment, base station 114a may employ Multiple-Input Multiple-Output (MIMO) technology, and multiple transceivers may be used for each sector of the cell.

[0034] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0035] More specifically, as described above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), and this technology can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0036] In another implementation, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish air interfaces 115 / 116 / 117.

[0037] In other implementations, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), GSM EDGE (GERAN), etc.

[0038] Figure 1Base station 114b can be, for example, a wireless router, home node B, home e node B, or access point, and can use any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, residence, vehicle, campus, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In another embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, base station 114b and WTRUs 102c, 102d can establish a picocell or femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). Figure 1 As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b does not necessarily need to access the Internet 110 via CN106 / 107 / 109.

[0039] RAN 103 / 104 / 105 can communicate with CN 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. For example, CN 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1 Although not shown, it should be understood that RAN 103 / 104 / 105 and / or CN 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT or a different RAT as RAN 103 / 104 / 105. For example, in addition to connecting with RAN 103 / 104 / 105 using E-UTRA radio technology, CN 106 / 107 / 109 can also communicate with other RANs (not shown) using GSM, UMTS, CDMA 2000, WiMAX, or WiFi radio technologies.

[0040] CNs 106 / 107 / 109 can also act as gateways for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Simple Old-Style Telephone Service (POTS). The Internet 110 may include a global interconnected computer network equipment system using common communication protocols, such as TCP, UDP, and / or IP from the Transmission Control Protocol (TCP) / Internet Protocol (IP) suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT or a different RAT as RAN 103 / 104 / 105.

[0041] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers communicating with different wireless networks on different wireless links). For example... Figure 1 The WTRU 102c shown can be configured to communicate with base station 114a using cellular-based radio technology, and with base station 114b using IEEE 802 radio technology.

[0042] Figure 2 This is a system diagram illustrating an example WTRU 102. (Example:) Figure 2 As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitter / receiver unit 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may also include any sub-combination of the aforementioned components.

[0043] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless context. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmit / receive unit 122. Although Figure 2 While the processor 118 and transceiver 120 are described as separate components, it should be understood that the processor 118 and transceiver 120 can be integrated into a single electronic package or chip.

[0044] Transmit / receive component 122 can be configured to transmit or receive signals destined for or from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmit / receive component 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, as an example, transmit / receive component 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmit / receive component 122 can be configured to transmit and / or receive RF and optical signals. It should be understood that transmit / receive component 122 can be configured to transmit and / or receive any combination of wireless signals.

[0045] Although Figure 2 While the transmit / receive component 122 is described as a single component, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may use MIMO technology. Therefore, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) that transmit and receive radio signals via air interfaces 115 / 116 / 117.

[0046] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving unit 122 and demodulate signals received by transmitting / receiving unit 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers enabling WTRU 102 to communicate via various RATs such as UTRA and IEEE 802.11.

[0047] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from these components. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access and store information from any type of suitable memory (e.g., non-removable memory 130 and / or removable memory 132). The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital card (SD card), etc. In other embodiments, processor 118 may access information from and store data in memories that are not actually located in WTRU 102, for example, memories that may be located on a server or home computer (not shown).

[0048] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device that powers the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (such as nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0049] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117, and / or determine its location based on signal timing received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation method, the WTRU 102 may acquire location information using any suitable positioning method.

[0050] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth modules, FM radio units, digital music players, media players, video game console modules, internet browsers, and so on.

[0051] Figure 3 This is a system diagram illustrating RAN 103 and CN 106 according to another embodiment. As described above, RAN 103 can communicate with WTRUs 102a, 102b, and 102c using UTRA radio technology and via air interface 115. RAN 103 can also communicate with CN 106. Figure 3 As shown, RAN 103 may include node Bs 140a, 140b, and 140c, each of which may include one or more transceivers communicating with WTRUs 102a, 102b, and 102c via air interface 115. Each of node Bs 140a, 140b, and 140c may be associated with a specific cell in RAN 103. RAN 103 may also include RNCs 142a and 142b. It should be understood that RAN 103 may include any number of node Bs and RNCs while maintaining compliance with the implementation method.

[0052] like Figure 3 As shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each RNC 142a and 142b can be configured to control its connected node B 140a, 140b, or 140c. Furthermore, each RNC 142a and 142b can be configured to perform or support other functions, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0053] Figure 3The CN 106 shown may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, an SGSN 148, and / or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing components is described as part of the CN 106, it should be understood that entities other than the CN operator may also own and / or operate any of these components.

[0054] RNC 142a in RAN 103 can connect to MSC 146 in CN 106 via the IuCS interface. MSC 146 can connect to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment.

[0055] RNC 142a in RAN 103 can also be connected to SGSN 148 in CN 106 via an IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 can provide WTRU 102a, 102b, and 102c with access to packet-switched networks such as the Internet, facilitating communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0056] As described above, CN 106 can also connect to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0057] Figure 4 This is a system diagram illustrating RAN 104 and CN 107 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c using E-UTRA radio technology and via air interface 116. RAN 104 can also communicate with CN 107.

[0058] RAN 104 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the implementation method. Each of eNodeBs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0059] Each of eNodeB 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 4 As shown, nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0060] Figure 4 The CN 107 shown may include the MME 162, the Serving Gateway (SGW) 164, and the Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the above components is described as part of the CN 107, it should be understood that entities other than CN operators may also own and / or operate any of these components.

[0061] MME 162 can connect to each of eNodeBs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attachment process of WTRUs 102a, 102b, and 102c, etc. MME 162 can also provide control plane functions for performing handovers between RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0062] Service gateway 164 can connect to each of eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface. Service gateway 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. Service gateway 164 can perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0063] Service gateway 164 can connect to PDN gateway 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as the Internet 110, in order to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0064] CN 107 can facilitate communication with other networks. For example, CN 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108, thereby facilitating communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. As an example, CN 107 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), wherein the IP gateway acts as an interface between CN 107 and PSTN 108. Furthermore, CN 107 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, wherein these other networks may include other wired and / or wireless networks owned and / or operated by other service providers.

[0065] Figure 5 This is a system diagram illustrating RAN 105 and CN 109 according to one embodiment. RAN 105 may be an Access Service Network (ASN) communicating with WTRUs 102a, 102b, and 102c over air interface 116 using IEEE 802.16 radio technology. As discussed further below, communication links between the different functional entities of WTRUs 102a, 102b, 102c, RAN 105, and CN 109 can be defined as reference points.

[0066] like Figure 5As shown, RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182. However, it should be understood that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the implementation method. Each of base stations 180a, 180b, 180c may be associated with a specific cell (not shown) in RAN 104, and each base station may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one implementation, base stations 180a, 180b, 180c may implement MIMO technology. For example, base station 180a may use multiple antennas to transmit radio signals to WTRU 102a and / or receive radio signals from WTRU 102a. Base stations 180a, 180b, 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, Quality of Service (QoS) policy enforcement, etc. ASN Gateway 142 can act as a traffic aggregation point and can be responsible for paging, subscriber profile caching, routing for CN 109, etc.

[0067] The air interface 117 between WTRUs 102a, 102b, and 102c and RAN 105 can be defined as an R1 reference point implementing the IEEE 802.16 standard. Additionally, each of WTRUs 102a, 102b, and 102c can establish a logical interface with CN 109 (not shown). The logical interface between WTRUs 102a, 102b, and 102c and CN 109 can be defined as an R2 reference point, which can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0068] The communication link between each of base stations 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transmission between base stations. The communication link between base stations 180a, 180b, and 180c and ASN gateway 182 can be defined as an R6 reference point. The R6 reference point may include mobility management based on mobility events associated with each of WTRUs 102a, 102b, and 102c.

[0069] like Figure 5As shown, RAN 105 can connect to CN 109. The communication link between RAN 105 and CN 109 can be defined as an R3 reference point, which, as an example, includes protocols for facilitating data transfer and mobility management capabilities. CN 109 may include a Mobile IP Local Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. While each of the aforementioned components is described as part of CN 109, it should be understood that entities other than the CN operator may also own and / or operate any of these components.

[0070] MIP-HA 184 manages IP addresses and enables WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different CNs. MIP-HA 184 provides WTRUs 102a, 102b, and 102c with access to packet-switched networks such as the Internet (110), facilitating communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. AAA Server 186 handles user authentication and user service support. Gateway 188 facilitates interoperability with other networks. For example, Gateway 188 provides WTRUs 102a, 102b, and 102c with access to circuit-switched networks such as the PSTN (108), facilitating communication between WTRUs 102a, 102b, and 102c and traditional terrestrial communication equipment. Gateway 188 can provide WTRU 102a, 102b, 102c with access to other networks 112, wherein the other networks may include other wired and / or wireless networks owned and / or operated by other service providers.

[0071] Although Figure 5 Although not shown, it should be understood that RAN 105 can connect to other ASNs, and other RANs (e.g., RAN 103 and / or 104) and / or CN 109 can connect to other CNs (e.g., CN 106 and / or 107). The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between CN 109 and other CNs can be defined as an R5 reference point, which may include protocols for facilitating interoperability between the home CN and the visited CN.

[0072] although Figure 1-5 The WTRU is described as a wireless terminal, but it is conceivable that in some typical implementations the terminal may use a wired communication interface with a communication network (e.g., temporarily or permanently).

[0073] The terms “core network” (CN) and “dedicated CN” (DCN) can generally be used interchangeably. Typically, a DCN can serve a specific type of WTRU, such as WTRUs associated with one or more DCN types (e.g., WTRUs associated only with one or more DCN types), and a CN may or may not serve those specific DCN types of WTRUs. For example, a DCN can be a CN dedicated to serving one or more types of WTRUs (e.g., WTRUs with a specific DCN type).

[0074] In some typical implementations, when the DCN type for a particular WTRU changes (e.g., based on a subscription change), the CN node can notify the WTRU of the new DCN type via a modified NAS message.

[0075] In some typical implementations, if redirection is appropriate or necessary, the CN node may provide a new DCN type to the UE or the RAN, for example, so that the RAN can notify the new CN node, which in turn can notify the WTRU in a NAS (e.g., accept) message.

[0076] In some typical implementations, in the event of congestion at the DCN, RRC connections for one or more DCN types can be denied, and the WTRU (e.g., a device) can receive a backoff timer from the RAN, which will prevent it from accessing the network during the backoff timer period.

[0077] In some typical implementations, a new RRC message can be implemented when the WTRU is unable to send its DCN type in a request message (e.g., an RRC connection request message).

[0078] In some typical implementations, the network support level and mechanism for new messages can be broadcast or relayed to WTRU via RRC messages and / or NAS messages.

[0079] In some typical implementations, WTRU access congestion can be based on any combination of the following (or relaxation based on any combination of the following): (1) DCN type; (2) establishment reason; and / or priority rules.

[0080] There are various services and applications that can run on cellular networks (e.g., 3GPP cellular networks). The most common services are voice, and IP connectivity is increasingly common and can be one of the most frequently offered services by cellular operators. Smartphones (e.g., WTRUs) can be used by device users (e.g., interactive and / or non-interactive users) and / or by people interacting with the device, which in turn and / or in response to, for example: (1) performing a process (e.g., a standard-based process, such as a 3GPP process and / or a non-standard-based process); (2) requesting an IP address; and / or (3) requesting resources (e.g., with a specific Quality of Service (QoS)), etc. Other cellular capability devices may not be able to interact with device users and / or people. These devices can run / execute applications to manage, control smart meters and / or sensors, etc., and / or communicate with smart meters and / or sensors, etc. Such devices can be called machine-type (MT) devices and typically can exchange IP data with application servers (which may be via the Internet). Considering the increasing number of MT devices owned by cellular operators communicating on their networks, this could increase the load on cellular systems.

[0081] Cellular operators may deploy dedicated nodes for devices with specific characteristics (e.g., low-speed storage devices (e.g., below a threshold), low-computing-power devices (e.g., below a threshold), low-power transmission devices (e.g., below a threshold), special radio access technologies for communication, special bandwidth requirements), devices known as MT devices, devices with highly predictable communication patterns, and / or devices for which IP connectivity is required (e.g., used) to conform to a specific communication model and / or processing. Cellular operators may implement dedicated nodes to serve these devices so that: (1) smartphones that can be used by people (interacting with user equipment) receive (e.g., always receive) the expected services (e.g., without worrying about the load caused by the increased deployment of other devices such as machine equipment (e.g., MT devices); and / or (2) service quality degradation for smartphones (e.g., due to a large number of devices (e.g., smartphones and / or machine equipment) accessing the system at the same time) will not occur.

[0082] For example, devices (such as WTRUs / UEs) can be directed and / or redirected to DCN nodes, such as MMEs, Serving Gateways (SGWs), and / or Packet Data Gateways (PGWs). WTRU redirection can be based on subscription information, which can be stored in the HSS. The MME can download the subscription information from the HSS, for example, when the WTRU registers to and / or joins the system. WTRUs running MT applications and / or WTRUs with low priority can indicate to the network that they are running MT applications and / or have low priority. For example, when a WTRU accesses the network (e.g., the system), (e.g., if the WTRU is configured as a low-priority device), a low-access-priority device indication can be signaled by the WTRU to the network entity. The WTRU can signal the indication at the radio (e.g., Radio Resource Control (RRC)) level and / or the Non-Access Stratum (NAS) level. The network can use this indication to perform certain actions (e.g., measurements), such as applying congestion control by providing one or more backoff indications and / or timers to the WTRU.

[0083] In one example, the subscription information may include or include an indication that the WTRU will be or can be served by the DCN. It is considered that the subscription information can change at any time and the time at which the WTRU can be directed and / or redirected to a specific CN can also be any time (e.g., it can have a defined time). Redirection to a specific CN can occur when any of the following occur: (1) an attach procedure; (2) a Tracking Area Update (TAU) procedure; (3) a Routing Area Update (RAU) procedure; (4) a service request procedure; (5) an idle mode move procedure within and / or between RATs; (6) a handover (HO) procedure within and / or between RATs; (7) roaming and / or shared network scenarios, etc.

[0084] Figure 6 This is a diagram illustrating a NAS message redirection process 600. The NAS message redirection process 600 can be implemented, for example, to redirect WTRU 102 to a dedicated CN. Reference Figure 6 At 620, a rerouting message request can be sent from the first SGSN 148A and / or the first MME 162A of CN 106, 107, 109, or 650A to RAN node 610 (e.g., eNB, Node B, and / or access point, etc.). At 630, RAN node 610 can use the Node Selection Function (NSF) (e.g., NAS NSF) to select a second new SGSN 148B and / or a second new MME 162B of CN 650B. At 640, the RAN node can send the initial WTRU message / UL-cell data to the second SGSN 148B and / or the second MME 162B of CN 650B.

[0085] For example, when a dedicated CN (DCN) 650 is implemented, NAS messages can be used to reroute WTRU 102 from a first CN node (e.g., MME 162A and / or SGSN 148A) to another CN node (e.g., MME 162B and SGSN 148B) during the attach, TAU, and / or RAU processes. MME 162 / SGSN 148 and / or HSS 710 can participate in the DCN reselection process.

[0086] When a network entity (e.g., the new MME 162A / SGSN 148A) decides and / or determines to move the processing of attach requests, TAU requests, and / or RAU requests to another CN node (e.g., MME 162B and / or SGSN 148B), the NAS message redirection procedure 600 may be initiated by the network entity (e.g., the new MME 162A / SGSN 148A and / or another network entity associated with the first CN node). The NAS message redirection procedure 600 may include any of the following:

[0087] 1) The first new MME 162A / SGSN 148A can send a rerouting NAS message request (including the original RAN message, rerouting parameters, and / or an additional Globally Unique Temporary Identifier (GUTI) / Packet-Temporary Mobile Subscriber Identifier (P-TMSI), etc.) to RAN node 610. The rerouting parameters may include an MME group identifier (MMEGI), such as for E-UTRAN, or a Null-Network Resource Identifier (Null-NRI) / SGSN group ID, such as for UTRAN / GERAN, which may correspond to or be associated with a DCN that can be used with or associated with a WTRU (e.g., UE). A WTRU 102 may be included with an additional GUTI / P-TMSI (e.g., if available) from the NAS request message. The MME 162A may use Domain Name System (DNS) procedures to determine the MMEGI or Null-NRI / SGSN group ID corresponding to DCN 650B. The original RAN message may be a complete PDU received from RAN 610, which may contain or may include the original NAS request message and RAN Information Elements (IEs) (e.g., one, some, or all of the RAN IEs).

[0088] 2) The NAS Node Selection Function (NNSF) of the RAN node can select a new MME 162 / SGSN 148 based on MMEGI, Null-NRI / SGSN group ID, and / or the appended GUTI / P-TMSI. For example, if the appended GUTI / P-TMSI identifies MME 162B / SGSN 148B within the set of valid nodes identified by the MMEGI and / or Null-NRI / SGSN group ID, then the identified MME 162B / SGSN 148B can be selected (e.g., it can be the selected node). In some examples, a valid CN node corresponding to the MMEGI and / or Null-NRI / SGSN group ID can be selected. If no valid MME 162 / SGSN 148 is available in the set of valid nodes identified by the MMEGI and / or Null-NRI / SGSN group ID, RAN node 610 may select MME 162 / SGSN 148 from the default DCN 650, or may select an MME 162A / SGSN148A that has sent a rerouting request based on one or more operator policies, rules, and / or configurations. MME 162 / SGSN 148 may be selected from the network corresponding to the selected CN operator.

[0089] 3) In some examples, the eNB 160 / RNC 142, depending on the Radio Access Technology (RAT) used, may send an initial WTRU message to the selected MME 162 / SGSN 148 and / or Base Station Controller (BSC) / Access Point 140, 160, and / or 180, and may send a UL-cell data message to the selected SGSN 148 and / or network entity (e.g., MME 162 and / or other network entities, etc.). The initial WTRU message / UL-cell data message may include a NAS request message, MMEGI, and / or Null-NRI / SGSN group ID. The MMEGI and / or Null-NRI / SGSN group ID may indicate that the message is a rerouted message, and a second new MME 162B / SGSN 148B of the DCN 650B may not reroute the NAS message (e.g., to another CN node).

[0090] The following pertains to the NAS message redirection process:

[0091] 1) There is no WTRU affected by the NAS message redirection process (e.g., the booting of the WTRU to a specific CN 650 (e.g., DCN) may not be perceived by the users of WTRU 102 and / or WTRU 102).

[0092] 2) The process can be based on subscription information and / or can utilize subscription information. A new WTRU usage type IE can be defined for WTRU 102 (e.g., in HSS 710), and when MME 162 obtains the WTRU's subscription document from HSS 710, MME 162 can determine, based on the WTRU usage type IE, which CN 650 (e.g., DCN) WTRU 102 can or should be redirected to (e.g., depending on the circumstances, such as if MME 162 is not the appropriate node serving WTRU 102, or if such a situation exists). If a redirection is to occur, MME 162 can trigger a redirection process to RAN node 610 (e.g., a specific eNB 160). MME 162 can include rerouting parameters (e.g., MMEGI in the LTE case, and / or Null-NRI / SGSN group ID for UTRAN / GERAN systems), and other parameters. The eNB160 or RAN node 610 can use the received parameters to select the MME 162 (and / or CN 650 (e.g., DCN)).

[0093] 3) The process can be initiated when WTRU 102 is sending an attach request message (e.g., when WTRU 102 is the first (e.g., initially) to register to the network / system) (e.g., only useful in this case) and / or when a TAU request message is sent, for example due to periodic registration or idle mode movement. Redirection can be triggered based on receiving a service request message from WTRU 102.

[0094] If WTRU 102 is registered in a network (e.g., network 100) (e.g., already registered), for example, WTRU 102 already has service CNs 106, 107, 109, or 650A, then the WTRU's subscription information can be changed to make a (new) dedicated CN 650B suitable for serving WTRU 102 and / or needed to serve WTRU 102. Using a given process that is useful for (e.g., only for) specific NAS messages (e.g., attach request messages and / or TAU messages), immediate redirection to a new DCN 650B may not be feasible if WTRU 102 is already registered (except when sending a TAU). TAU messages can be managed by periodically updated timers, which may take a very long time (greater than a threshold time) to occur.

[0095] Figure 7 This is a diagram illustrating the DCN reselection process 700 initiated by the MME / SGSN or HSS.

[0096] refer to Figure 7At 715, HSS 710 can send an insert subscriber data message to SGSN 148 and / or MME 162 associated with WTRU 102. At 720, MME 162 and / or SGSN 148 associated with WTRU 102 can send an insert subscriber data acknowledgment message to HSS 710. At 725, MME 162 and / or SGSN 148 associated with WTRU 102 can page WTRU 102. At 730, WTRU 102 can initiate data transmission with SGSN 148 and / or MME 162 associated with WTRU 102 from idle mode. At 735, MME 162 / SGSN 148 can trigger a GUTI reallocation / P-TMSI reallocation with WTRU 102. At 740, MME 162 / SGSN 148 can release RAN resources. At 745 or 750, WTRU 102 can perform the TAU and / or RAU procedures. At 755, MME 162 / SGSN 148 can initiate a redirection to DCN 650. In some typical implementations, operations 730, 735, and 745 can be completed, or operation 750 can be completed in place of operations 730, 735, and 745.

[0097] For example, the DCN reselection process 700 initiated by the MME / SGSN or HSS 710 can be implemented to mitigate one or more concerns associated with the NAS message redirection process and to expedite the change from service CN 106, 107, 109, or 650A to DCN650B, and may include any of the following:

[0098] If DCN 650 is deployed, the DCN reselection procedure can be used by HSS 710 to update the WTRU usage type subscription parameters in the service node. The reselection procedure may enable and / or result in a change of service node for WTRU 102. The reselection procedure can be used for service node changes initiated by the MME / SGSN for WTRU 102 (e.g., when the configuration regarding the WTRU usage type for service on MME162 / SGSN 148 is changed, or under such conditions). The reselection procedure can be used by the target MME 162 / SGSN 148 after a handover process to redirect WTRU 102 to a service node of another DCN (e.g., DCN650B). The reselection procedure described here can be applied when a handover occurs from a service area where DCN 650 is not supported (e.g., is being used) to a service area where DCN 650 is supported (e.g., is being used) and the target CN node does not serve the WTRU usage type. The switching process can be successfully completed and the target CN node can use this reselection process (as associated with typical operation 735 or forward operation) to change the service DCN 650 of WTRU 102.

[0099] Subscription changes can be applied to the maximum number of WTRUs 102 (e.g., above a threshold number of WTRUs), and considerations for MME / SGSN rebalancing as disclosed herein can be applied, for example, to avoid sudden redirection of WTRUs 102, which could overload CN nodes 144, 146, 148, 150, 162, 164, 166, 184, 186, and 188 (and / or RAN 103, 104, or 105, if paging is appropriate and / or required).

[0100] Figure 7 Typical operations 715 and 720 can be applied to HSS-initiated DCN reselection procedures (e.g., HSS-only DCN reselection procedures).

[0101] The DCN reselection process 700 may include any of the following:

[0102] 1) The HSS 710 can send an Insert User Data Request (IMSI, Subscription Data) message to the MME 162 / SGSN 148. The subscription data may include WTRU usage type information. Considering that when WTRU usage type subscription changes will be applied to a large number of users, the HSS 710 can stagger the insertion of subscription changes to service nodes (e.g., based on information / signaling from Operations & Maintenance (OAM)).

[0103] 2) MME 162 / SGSN 148 can update the stored subscription data and respond to Insert User Data Request messages, for example, by returning an Insert User Data Response (IMSI) message to HSS 710. The process can end if MME 162 / SGSN 148 is able to continue serving WTRU 102.

[0104] 3) If MME 162 / SGSN 148 determines and / or decides to immediately (e.g., within a threshold period) transfer WTRU 102 to another CN (e.g., DCN 650A or DCN 650B) and WTRU 102 is in idle mode, MME 162 / SGSN 148 may page WTRU 102. In another example, MME 162 may wait until WTRU 102 becomes active.

[0105] In some typical implementations, for the DCN reselection process, operations associated with 760 (e.g., operations 730, 735, 740, and 745) or operation 750 may occur or be executed. Operations 730, 735, 740, and 745 may occur when WTRU 102 is already in connected mode or when WTRU 102 enters connected mode by initiating a data transfer. Operation 750 may occur when the WTRU is in idle mode and performing the TAU and / or RAU procedures.

[0106] 4) The WTRU 102 can initiate NAS connection establishment via paging or uplink data triggering. In some examples, the WTRU 102 can initiate NAS connection establishment by sending a TAU / RAU request.

[0107] 5) When a NAS connection already exists or when a NAS connection is established to initiate data transfer, the MME 162 / SGSN148 can trigger a GUTI reassignment / P-TMSI reassignment process and may include a non-broadcast tracking area identifier (TAI) / routing area identifier (RAI).

[0108] 6) MME 162 / SGSN 148 can release RAN resources and / or WTRU 102 can be moved to idle mode.

[0109] Considering situations where a large number of WTRUs 102 (e.g., exceeding a threshold number of WTRUs) may be or need to be offloaded, the MME 162 / SGSN 148 may not immediately release RAN resources for WTRUs 102 (e.g., all WTRUs), for example, to avoid sudden redirection of WTRUs 102 that could overload the CN node (and / or the RAN, e.g., if paging is appropriate or necessary). The MME 162 / SGSN 148 may wait until a release is performed due to inactivity.

[0110] 7) Non-broadcast TAI / RAI can trigger WTRU 102 to start (e.g., immediately) the TAI / RAU procedure. MME162 / SGSN 148 can receive TAI / RAU request messages.

[0111] 8) WTRU 102 can execute TAU / RAU requests. MME 162 / SGSN 148 can receive TAU / RAU request messages.

[0112] 9) If the WTRU usage type for WTRU 102 is not served by MME 162 / SGSN 148, MME 162 / SGSN 148 may trigger the NAS message redirection procedure disclosed herein to redirect WTRU 102. Afterwards, the TAU / RAU procedure can be completed at the MME 162 of the selected DCN.

[0113] Redirection procedures during attach or TAU can cause signaling in the network (e.g., network 100) before the selection of the appropriate CN 106, 107, 109, or 650. At least one redirection procedure is appropriate and / or necessary before the correct CN is selected or picked for WTRU 102. To avoid this signaling, 3GPP Release 13 WTRUs may include backward compatible functions / operations / procedures for DCN selection / redirection with 3GPP Pre-Release 13 WTRUs. In some typical implementations, 3GPP Release 13 WTRUs may provide auxiliary information as part of RRC connection establishment. This auxiliary information may be used by RANs 103, 104, and / or 105 (e.g., for RAN node 610 or eNB 160, etc.) to select CN 106, 107, or 109 without using a CN redirection procedure.

[0114] Typical process of DCN type change for WTRU based on subscription modification / change

[0115] In some typical implementations, WTRU 102 may send auxiliary information to the network, such as to help select the appropriate DCN 650. The auxiliary information may include an indication (e.g., a new indication), which may be a parameter or DCN type IE. WTRU 102 may be pre-configured to indicate a specific DCN type. Subscription changes for WTRU 102 may exist, which may change the DCN type on the network side. HSS 710 may initiate operations toward a DCN node (e.g., MME 162A and / or SGSN 148A, etc.) where WTRU 102 resides. If DCN node 162A / 148A supports the new DCN type, WTRU 102 may not be redirected to another DCN node 162B / 148B. WTRU 102 may be aware that its DCN type has changed so that WTRU 102 can indicate the changed DCN type in the next or subsequent communication or contact with the network (e.g., network 100).

[0116] Typical process of network-side congestion

[0117] At any time, a threshold may be reached on the network side (e.g., at RAN 103, 104, and / or 105, DCN 650A and 650B, and / or DCN nodes 162A / 148A and / or 162B / 148B, etc.) causing a determined node (e.g., DCN) to be congested. DCN 650 may not want more signaling or data communication or may determine that it does not want more signaling or data communication. Rules, policies, thresholds, and / or criteria may be configured by the operator to allow DCN nodes 162A / 148A and / or 162B / 148B to accept one or more DCN types, but may reject others. In some typical implementations, the process may be implemented such that DCN nodes 162A / 148A and / or 162B / 148B may not receive signaling messages from WTRU 102 originating from a certain DCN type (e.g., may not even receive any signaling messages). Congestion control operations applicable to certain DCN types can be expected because a DCN 650A or 650B can serve different DCN types and one DCN type can have a lower priority than another DCN type.

[0118] Although the typical procedures described herein are associated with LTE systems, those skilled in the art will understand that these typical procedures can be applied to other RATs or other systems, such as CN / RAN / WTRU procedures at GERAN / UTRAN and RRA or NAS with corresponding CN nodes and corresponding RAN nodes. Thus, the term "MME" can refer to the LTE MME or it can also refer to the SGSN or C-SGN (e.g., for Cellular Internet of Things (CioT)), and the term "eNB" can refer to the LTE eNB or it can also refer to the RAN or BSC.

[0119] Typical process for notifying WTRU of a new DCN type

[0120] Typical CN node behavior (e.g., MME behavior)

[0121] The CN node (e.g., MME 162) can receive an indication from HSS 710 that the usage type of the WTRU has changed (e.g., WTRU 102 may be or will be redirected to another DCN (e.g., DCN 650B) or the DCN of the WTRU has changed). The CN node (e.g., MME 162) can receive a new DCN type for a specific WTRU 102 from HSS 710. The CN node (e.g., MME 162) can determine the new DCN type to be assigned to WTRU 102. The determination of the new DCN type can be based on local configuration or policies in the CN node (e.g., MME 162). For example, the CN node (e.g., MME 162) may be configured with a mapping between one or more WTRU usage types and one or more DCN types. If a new WTRU usage type is received from HSS 710, CN node 162 can determine the new DCN type to be assigned to WTRU 102 for WTRU 102. In some typical implementations, HSS 710 may provide information (e.g., stored information) to MME 162 to locally configure changes to the WTRU usage type indication, set a new WTRU usage type for WTRU 102, and / or set a new DCN type for WTRU 102.

[0122] Once a new DCN type has been determined for WTRU 102 or after it has been determined, the CN node (e.g., MME 162) can determine whether the redirection will be completed for WTRU 102 (e.g., required) (because a CN node can serve multiple DCN types).

[0123] Typical CN node behavior (e.g., MME behavior), such as when redirection is inappropriate and / or unnecessary.

[0124] If redirection is inappropriate and / or unnecessary, the CN node (e.g., MME 162) can send a new DCN type to WTRU 102. MME 162 can verify whether WTRU 102 is in idle mode or connected mode and can act based on the verified mode.

[0125] If WTRU 102 is in spatial mode, a CN node (e.g., MME 162) can page (e.g., proactively page) WTRU 102 to bring WTRU 102 into connected mode (e.g., control the transition of WTRU 102 to connected mode). In some typical implementations, a CN node (e.g., MME 162) can wait for WTRU 102 to transition to connected mode. The CN node (e.g., MME 162) may have a local policy that determines the action to be taken. For example, the CN node (e.g., MME 162) may determine whether paging WTRU 102 is appropriate (e.g., necessary or unnecessary) based on: (1) load conditions; (2) priority of the DCN type; and / or (3) indications (e.g., received from HSS 710 and / or locally configured in CN node 162), such as regarding the priority associated with the new DCN type.

[0126] When WTRU 102 transitions to connected mode (e.g., due to paging of WTRU or after paging of WTRU or due to NAS signaling connection initiated by WTRU), MME 162 may send a new DCN type to WTRU 102. A CN node (e.g., MME 162) may use any of the following to send the new DCN type.

[0127] CN nodes (e.g., MME 162) can use existing NAS messages (e.g., EPS Mobility Management (EMM) information messages in LTE systems and / or Mobility Management (MM) / GPRS MM (GMM) information messages via MSC 146 / SGSN 148) and can include new DCN types as new DCN type IE.

[0128] In some typical implementations, a CN node (e.g., MME 162) may use a GUTI reallocation command message to provide a new DCN type for WTRU 102. The CN node (e.g., MME 162) may include the new DCN type IE in this message (e.g., the GUTI reallocation command message). MME 162 may maintain the same GUTI for WTRU 102, or MME 162 may assign a new GUTI. The MME IE may point to the new DCN type so that the RAN node (e.g., eNB 160) can correctly route NAS messages to the appropriate CN node 162.

[0129] If WTRU 102 initiates a NAS signaling connection by sending a RAU / TA message, the CN node (e.g., MME162) can provide a new DCN type to WTRU 102 in the RAU / TAU message. MME 162 can include the new DCN type IE in the message given to WTRU 102 and can also include a new IE to indicate whether redirection to the new DCN is appropriate (e.g., required or not required).

[0130] After the new DCN type is assigned to WTRU 102, the CN node (e.g., MME 162) can release the WTRU's NAS connection (and RRC connection) by initiating a release procedure on the S1AP interface toward the RAN node (e.g., eNB160).

[0131] Typical CN node behavior when redirection is appropriate or necessary.

[0132] Typical process when WTRU is in connected mode

[0133] Figure 8 This is a flowchart illustrating typical MME behavior 800 associated with redirection to a new CN node. The MME behavior may depend on whether WTRU 102 is in connected mode or not, depending on whether the redirection is expected, appropriate, and / or required.

[0134] refer to Figure 8At block 810, MME 162 can receive a DCN type IE for WTRU 102 already registered in MME 162 or a new WTRU usage type IE. At block 820, MME 162 can determine a new DCN type for WTRU 102 and can determine whether a redirection is appropriate or necessary based on this new DCN type. At block 830, MME 162 can determine whether the new DCN type should or will be provided to WTRU 102 immediately. For example, if a redirection should or will be performed immediately, this determination can optionally be initiated. At block 840, MME 162 can page WTRU 102 to provide WTRU 102 with the new DCN type. In some typical implementations, the MME can page the WTRU to initiate a redirection to a new CN node (e.g., MME 162A or 162B). When WTRU 102 is in connected mode, MME 162 can initiate a GUTI reallocation command and / or send an EMM information message with a new DCN type to WTRU 102. If WTRU 102 has already sent a TAU request, MME 162 can provide the DCN type in the TAU acceptance. MME 162 can release the NAS connection used for WTRU 102.

[0135] For example, if WTRU 102 is in connected mode (e.g., already in connected mode), MME 162 can use the GUTI redistribution command procedure to provide WTRU 102 with a new GUTI. Consideration is given to the possibility that MME 162 can provide (e.g., can still provide) a new DCN type as determined by the CN node (e.g., MME 162). The procedures described above can be used for this purpose. MME 162 can include an indication in NAS messages (e.g., any NAS message, such as a GUTI redistribution command) indicating whether or will trigger a redirection. This indication can also include when the redirection can or will be performed (e.g., the time the redirection is initiated). For example, MME 162 can include a time value in the NAS message after which the redirection will be initiated by WTRU 102 (or network 100).

[0136] After the new GUTI and / or DCN type has been provided to WTRU 102 by MME 162 (as described above), MME 162 can release the connection of WTRU 102. MME 162 can trigger a WTRU context release command and may include an indication that the release is due to a DCN change and / or because redirection of WTRU 102 to another CN node 162A / 148A, or 162B / 148B (or DCN 650A or 650B) is expected or required. The CN node (e.g., MME 162) may include a new DCN type that can be used for WTRU 102. The CN node (e.g., MME 162) may indicate whether redirection is needed / expected, for example, because a new DCN type may not trigger a redirection. When a RAN node (e.g., eNB 160) receives an indication of releasing the context of a WTRU (which may include a DCN type) or an indication that the release is due to a DCN change, eNB 160 may release the WTRU connection and may include a new reason for the connection release (e.g., "DCN change"). eNB 160 may include the received DCN type (e.g., from MME 162) in an RRC message (e.g., an RRC release message or other RRC message).

[0137] MME 162 may send another S1AP message that is not a context release message. MME 162 may send another S1AP message (e.g., a WTRU context modification request) and may include a new DCN type in said message. eNB 160 may send a new RRC message or an existing RRC message to deliver (e.g., provide) the new DCN type to WTRU 102. At any time, when the DCN changes, MME 162 may notify WTRU 102 using any of the procedures and / or methods described above. eNB 160 may update the DCN type of WTRU 102 stored in the context by the eNB for WTRU 102. eNB 160 may use this DCN type to determine (e.g., in determining or as a factor in determining) which target eNB 160s can be used for handover (e.g., which eNB 160s are the targets for handover). In some typical implementations, eNB 160 may indicate in the RRC message sent to WTRU 102 whether redirection is needed / expected or whether the DCN type has changed and redirection is not required.

[0138] The above process can be applied when the WTRU 102 transitions to connected mode using any NAS message (e.g., service request, extended service request, and / or TAU / RAU, etc.).

[0139] Those skilled in the art should understand that Figure 8The blocks / operations within can be performed in different orders. Furthermore, those skilled in the art should understand that some implementations may include... Figure 8 All or part (e.g., only a subset) of the blocks / operations shown.

[0140] Typical process when WTRU is in idle mode

[0141] Figure 9 This is a flowchart illustrating the operation 900 of a different entity in a redirection to another CN node.

[0142] refer to Figure 9At 910, HSS 710 can send an Insert User Data message to MME 162 and / or SGSN 148 associated with WTRU 102. At 920, MME 162 and / or SGSN 148 associated with WTRU 102 can send an Insert User Data Response message to HSS 710. At 930, MME 162 and / or SGSN 148 associated with WTRU 102 can determine and / or set a new DCN type for WTRU 102 (e.g., based on an updated or new WTRU usage type / DCN type in the Insert User Data message). At 940, MME 162 / SGSN 148 can page WTRU 102 if WTRU 102 is in idle mode. At 950, MME 162 / SGSN 148 may send a GUTI reallocation command to WTRU 102, which may include any of the following: (1) a new GUTI; (2) a new DCN type; (3) a timer for the start of redirection; and / or (4) a DCN change indication, etc. At 960, WTRU 102 may send a GUTI reallocation complete message (e.g., which may include a response DCN type indicator) to MME 162 / SGSN 148. At 970, MME 162 / SGSN 148 may send an S1AP message (e.g., which may include any of the following: a new DCN type and / or a new release reason, etc.) to eNB 160. At 980, eNB 160 may send a message (e.g., an RRC message and / or a NAS message, which may include a new DCN type and / or a new release reason, etc.). At 985, WTRU 102 can determine that a NAS message (e.g., a TAU message) will or should be sent based on a new release reason or a new DCN type received in the NAS or RRC message. At 990, WTRU 102 can start a timer (using a value previously received in a NAS / RRC message with a new DCN type). After the timer expires, WTRU 102 can initiate a NAS signaling connection. At 995, WTRU 102 can send the NAS message, for example, in an RRC message, such that the NAS or RRC may include the new DCN type.

[0143] Figure 10 This is a diagram illustrating a NAS message (e.g., a TAU / RAU request) 1000 for a DCN type WTRU that has changed its DCN type to initiate a redirection process (e.g., from source MME 162A to target MME 162B).

[0144] refer to Figure 10At 1010, WTRU 102 may send a message (e.g., a NAS message, such as a TAU / RAU request) to source MME 162 / SGSN 148. At 1020, source MME 162A / SGSN 148 may send a redirection message (e.g., a NAS message redirection) to eNB 160, which may include any of the following: (1) a NAS message; (2) an MMEGI and / or (3) a DCN type, etc. At 1030, eNB 160 may determine a new DCN based at least on the new DCN type IE. At 1040, eNB 160 may send a redirection message (e.g., a NAS message redirection) to target MME 162B / SGSN 148B, which may include any of the following: (1) a NAS message; (2) an MMEGI and / or (3) a DCN type, etc. At 1050, the target MME162B / SGSN 148B can process NAS messages and can consider new DCN types. At 1060, the target MME 162B / SGSN 148B can send a context request to the source MME 162A / SGSN 148A. At 1070, the source MME 162A / SGSN 148A can send a context response to the target MME 162B / SGSN 148B, which may include the new DCN type of WTRU 102. At 1080, the target MME 162B / SGSN 148B can send a message that may include the new DCN type (such as a NAS message, e.g., a TAU / RAU response).

[0145] refer to Figure 9 and 10 If WTRU 102 is in idle mode, the CN node (e.g., MME 162) may decide or determine to page WTRU 102 to transition WTRU 102 (e.g., to make WTRU 102) into connected mode and to provide WTRU 102 with a new DCN type. In some typical implementations, the CN node (e.g., MME 162) may redirect WTRU 102. Once in connected mode, the CN node (e.g., source MME 162A) may use any of the procedures / operations / methods described herein to provide WTRU 102 with a new DCN type and / or redirect WTRU 102 to a new target DCN 650B / target CN.

[0146] WTRU 102 can autonomously leave idle mode for Mobile Originating (MO) data or MO signaling. For example, WTRU 102 can leave idle mode using a service request procedure for MO data and / or MO session management signaling. When WTRU 102 is in connected mode based on or as a result of a WTRU-initiated service request procedure, the source CN node (e.g., MME 162A) can use the procedures / operations / methods described herein to provide WTRU 102 with a new type and / or redirect WTRU 102 to a new CN or DCN.

[0147] If WTRU 102 uses (e.g., utilizes) other NAS messages such as TAU / RAU detachment requests to transition out of idle mode, the CN node (e.g., MME 162A) may provide (e.g., initially provide) a DCN type (e.g., a new DCN type) (e.g., any process / operation / method used here) to WTRU 102 or may redirect (e.g., directly redirect) WTRU 102 to a new target CN 650B and may provide a new DCN type to a new target CN node (e.g., a new and different MME 162B). To redirect WTRU 102, the source MME 162A may use a new process or an existing process (e.g., MME 162 may use a NAS message redirection process). In some typical implementations, the source MME 162A may include the new DCN type of WTRU 102 as a new Information Element (IE) in the NAS message redirection process. Once received by eNB 160, eNB 160 can use the new DCN type received from the source CN node (e.g., source MME 162) to select (and / or pick) a new target CN node (e.g., target MME 162B). eNB 160 can use the DCN type and / or MMEGI received from the source CN node (e.g., source MME 162A) to select a new target CN node (e.g., target MME 162B).

[0148] After a NAS message is redirected to a new MME 162 (e.g., target MME 162B), the target MME 162B can forward a new DCN type for WTRU 102 via NAS messages (e.g., TAU / RAU accept, etc.). The source MME 162A can forward any DCN type IE to the new target MME 162B as part of a context request / response between the source MME 162A and the target MME 162B.

[0149] Those skilled in the art should understand that Figure 9 and 10The blocks / operations within can be performed in different orders. Furthermore, those skilled in the art should understand that some implementations may include... Figure 9 and 10 All or part (e.g., only a subset) of blocks and operations.

[0150] Typical WTRU behavior

[0151] WTRU 102 can receive a new DCN type IE in NAS and / or RRC messages. If a redirection is about to occur (e.g., is required), WTRU 102 can receive a timer in the NAS and / or RRC messages, after which a redirection can be initiated. If WTRU 102 receives a new DCN type IE, it can override its current DCN type using the value received in the new DCN type IE. If a timer is received in the NAS and / or RRC messages, WTRU 102 can start a timer for DCN redirection. When the timer expires, WTRU 102 can send TAU / RAU messages and / or any NAS message, for example, for the network redirection WTRU 102. WTRU 102 can include the new DCN type in the NAS message.

[0152] If WTRU 102 receives an RRC message (e.g., an RRC connection release message) with a new DCN type IE and / or a new reason code, where the new reason code indicates that the release is due to a redirection (e.g., "required DCN redirection"), then WTRU 102 (e.g., the RRC layer in WTRU 102) may forward the received IE (e.g., all received IEs) to a higher layer (e.g., the NAS layer). The RRC layer may forward any received timers (e.g., any received timers) from the RRC release message to a higher layer, such as the NAS layer or another layer. The NAS may perform any of the actions described herein (e.g., start a timer to determine when a redirection will occur and / or send a NAS message after the timer expires so that the new DCN type can be included in the NAS message).

[0153] Typical blocking process of WTRU at the RRC level in RAN

[0154] Figure 11 This is a diagram illustrating a typical blocking process 1100. (Reference) Figure 11At 1110, the source MME 162 / SGSN 148 may send an overload start message to the RAN node (e.g., eNB 160), which may include any of the following: (1) an indicator indicating whether the DCN type is allowed or not (e.g., DCN type {allowed / not allowed}); and / or (2) an indicator indicating whether the access type is allowed or not (e.g., access type (e.g., MO data, MT data, etc.) {allowed / not allowed}), etc. At 1120, the RAN node (e.g., eNB 160) may send an overload start acknowledge message to the source MME 162 / SGSN 148. At 1130, WTRU 102 may send a message (e.g., an RRC message including any of (1) DCN type and / or (2) establishment reason, etc.) to the RAN node (e.g., eNB 160). At 1140, eNB 160 can determine whether WTRU 102 is subject to backoff based at least on the DCN type (e.g., for WTRU 102 in idle mode or connected mode). eNB 160 can broadcast DCN access restriction information on one or more SIBs. At 1150, eNB 160 can send a message (e.g., an RRC message) that may include any of the following: (1) DCN type; (2) backoff (BO) timer; and / or (3) reason for BO, etc. At 1160, WTRU 102 can: (1) start the BO timer for the indicated DCN type; and / or (2) access a system with another DCN type, for example, based on a priority list of DCN types, etc. At 1170, source MME162 / SGSN 148 can at any time request a stop to overload for a specific DCN type and / or for the access type of each DCN 650. At 1180, the source MME 162 / SGSN 148 may send a message (e.g., overload stop) that may include any of the following: (1) an indicator indicating whether the DCN type is allowed or not (e.g., DCN type {allowed / not allowed}); and / or (2) an indicator indicating whether the access type is allowed or not (e.g., access type (e.g., MO data, MT data, etc.) {allowed / not allowed}), etc. At 1190, the eNB 160 may update the eNB access restrictions based on received information (e.g., information). The eNB 160 may begin broadcasting the updated DCN access restriction information (e.g., information).

[0155] For example, when one or more congestion criteria at DCN 650 reach (e.g., meet or exceed) one or more thresholds (e.g., based on policy / rules), the CN node (e.g., MME 162 / SGSN 148) can send an overload start message to eNB 160 via the S1 interface and can notify eNB 160 that access for certain DCN types is blocked or will be blocked. eNB 160 can store information and can reject RRC connection request messages (e.g., any RRC connection request message) from WTRU 102 indicating the DCN type for which congestion control will be applied or is active / requested. MME 162 can provide at least one DCN type in the overload start message, and the eNB can reject (block) connections from WTRU 102, which provides any of the disallowed / blocked DCN types received by eNB 160 from the CN node (e.g., MME 162). The CN node (e.g., MME 162) can provide a time during which overload control is applicable and can provide a time for determining how long a WTRU 102 with an unpermitted (or blocked) DCN type will be blocked (e.g., can be backed off) by the eNB 160.

[0156] The eNB 160 can provide a backoff timer to the WTRU 102 (e.g., which it can receive from the MME 162) so that the WTRU 102 does not need to retries another connection establishment. It is considered that the WTRU 102 can indicate its DCN type in any RRC message (e.g., an RRC connection request message, etc.). In some typical implementations, the WTRU 102 can indicate its DCN type in an RRC connection setup complete message, and the eNB 160 can release the RRC connection and provide a backoff timer to the WTRU 102. Under certain congestion levels (e.g., severe congestion exceeding a high threshold), the network operator may want to or determine to block access for all DCN types. In some typical implementations, the WTRU 102 may not be able to send the DCN type in the RRC connection request message, so the network (e.g., the MME 162 / eNB 160) can first send an RRC connection setup message to the WTRU 102 and receive an RRC connection setup complete message from the WTRU 102, and then release the RRC connection.

[0157] In other typical implementations, if the device is a DCN candidate, the network can notify WTRU 102 that WTRU 102 can use a new RRC message (e.g., referred to as a DCN connection request). When eNB 160 receives a new DCN connection request message, eNB 160 can know and / or determine that the connection request is for a DCN type WTRU and can appropriately reject or accept the connection based at least on the following information: WTRU 102 is a DCN type WTRU and / or eNB 160 can provide a backoff timer.

[0158] In some typical implementations, the network may inform WTRU 102 of its ability to decode / understand new RRC messages (e.g., DCN connection request messages), for example, because otherwise WTRU 102 might be unsure whether the network supports the message. One of the System Information Blocks (SIBs) may be modified to carry this information (e.g., a one-bit or multi-bit indicator indicating the ability to decode DCN connection requests). In other typical implementations, RANs 103, 104, and 105 may inform WTRU 102 of its capabilities in the first connection establishment, for example, by using an RRC connection setup message. The Information Element (IE) in the RRC connection setup message may inform WTRU 102 of network support for DCN type WTRUs.

[0159] In other typical implementations, NAS messages may be used during the first attach / TAU procedure. The eNB 160 may broadcast one of the following in any SIB: (1) which DCN types are not allowed for access; or (2) which DCN types are allowed for WTRU 102 access.

[0160] A DCN 650A (e.g., via MME 162A) can determine or wish to block certain types of connections associated with certain DCN types. For example, a DCN 650A may expect to block (e.g., only block) data attempts / MO signaling for the DCN 650A. The DCN 650A can provide this blocking information about the DCN 650A along with a backoff timer (e.g., or other backoff mechanism) to RANs 103, 104, and 105. The CN node (e.g., the source MME 162A) in the overload start message can provide a list of DCN types that are no longer permitted for access. For each DCN type, the source MME 162A can indicate which types of traffic are permitted or which types of traffic are not permitted (e.g., permitted or disallowed MO signaling, and / or permitted or disallowed MO data, etc.). When eNB 160 receives an RRC message from WTRU 102, eNB 160 can verify the DCN type and / or establishment reason indicated by WTRU 102. eNB 160 can determine whether the WTRU's access is permitted based on this information received from the source MME 162A (e.g., based on the DCN type and access reason). The access reason may include, but is not limited to, mobile called data; and / or mobile calling data, etc.

[0161] If WTRU 102 is already in connected mode and the context of WTRU 102 in eNB 160 indicates that the DCN type is not subject to load control, then eNB 160 may release the connection of WTRU 102 and may indicate the BO timer, DCN type and / or may indicate that the release reason is due to congestion for the indicated DCN type.

[0162] WTRU 102 can be configured to operate or use more than one DCN type, for example, with a priority set among DCN types based on one or more priority rules / policies. Each WTRU has multiple DCN types, and WTRU 102 can request registration in another DCN 650B, for example, under conditions where WTRU 102 is not allowed to register (e.g., due to congestion in the network in a DCN 650A). WTRU 102 can begin (typically) with the highest priority DCN type (according to priority rules). If WTRU 102 is rejected from RAN 103, 104, and 105, WTRU 102 can attempt to access another DCN type with a lower priority in the list of WTRU 102s in the prioritized DCNs 650A and 650B. WTRU 102 can (1) receive a priority list of DCN 650A and 650B from CN 106, 107 and / or 109 in NAS messages (e.g., any NAS message), (2) via OMADM, and / or (3) via SMS, etc., and / or information can be configured in WTRU 102.

[0163] If WTRU 102 receives an RRC rejection or release and backoff timer, WTRU 102 (e.g., the RRC layer) can forward the BO timer to a higher layer (e.g., NAS). NAS can enable the BO timer associated with DCN 650A (e.g., during which no access to DCN 650A can be allowed by WTRU 102). WTRU 102 can access a network / system of another DCN type.

[0164] WTRU 102 can read SIBs and receive DCN access restriction information (e.g., info) and can determine whether WTRU 102 can access the network / system based on the received info and / or the DCN type configured to operate.

[0165] What those skilled in the art understand is Figure 11 The blocks / operations within can be performed in different orders. Furthermore, those skilled in the art will understand that some implementations may include... Figure 11 All or part (e.g., only a subset) of the block / operation shown.

[0166] Figure 12 This is a flowchart illustrating a typical approach implemented by a CN entity (e.g., MME and / or SGSN).

[0167] refer to Figure 12Typical method 1200 may include, at 1210, a CN entity (e.g., MME 162 or SGSN 148) receiving information from another CN entity (e.g., HSS 710) indicating that the DCN type for WTRU 102 is new or has been changed. At 1220, CN entities 162 / 148 may send messages (e.g., RRC and / or NAS messages) to WTRU 102, which may include the new or changed DCN type.

[0168] In some typical implementations, CN entities 162 / 148 can determine whether the DCN type is new or has changed based on subscription information from another CN entity 710.

[0169] In some typical implementations, CN entities 162 / 148 may send a GUTI / P-TMSI reallocation command that may include a new DCN type or a changed DCN type. For example, when WTRU 102 is in idle mode, CN entities 162 / 148 may page WTRU 102 before sending a GUTI / P-TMSI reallocation command that includes a new DCN type or a changed DCN type.

[0170] In some typical implementations, CN entity 162 / 148 may receive TAU requests from WTRU 102.

[0171] For example, CN entities 162A / 148A and 162B / 148B may include processor 118; and transmit / receive unit 120, which communicates with processor 118 and may be configured to: receive information from another CN entity 710 indicating whether the DCN type for WTRU 102 is new or has been changed; and send a message including the new DCN type or the changed DCN type to WTRU 102.

[0172] Figure 13 This is a flowchart illustrating another typical method implemented by a CN entity.

[0173] refer to Figure 13 Typical method 1300 may include, at 1310, a CN entity (e.g., MME 162 or SGSN 148) determining whether to redirect WTRU 102 to another CN entity (e.g., MME 162A / 162B or SGSN 148A / 148B). At 1320, if WTRU 102 is to be redirected, the CN entity (e.g., MME 162 or SGSN 148) may send information to WTRU 102 indicating the DCN type for WTRU 102.

[0174] In some typical implementations, CN entity 162 / 148 may receive subscription information of DCN type associated with WTRU 102.

[0175] In some typical implementations, CN entity 162 / 148 may determine whether WTRU 102 will be served by CN entity 162 / 148 or other CN entities 162A / 148A and 162B / 148B based on the DCN type from the received subscription information.

[0176] In some typical implementations, where WTRU 102 will be served by other CN entities 162A / 148A and 162B / 148B, CN entity 162 / 148 can initiate a redirection of WTRU 102 to other CN entities 162A / 148A and 162B / 148B.

[0177] For example, CN entity 162 / 148 may include processor 118 configured to determine whether to redirect WTRU 102 to another CN entity 162A / 148A and 162B / 148B, and transmit / receive unit 120, communicating with processor 118 and configured to send information indicating the DCN type for WTRU 102 if the WTR will be redirected.

[0178] Figure 14 This is a flowchart illustrating a typical method implemented by a network entity.

[0179] refer to Figure 14 Typical method 1400 may include, at 1410, network entities (e.g., eNB 160, RAN node 610, and / or access point, etc.) receiving from WTRU 102 a message including a DCN type for WTRU 102 (e.g., a connection setup complete message). At 1420, network entities 160 and 610 may determine, for CN entities 162A / 148A and 162B / 148B serving the DCN type of WTRU 102, whether the DCN type of WTRU 102 is subject to congestion control. At 1430, if the DCN type of WTRU 102 is subject to congestion control, network entities 160 and 610 may send to WTRU 102 a message that may indicate the release of the connection and may include a backoff timer (e.g., a connection release message). For example, network entities 160 and 610 can determine whether the DCN type of WTRU 102 is subject to congestion control based on the congestion level and DCN type associated with CN entities 162A / 148A and 162B / 148B of the DCN type serving WTRU 102.

[0180] In some typical implementations, network entities 160 and 610 may receive information indicating overload conditions of CN entities 162A / 148A and 162B / 148B, including indications of one or more DCN types undergoing congestion control.

[0181] For example, network entities 160 and 610 may include a transmit / receive unit 120 configured to receive from WTRU 102 a connection setup completion message including a DCN type for WTRU 102, and a processor 118 configured to determine, for CN entities 162A / 148A and 162B / 148B serving the DCN type of WTRU 102, whether the DCN type of WTRU 102 is under congestion control. In some typical embodiments, under the condition that the DCN type of WTRU 102 is under congestion control, the transmit / receive unit 120 may be configured to send a message to WTRU 102 indicating the release of the connection and including a backoff timer (e.g., a connection release message).

[0182] Figure 15 This is a flowchart illustrating a typical method of WTRU implementation in idle mode (e.g., initially in idle mode).

[0183] refer to Figure 15 Typical method 1500 may include, at 1510, WTRU 102 receiving a paging request. At 1520, WTRU 102 may send a TAU request. At 1530, WTRU 102 may receive a GUTI / P-TMSI reallocation command that may include WTRU 102's new DCN type or changed DCN type. At 1540, WTRU 102 may redirect to CN entities 162A / 148A and 162B / 148B serving the new DCN type or changed DCN type.

[0184] For example, WTRU 102 in idle mode may include transmit / receive unit 120 configured to: receive paging, send TAU requests, and receive GUTI / P-TMSI reallocation commands that may include a new DCN type or a changed DCN type of the WTRU; and processor 118 configured to redirect WTRU 102 to CN entities 162A / 148A and 162B / 148B serving the new DCN type or the changed DCN type.

[0185] Figure 16 This is a flowchart illustrating another typical approach to WTRU implementation.

[0186] refer to Figure 16Typical method 1600 may include, at 1620, WTRU 102 sending a request message (e.g., a connection request message) to network entities 160 and 610. At 1620, WTRU 102 may receive a setup message (e.g., a connection setup message) from network entities 160 and 610. At 1630, WTRU 102 may send a setup completion message (e.g., a connection setup completion message) to network entities 160 and 610, which may include a DCN type for WTRU 102. At 1640, under the condition that the DCN type of the WTRU is subject to congestion control by CN: WTRU 102 may receive a message from network entities 160 and 610 that may indicate the release of the connection and may include a backoff timer (e.g., a connection release message), and may wait for the backoff timer to expire before retransmitting the request message (e.g., the connection request message) to network entities 160 and 610.

[0187] For example, WTRU 102 may include a transmit / receive unit 120 and a processor 118. The transmit / receive unit 120 may be configured to: send a connection request to network entities 160 and 610; receive a connection setup message from network entities 160 and 610; send a connection setup completion message to network entities 160 and 610, which may include a DCN type for WTRU 102; and, if the DCN type of WTRU 102 is subject to congestion control under CN 650A and 650B, receive a connection release indication from network entities 160 and 610, including a backoff timer. The processor 118 may be configured to wait for the backoff timer to expire, and the transmit / receive unit 120 may be configured to retransmit the connection request to the network entities after the backoff timer expires.

[0188] Figure 17 This is a flowchart illustrating yet another typical approach implemented by network entities and / or CN entities.

[0189] refer to Figure 17Typical method 1700 may include, at 1710, network entity 160 and / or CN entity 162 / 148 receiving a DCN type for the WTRU using a connection request from the WTRU 102. At 1720, network entity 160 and / or CN entity 162 / 148 may determine, as a result, whether CN entity 162 / 148 or another CN entity 162A / 148A and 162B / 148B that can serve the WTRU 102 with that DCN type is congested. At 1730, in response to the determination result, network entity 160 and / or CN entity 162 / 148 may send information indicating whether to accept or reject the connection request. For example, network entity 160 and / or CN entity 162 / 148 may send a message indicating acceptance of a connection request based on a determination that CN entity 162 / 148 of the DCN type serving WTRU 102, or other CN entities 162A / 148A and 162B / 148B, are not congested. As another example, CN entity 162 / 148 may send a message indicating rejection of a connection request based on a determination that CN entity 162 / 148 of the DCN type serving WTRU 102, or other CN entities 162A / 148A and 162B / 148B, are congested.

[0190] In some typical implementations, network entity 160 and / or CN entity 162 / 148 may determine whether CN entity 162 / 148 or other CN entities 162A / 148A and 162B / 148B of the DCN type serving WTRU 102 is congested, based on one or more operating parameters associated with CN entity 162 / 148 of the DCN type serving WTRU 102 or other CN entities 162A / 148A and 162B / 148B.

[0191] Figure 18 This is a flowchart illustrating another typical method of WTRU implementation.

[0192] refer to Figure 18 Typical method 1800 may include, at 1810, WTRU 102 sending a contention-based connection request message to network entities 160 and 610, including information indicating the DCN type for WTRU 102. The DCN type may indicate the type of WTRU 102, which is served by or will be served by DCN entities 162A / 148A and 162B / 148B associated with the WTRU 102 requesting a connection to the network. At 1820, WTRU 102 may receive a connection completion message from network entities 160 and 610 in accordance with the request for a connection to the network, and may at least indicate a set of resources based on non-contention communication.

[0193] In some typical implementations, WTRU 102 may receive broadcast messages that include indicators indicating whether the network supports DCN type messages. For example, WTRU 102 may determine to send a contention-based connection request message based on the reception of a broadcast message indicating support for DCN type messages.

[0194] Figure 19 This is a flowchart illustrating an additional typical method implemented by WTRU for managing connections to the network.

[0195] refer to Figure 19 Typical method 1900 may include, at 1910, WTRU 102 receiving a broadcast message including an indicator indicating whether the network supports DCN type messages. At 1920, WTRU 102 may determine, based on the indicator in the broadcast message, whether to send a contention-based connection request message, which may include the DCN type. At 1930, WTRU 102 may send a first contention-based connection request message excluding the DCN type to network entities 160 and 610 if the network does not support DCN type messages, or send a second contention-based connection request message including the DCN type to network entities 160 and 610 if the network supports DCN type messages.

[0196] Figure 20 This is a flowchart illustrating additional typical methods implemented by network entities within a network.

[0197] refer to Figure 20 Typical method 2000 may include, at 2010, network entities 160 and 610 receiving a contention-based connection request message from WTRU 102, the contention-based connection request message including information indicating the DCN type for WTRU 102. The DCN type may indicate the type of WTRU 102 that will be served by DCN entity 162A / 148A associated with the WTRU 102 requesting a connection to the network. At 2020, network entities 160 and 610 may determine whether to accept or reject the connection request based at least on the DCN type in the contention-based connection request message. At 2030, if the connection request is accepted, network entities 160 and 610 may redirect the WTRU to another DCN entity 162B / 148B that will serve or service the WTRU 102 whose DCN type is included in the received connection request message. At 2040, under the condition that the connection request is rejected, network entities 160 and 610 may send a connection rejection message and a backoff timer to WTRU 102, which can indicate the period of time during which WTRU 102 cannot connect to the network served by the CN entity associated with the DCN type in the connection request message.

[0198] In some typical implementations, network 100 may support multiple DCN types for each WTRU 102.

[0199] In some typical implementations, if a connection request is rejected, network entities 160 and 610 may receive another contention-based connection request message from WTRU 102, which includes an indication of a second, different DCN type for WTRU 102. For example, the second DCN type could indicate the type of WTRU that will be served by yet another network entity associated with WTRU 102, which is requesting a second connection to network 100.

[0200] In some typical implementations, network entities 160 and 610 may determine whether to accept or reject the second connection request based at least on the second DCN type in other contention-based connection request messages.

[0201] In some typical implementations, network entities 160 and 610 may redirect WTRU 102 to another network entity that serves WTRU 102 of type DCN included in the received second connection request message, provided that other connection requests are accepted.

[0202] In some typical implementations, network entities 160 and 610 may send broadcast messages that may include indicators indicating whether the network supports DCN type messages.

[0203] In some typical implementations, network entities 160 and 610 can determine whether a contention-based connection request message includes or excludes information indicating the DCN type for WTRU 102.

[0204] Figure 21 This is a flowchart illustrating another typical method of implementation by network entities.

[0205] refer to Figure 21Typical method 2100 may include, at 2110, network entities 160 and 610 receiving a contention-based connection request message, which may include information indicating the DCN type for WTRU 102. The DCN type may indicate the type of WTRU 102 that is served by or will be served by a DCN entity 162A / 148A associated with the WTRU 102 requesting a connection to network 100. At 2120, network entities 160 and 610 may determine whether to accept or reject the connection request based at least on the DCN type in the contention-based connection request message. At 2130, if the connection request is accepted, network entities 160 and 610 may send a connection completion message to WTRU 102 according to the connection request and at least indicating the set of resources for non-contention-based communication.

[0206] Figure 22 This is a flowchart illustrating yet another typical method implemented by a network entity.

[0207] refer to Figure 22 Typical method 2200 may include, at 2210, network entities 160 and 610 receiving the DCN type for WTRU 102 from WTRU 102 using a connection request. At 2220, network entities 160 and 610 may determine, as a result of the determination, whether to block WTRU 102 from connecting to CN entity 162A serving the DCN type of WTRU. At 2230, in response to the determination result, network entities 160 and 610 may send information indicating acceptance or rejection of the connection request. For example, network entities 160 and 610 may send information indicating acceptance of the connection request based on the determination that WTRU will not be blocked from connecting to CN entity 162 serving the DCN type of WTRU 102, and may send information indicating rejection of the connection request based on the determination that WTRU will be blocked from connecting to CN entity 162 serving the DCN type of WTRU 102.

[0208] In some typical implementations, network entities 160 and 610 may establish one or more access rules based on DCN type and / or establishment reason; and CN entities 162A / 148A may compare the DCN type and establishment reason associated with WTRU 102 with the established access rules to determine whether to block WTRU connection to the DCN type serving WTRU 102.

[0209] It is considered that a CN entity can be any of the following: (1) a source MME; and / or (2) a target MME. It is also considered that a CN entity and / or a network entity can include one or more processors, one or more memories, and / or one or more transmit / receive units to perform any operations disclosed herein for such an entity.

[0210] The embodiments described herein are considered for application to other devices / systems such as GERAN / UTRAN or any new systems developed for cellular IoT. Although LTE-specific NAS messages, RRC messages, and S1AP messages are shown, equivalent messages in these other systems can also be used.

[0211] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in a computer-readable medium and executed by a computer or processor. Examples of non-transitory computer-readable media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital multipurpose discs (DVDs). The processor associated with the software can be used to implement radio frequency transceivers used in WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

[0212] Furthermore, in the above embodiments, note the presence of a processing platform, computing system, controller, and other devices including a limiting server and a convergence point / server containing a processor. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by different CPUs and memories. Such actions and operations or instructions may be referred to as being “executed,” “computer-executed,” or “CPU-executed.”

[0213] Those skilled in the art will understand that the actions and symbols representing operations or instructions include the processing of electrical signals by the CPU. The electrical system represents the maintenance of data bits at storage locations in the storage system, which can cause the conversion or restoration of electrical signals, thereby enabling reconfiguration or other alteration of CPU operations, and other signal processing. The storage location for maintaining data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that exemplary embodiments are not limited to the aforementioned platform or CPU, and other platforms and CPUs may support the provided methods.

[0214] Data bits can also be maintained on computer-readable media, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”) mass storage systems. Computer-readable media can include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed among multiple interconnected processing systems, which are local or remote relative to the processing system. It should be understood that typical implementations are not limited to the above-described memories, and other platforms and memories can support the described methods.

[0215] In the illustrative embodiments, any of the operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0216] There is virtually no difference between the hardware and software implementations of the various aspects of the system. The use of hardware or software is typically (but not always, as the choice between hardware and software can become important in certain environments) a design choice representing a cost-efficiency trade-off. Different vehicles may exist, through which the processes and / or systems and / or other technologies described herein can be implemented (e.g., hardware, software, and / or firmware), and the preferred vehicle may vary depending on the environment in which the processes and / or systems and / or other technologies are developed. For example, if the implementer determines that speed and accuracy are most important, the implementer may primarily choose a hardware and / or firmware vehicle. If flexibility is paramount, the implementer may primarily choose a software implementation. Alternatively, the implementer may choose a combination of hardware, software, and / or firmware.

[0217] The detailed description above has illustrated various implementations of the apparatus and / or process using block diagrams, flowcharts, and / or examples. While such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by various hardware, software, firmware, or substantially any combination thereof. By way of example, suitable processors include general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate arrays (FPGAs), any other type of integrated circuit (IC), and / or state machines.

[0218] Although features and elements are provided above in specific combinations, it should be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described herein, which serve as illustrations of different aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from its spirit and scope. Elements, actions, or instructions used in this specification should not be construed as critical or essential to the invention unless explicitly stated otherwise. In addition to those enumerated herein, functionally equivalent methods and apparatuses within the scope of this disclosure will be apparent to those skilled in the art based on the foregoing description. Such modifications and variations fall within the scope of the appended claims. This disclosure will be limited only by the full scope of the appended claims and their equivalents. It should be understood that this disclosure is not limited to any particular method or system.

[0219] It should also be understood that the terminology used herein is for the purpose of describing particular implementations only and is not intended to be limiting. As used herein, and when referred to herein, the term “User Equipment” and its abbreviation “UE” may mean (i) a Wireless Transmitting and / or Receiving Unit (WTRU), as described below; (ii) any number of implementations of a WTRU, as described below; (iii) a wireless and / or wired (e.g., tethered) device, particularly configured with some or all of the structure and functions of a WTRU, as described below; (iv) a wireless and / or limited-capability device configured with fewer of the structure and functions of a WTRU, as described below; or (iv) etc. Details of the example WTRU may be representative of any WTRU described herein.

[0220] In some typical embodiments, several portions of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that certain aspects of the embodiments disclosed herein may be implemented entirely or partially equivalently in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or substantially any combination thereof, and recognize that those skilled in the art will be able to design circuits and / or write code for software and / or firmware according to this disclosure. Furthermore, those skilled in the art should understand that the mechanisms of the subject matter described herein can be distributed in various forms as program products, and it should be understood that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium actually used to execute the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc., and transmission media, such as digital communication media and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0221] The subjects described herein sometimes illustrate different components contained in or connected to different other components. It should be understood that the structures described are merely exemplary, and that many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components that achieve the same functionality is effectively “associated” so that the desired functionality can be achieved. Therefore, any two components in this combination that achieve a particular function can be considered “associated” with each other so that the desired functionality can be achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered to be “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be so associated can also be considered to be “operably coupled” to each other to achieve the desired functionality. Specific examples of operably coupled components include, but are not limited to, physically pairable and / or physically interactive components and / or wirelessly interactive and / or logically interactive and / or logically interactive components.

[0222] Regarding the use of any multiple and / or single term herein, those skilled in the art may convert multiple to single and / or single to multiple to suit the context and / or application. For clarity, different single / multiple substitutions may be explicitly stated herein.

[0223] Those skilled in the art will understand that, generally, the terminology used herein, especially in the appended claims (e.g., the body of the appended claims), is intended to be “open-ended” (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if it is intended to introduce a specific number of claim statements, such intention will be explicitly stated in the claims, and without such a statement, such intention does not exist. For example, the term “single” or similar language may be used where only one is intended. To aid understanding, the following appended claims and / or the description herein may contain the use of the introductory phrases “at least one” and “one or more” to introduce claim statements. However, the use of such phrases should not be construed as implying that the introduction of a claim statement by the indefinite article “a” limits any claim statement containing such an introduction to a specific claim containing only one such statement, even when the same claim includes the introductory phrase “one or more” or “at least one” and indefinite articles such as “a” (e.g., “a” should be interpreted as meaning “at least one” or “one or more”). This general usage is consistent with the use of definite articles used to introduce claim statements. Furthermore, even if a specific number of claim statements is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the number stated (e.g., the basic statement of "two statements" without other modifiers means at least two statements, or two or more statements). Additionally, in cases similar to the convention of using "at least one of A, B, and C, etc.", such a structure is generally intended to be understood by those skilled in the art in the sense of that convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In cases similar to the convention of using "at least one of A, B, or C, etc.", such a structure is generally intended to be understood by those skilled in the art in the sense of that convention (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that any inherently separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to account for the possibility of including one of these terms, either term, or both terms. For example, the phrase "A or B" will be understood to include the possibility of including "A" or "B" or "A and B".Furthermore, as used herein, the term "any" in the list of multiple items and / or multiple item categories is intended to include "any," "any combination," "any plurality," and / or "any combination of many," either alone or in combination with other items and / or other item categories. Additionally, as used herein, the term "set" or "group" is intended to include any number of items, including zero. Furthermore, as used herein, the term "quantity" is intended to include any quantity, including zero.

[0224] Furthermore, where features or aspects of this disclosure are described in a manner consistent with the Markush group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup of the Markush group.

[0225] As those skilled in the art will understand, for any and all purposes, such as by providing a written description, all scopes disclosed herein also include any and all possible subscopes and combinations thereof. Any listed scope can be readily considered sufficiently descriptive and such that the same scope can be decomposed into at least two, three, four, five, ten, etc., equal parts. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, terms such as “up to,” “at least,” “greater than,” “less than,” etc., include the listed numbers and refer to a scope that can subsequently be decomposed into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1-3 units means a group having 1, 2, or 3 units. Similarly, a group having 1-5 units means a group having 1, 2, 3, 4, or 5 units, and so on.

[0226] Furthermore, the claims should not be construed as limited to the provided order or elements unless otherwise stated. Additionally, the term "means for..." as used in any claim is intended to invoke 35 U.S.SC § 112. 6. Claims in the form of device plus function, and any claim without the term "device for..." is not so.

[0227] The software-associated processor can be used to implement radio frequency transceivers in wireless transmit / receive units (WTRUs), user equipment (UEs), terminals, base stations, MMEs, or evolved packet cores (EPCs) or any host computer. WTRUs can be used in conjunction with modules implemented in software and / or hardware, including software-defined radio (SDR), and other components such as: cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth modules, FM radio units, near-field communication (NFC) modules, liquid crystal display (LCD) units, organic light-emitting diode (OLED) display units, digital music players, media players, video game console modules, internet browsers, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0228] Although the invention has been described in the context of inventions in communication systems, it is contemplated that it can be implemented in software on a microprocessor / general-purpose computer (not shown). In some embodiments, the functions of one or more different components can be implemented in software that controls the general-purpose computer.

[0229] Furthermore, although the invention has been illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Of course, various modifications can be made to the details within the scope of the claims and without departing from the invention.

Claims

1. A method implemented by WTRU, the method comprising: Receive first information from the network node indicating the following: a new or changed network type associated with the WTRU; Receive second information from the network node indicating the following: one or more allowed network types configured for the WTRU; Determine whether the first network type of the allowed network types is rejected; as well as Send a registration request. Wherein, if the first network type is not rejected, the registration request includes third information indicating a request for the first network type serving the WTRU.

2. The method according to claim 1, further comprising the WTRU receiving a paging message before receiving the first information.

3. The method according to claim 1, further comprising: The WTRU receives the value for the timer; as well as When the timer expires, a registration update is performed.

4. The method according to claim 1, wherein, The registration request is a Non-Access Stratum (NAS) message.

5. The method according to claim 1, wherein, The first information includes Non-Access Stratum (NAS) messages.

6. The method according to claim 1, wherein, The third piece of information indicates that registration will be completed.

7. The method according to claim 1, comprising: Receive connection release message, where: The receipt of the connection release message includes receiving the value of the backoff timer; and The connection release message indicates the release of the connection with the previous network type.

8. The method according to claim 1, further comprising: The WTRU receives timing information using the first information, the timing information indicating a time redirection to the first network type used to serve the WTRU; as well as The WTRU initiates a redirection from the WTRU to the first network type used to serve the WTRU.

9. The method of claim 1, wherein, in the event that the first network type is rejected, the registration request includes an indication of a request for a different second network type serving the WTRU.

10. A wireless transmit / receive unit (WTRU), the WTRU comprising: The processor and transceiver are configured as follows: Receive first information from the network node indicating the following: a new or changed network type associated with the WTRU; Receive second information indicating the following: one or more allowed network types configured for the WTRU; Determine whether the first network type of the allowed network types is rejected; as well as Send a registration request. Wherein, if the first network type is not rejected, the registration request includes third information indicating a request for the first network type serving the WTRU.

11. The WTRU of claim 10, wherein the transceiver is configured to receive a paging message before receiving the first information.

12. The WTRU of claim 10, wherein: The transceiver is configured to receive values ​​for a timer; and The processor is configured to perform a registration update when the timer expires.

13. The WTRU according to claim 10, wherein: The transceiver is configured to receive connection release messages. The connection release message includes the value of the backoff timer and indicates the release of the connection with the previous network type.

14. The WTRU of claim 10, wherein: The transceiver is configured to receive timing information using the first information, the timing information indicating a time redirected to the first network type for serving the WTRU; as well as The processor is configured to initiate a redirection of the WTRU to the first network type used to serve the WTRU.

15. The WTRU of claim 10, wherein, in the event that the first network type is rejected, the registration request includes an indication of a request for a different second network type to serve the WTRU.

Images