Methods for communication devices, methods for user equipment (UE), communication devices, and UEs.

Abstract

Aspects of the present disclosure include a method of a communications device. The method includes sending a message. The message includes a request to send information. The information includes at least one of an identifier of a user equipment (UE(3)), location information where the UE(3) is located, video information around the UE(3), photo information around the UE(3), audio information around the UE(3), temperature information around the UE(3), vital information of a user of the UE(3), and contact information of the UE(3). The method includes receiving the information after sending the message.

Description

Technical Field

[0001] The present disclosure relates to a method of a communication device, a method of a user equipment (UE), a communication device, and a UE.

Background Art

[0002] Saving lives in disasters is an important issue for protecting people's lives. Generally, it is difficult to predict when a disaster will occur and what kind of disaster will occur, so the work is difficult. A mobile communication system can be useful for supporting rescue activities after a disaster. Paging of UEs and broadcasting of messages to UEs are equipped as basic functions in a mobile communication system.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

Non-Patent Document 4

Non-Patent Document 5

Non-licensed Document 6

Non-licensed Document 7

Non-licensed literature 9

Non-licensed literature 10

Non-licensed Document 11

Non-licensed Document 12

Non-licensed Document 13

[0004] In the event of a disaster such as an earthquake, tsunami, or volcanic eruption, rescuing people in the disaster area is extremely difficult because they may be in a critical condition, unable to make emergency calls, or their mobile phones (or user devices) may be down due to damage to base stations caused by the disaster.

[0005] In addition, rescuers are needed not only in disaster situations but also in other emergencies. For example, rescuers may need assistance with people who have fallen while hiking and are unconscious, lost children, or people who are being held captive. Even if a rescuer knows that they need to rescue someone and call them, they may not be able to pinpoint the person's exact location in an emergency because, for example, the person may not be able to answer the phone or provide sufficient information. [Means for solving the problem]

[0006] In a first exemplary embodiment, the method of a communication device includes transmitting a message, the message comprising a request for information to be transmitted, the information comprising at least one of: an identifier of a user device (UE), location information where the UE is located, video information about the UE's surroundings, photographic information about the UE's surroundings, audio information about the UE's surroundings, temperature information about the UE's surroundings, vital information of the UE's user, and contact information for the UE; and receiving information after transmitting the message.

[0007] In a second exemplary embodiment, the method of a user device (UE) includes receiving a message which includes a request for the message to transmit information which includes at least one of the following: an identifier for the UE, location information where the UE is located, video information about the UE's surroundings, photographic information about the UE's surroundings, audio information about the UE's surroundings, temperature information about the UE's surroundings, vital information about the UE's user, and contact information for the UE, and transmitting information after receiving the message.

[0008] In a third exemplary embodiment, the communication device includes means for transmitting a message, the message including a request to transmit information, the information including at least one of: an identifier for a user device (UE), location information where the UE is located, video information about the UE's surroundings, photographic information about the UE's surroundings, audio information about the UE's surroundings, temperature information about the UE's surroundings, vital information about the UE's user, and contact information for the UE; and means for receiving information after the message has been transmitted.

[0009] In a fourth exemplary embodiment, the user device (UE) includes means for receiving a message, the message includes a request to transmit information, the information including at least one of the following: an identifier for the UE, location information where the UE is located, video information about the UE's surroundings, photographic information about the UE's surroundings, audio information about the UE's surroundings, temperature information about the UE's surroundings, vital information about the UE's user, and contact information for the UE; and means for transmitting information after the message has been received. [Effects of the Invention]

[0010] According to the present disclosure, a method for a communication device, a method for a user equipment (UE), a communication device, and a UE can be provided.

Brief Description of Drawings

[0011] [Figure 1] It is a diagram schematically showing an example of the rescue target period after a disaster. [Figure 2] It is a diagram schematically showing another example of the rescue target period after a disaster. [Figure 3] It is a flowchart showing an example of a processing procedure in the first aspect. [Figure 4] It is a signaling diagram of the second example of the first aspect. [Figure 5] It is a signaling diagram of a modification of the second example of the first aspect. [Figure 6] It is a signaling diagram of the third example of the first aspect. [Figure 7] It is a signaling diagram of the first example of the second aspect. [Figure 8] It is a signaling diagram of the second example of the second aspect. [Figure 9] It is a signaling diagram of the third example of the second aspect. [Figure 10] It is a signaling diagram of the first example of the third aspect. [Figure 11] It is a signaling diagram of the second example of the third aspect. [Figure 12] It is a signaling diagram of the third example of the third aspect. [Figure 13] It is a diagram schematically showing a system to which the present invention can be applied. [Figure 14] It is a block diagram showing a UE. [Figure 15] It is a block diagram showing a (R)AN node. [Figure 16] It is a diagram showing a system overview of a (R)AN node based on an O-RAN architecture. [Figure 17] It is a block diagram showing a RU. [Figure 18]DU branch office. [Figure 19] This is the CU (Clinical Unit) branch office. [Figure 20] AMF is a type of cylinder. [Figure 21] SMF block. [Figure 22] UPF block. [Figure 23] PCF block. [Figure 24] AUSF is a block diagram. [Figure 25] UDM cylinder. [Figure 26] This is a block of NWDAF. [Figure 27] A branch of NEF. [Figure 28] This is an NSACF block. [Figure 29] IMS block. [Figure 30] PSAP Branch Office. [Modes for carrying out the invention]

[0012] (abbreviation) For the purposes of this document, 3GPP TR21.905 (Non-Patent Literature 1) and the abbreviations given below apply. Any abbreviations defined in this document take precedence over the definitions of the same abbreviations in 3GPP TR21.905 (Non-Patent Literature 1), if any. 4G-GUTI 4G Globally Unique Temporary UE Identifier 5GC 5G Core Network 5G LAN (5G Local Area Network) 5GS 5G system 5G-AN 5G Access Network 5G-AN PDB 5G Access Network Packet Latency Budget 5G-EIR 5G Device Identification Register 5G-GUTI: 5G Global Unique Temporary Identifier 5G-BRG 5G Broadband Residential Gateway 5G-CRG 5G Cable Residential Gateway 5G GM 5G Grandmaster 5G-RG 5G Residential Gateway 5G-S-TMSI 5G S Primary Mobile Subscription Identifier 5G VN (5G Virtual Network) 5QI 5G QoS Identifier AF Application Function AI artificial intelligence AMF access and mobility management functions AMF-G Geographically Selected Access and Mobility Management Functions AMF-NG Access and Mobility Management Functions Not Geographically Selected ANDSF Access Network Discovery and Selection Function AS Access Layer ATSSS Access Traffic Steering, Switching, and Splitting ATSSS-LL ATSSS Low Layer AUSF Authentication Server Function AUTN Authentication Token BCCH Broadcast Control Channel BMCA Best Master Clock Algorithm BSF Binding Support Function CAG Closed Access Group CAPIF: A common API framework for 3GPP northbound APIs. CHF charging function CN PDB Core Network Packet Latency Budget CP control plane DAPS Dual Active Protocol Stack DL Downlink DN Data Network DNAI DN Access Identifier DNN Data Network Name DRX discontinuous reception DS-TT device-side TSN translator ePDG (Advanced Packet Data Gateway) EBI EPS Bearer Identification Information EPS Advanced Packet System EUI Extended Unique Identifiers FAR Transfer Action Rules FN-BRG Fixed Network Broadband RG FN-CRG Fixed Network Cable RG FN-RG Fixed Network RG FQDN (Fully Qualified Domain Name) GFBR guaranteed flow bitrate GMLC Gateway Mobile Location Center GPSI General-Purpose Public Subscription Identifier GUAMI Globally Unique AMF Identifier GUTI Globally Unique Temporary UE Identifier HPLMN Home Public Land Mobile Network HR Home Routed (Roaming) IAB Integrated Access and Backhaul IMEI / TAC IMEI type assignment code IPUPS PLMN Inter-UP Security I-SMF Intermediate SMF I-UPF Intermediate UPF LADN Local Area Data Network LBO Local Breakout (Roaming) LMF location management function Level of LoA Automation LPP LTE Positioning Protocol LRF Location Search Function MCC Mobile Country Code MCX Mission Critical Services MDBV Maximum Data Burst Volume MFBR Maximum Flow Bitrate MICO Mobile Initiation Connection Only MITM man in the middle ML (Machine Learning) MNC Mobile Network Code MPS Multimedia Priority Service MPTCP Multipath TCP Protocol Minimum set of MSD data N3IWF Non-3GPP Interoperability Features N3GPP Non-3GPP Access N5CW Non-5G compatible on WLAN NAI (Network Access Identifier) NAS Non-Access Layer NEF Network Publishing Function NF Network Function NGAP Next Generation Application Protocol NID (Network Identifier) NPN Non-Public Network NR new radio NRF Network Repository Function NSACF Network Slice Reception Control Function NSI ID: Network Slice Instance Identifier NSSAA Network Slice-Specific Authentication and Authorization NSSAAF Network Slice-Specific Authentication and Authorization Features NSSAI Network Slice Selection Support Information NSSF Network Slice Selection Function NSSP Network Slice Selection Policy NSSRG Network Slice Simultaneous Registration Group NW-TT Network-side TSN Translator NWDAF Network Data Analysis Function PCF Policy Control Function PDB Packet Latency Budget PDR Packet Detection Rules PDU Protocol Data Unit PEI Permanent Equipment Identifier PER (Percentage of Packet Errors) PFD Packet Flow Description PLMN Public Land Mobile Network PNI-NPN Public Network Integrated Non-Public Network Differentiation of PPD paging policies PPF paging progress flag PPI Paging Policy Indicator PSA PDU Session Anchor PSAP Public Safety Response Points PTP Precision Time Protocol QFI QoS Flow Identifier Quality of Experience (QoE) RACS Wireless Function Signaling Optimization (R)AN (Wireless) Access Network RAT (Radio Access Technology) RG Residential Gateway RIM Remote Interference Management RQA Reflective QoS Attributes RQI reflective QoS indication RSN Redundant Sequence Number SA NR Standalone New Wireless SBA Service-Based Architecture SBI Service-Based Interface SCP Service Communication Proxy SD slice differentiator SDP Session Description Protocol SEAF Security Anchor Function SEPP Security Edge Protection Proxy SIP Session Initiation Protocol SMF session management function SMSF Short Message Service function SN Sequence Number SN Name: The name of the service provider network. SNPN Standalone Non-Public Network S-NSSAI Single Network Slice Selection Support Information SSC Sessions and Service Continuity SSCMSP Session and Service Continuity Mode Selection Policy SST Slice / Service Type SUCI Subscription Hidden Identifier SUPI Subscription Persistence Identifier SV Software Version TMSI (Temporary Mobile Subscriber Identification Information) TNAN Trusted Non-3GPP Access Network TNAP: A reliable non-3GPP access point TNGF Reliable Non-3GPP Gateway Functionality TNL Transport Network Layer TNLA Transport Network Layer Association TSC Time-Sensing Communication TSCAI TSC Support Information TSN Time-Sensing Network TSN GM TSN Grandmaster TSP Traffic Steering Policy TT TSN Translator TWIF (Trustworthy WLAN Interoperability) UCMF UE Radio Capability Management Function UDM (Unified Data Management) UDR Integrated Data Repository UDSF Unstructured Data Storage Function UE User Equipment UL Uplink UL CL Uplink Classifier UPF User Plane Functionality URLLC (Ultra-High Reliability, Low Latency Communication) URRP-AMF UE Reachability Requirements Parameters for AMF URSP UE Route Selection Policy VID VLAN identifier VLAN Virtual Local Area Network VPLMN Visiting Public Land Mobile Communications Network W-5GAN Wired 5G Access Network W-5GBAN Wired BBF Access Network W-5GCAN Wired 5G Cable Access Network W-AGF Wireline Access Gateway Function

[0013] (definition) For the purposes of this document, the terms and definitions given in 3GPP TR21.905 (Non-Patent Literature 1) and below shall apply. Any terms defined herein shall take precedence over any definitions of the same terms in 3GPP TR21.905 (Non-Patent Literature 1).

[0014] (General) Those skilled in the art will understand that elements in the drawings are shown for simplification and may not necessarily be drawn to scale. Furthermore, with respect to the configuration of a device, one or more components of the device may be represented in the drawings by conventional symbols, and the drawings may show only certain details relevant to understanding aspects of this disclosure so as not to obscure the drawings with details that would be readily apparent to those skilled in the art who benefit from the description herein.

[0015] For the purpose of facilitating understanding of the principles of this disclosure, the embodiments shown in the figures will be referenced and specific terminology will be used to describe them. Nevertheless, it will be understood that no limitation of the scope of this disclosure is intended therein. Such modifications and further alterations to the illustrated systems, as well as such further applications of the principles of this disclosure as would ordinarily conceivable to those skilled in the art, should be construed as being within the scope of this disclosure.

[0016] The terms “includes,” “inclusion,” or any other variation thereof are intended to encompass non-exclusive inclusion, so that a process or method including a list of steps does not include only those steps, but may include other steps not explicitly listed or specific to such process or method. Similarly, one or more devices or entities or subsystems or elements or structures or components preceded by “...includes” does not, without further constraint, exclude the existence of other devices, subsystems, elements, structures, components, additional devices, additional subsystems, additional elements, additional structures, or additional components. Throughout this specification, occurrences of the phrases “in another aspect,” “in a different aspect,” and similar wording may all refer to the same aspect, though not necessarily so.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art to which this disclosure pertains. The systems, methods, and examples provided herein are illustrative and not intended to limit the scope of this disclosure.

[0018] In the following specification and claims, several terms are referenced as having the following meanings: The singular forms ("a", "an") and "the foregoing" include plural references unless otherwise explicitly indicated by the context.

[0019] Where used herein, data is meaningful information and represents values ​​resulting from parameters; therefore, information is associated with data and knowledge. Further knowledge means an understanding of abstract or concrete concepts. Note that this exemplary system is simplified for the sake of illustrating the disclosed subject matter and is not intended to limit the scope of this disclosure. In addition to or instead of the system, other devices, systems, and configurations may be used to carry out the embodiments disclosed herein, and all such embodiments are considered to be within the scope of this disclosure.

[0020] Furthermore, each aspect and element included in each of the following aspects may be implemented independently or in any combination. These aspects contain novel features that are different from each other. Therefore, these aspects contribute to achieving different objectives or solving different problems, and contribute to gaining different advantages.

[0021] An exemplary object of this disclosure is to provide a method and apparatus that can solve the above-mentioned problems.

[0022] A method for a communication device according to an exemplary aspect of the present disclosure includes sending a message. The message includes a request to send information. The information includes at least one of the following: an identifier for a user device (UE), location information where the UE is located, video information about the UE's surroundings, photographic information about the UE's surroundings, audio information about the UE's surroundings, temperature information about the UE's surroundings, vital information of the UE's user, and contact information for the UE. The method includes receiving information after sending a message.

[0023] A user device (UE) method relating to an exemplary aspect of this disclosure includes receiving a message. The message includes a request to transmit information. The information includes at least one of the following: an identifier for the UE, location information where the UE is located, video information about the UE's surroundings, photographic information about the UE's surroundings, audio information about the UE's surroundings, temperature information about the UE's surroundings, vital information of the UE's user, and contact information for the UE. The method includes transmitting information after receiving the message.

[0024] A communication device according to an exemplary aspect of the present disclosure includes a memory and at least one hardware processor coupled to the memory. The at least one hardware processor is configured to send a message. The message includes a request to send information. The information includes at least one of the following: an identifier for a user device (UE), location information where the UE is located, video information about the UE's surroundings, photographic information about the UE's surroundings, audio information about the UE's surroundings, temperature information about the UE's surroundings, vital information of the UE's user, and contact information for the UE. The at least one hardware processor is configured to receive information after sending a message.

[0025] An exemplary user device (UE) in this disclosure includes memory and at least one hardware processor coupled to the memory. The at least one hardware processor is configured to receive messages. Messages include a request to transmit information. The information includes at least one of the following: an identifier for the UE, location information where the UE is located, video information about the UE's surroundings, photographic information about the UE's surroundings, audio information about the UE's surroundings, temperature information about the UE's surroundings, vital information of the UE's user, and contact information for the UE. The at least one hardware processor is configured to transmit information after receiving a message.

[0026] This disclosure refers to Figures 1 and 2 to identify which examples of this disclosure are applicable to the periods shown in Figures 1 and 2.

[0027] Figure 1 is a timeline showing an example of the period following a disaster, along with the respective states of the base station and UE. In this case, the base station remains operational (undamaged), meaning it is powered and the backhaul connection is maintained. However, the UE continues to operate only for a limited period, indicated as "Period 1" in Figure 1, because its battery may be depleted after a while (e.g., 24 hours). Naturally, anyone who can make a phone call, i.e., who is conscious or not restrained, is not subject to rescue under this disclosure, as they can call for rescuers.

[0028] Throughout this disclosure, the term “rescuers” may refer to, for example, police, fire departments, local government officials, mountain rangers, coast guard officers, the Self-Defense Forces, or the military.

[0029] Figure 2 is a timeline showing several exemplary periods and the respective states of the base station and UE after a disaster. In this case, the base station has lost power and can only operate for a limited period after the disaster (shown as "Period 2" in Figure 2). The UE can also continue to operate for a limited period shown as Period 2 plus Period 3 in Figure 2, as long as there is some remaining charge in the UE's battery. In other scenarios, the base station may remain operational for a longer period than the UE, in which case Periods 2 and 3 may be defined differently. It should also be understood that the respective periods for different UEs and different base stations may differ depending on (among other things) their battery levels and energy consumption. For simplicity, a common period (e.g., a single Period 2 and / or a single Period 3) may be applied to groups of UEs and / or groups of base stations as needed (but not necessarily all UEs and base stations).

[0030] (First aspect) This aspect discloses several examples of how disaster situations may be applicable to locating people in need of rescue in a disaster area. It will be understood that the term “disaster” is intended to encompass any other critical event or emergency (e.g., the situation of persons being held captive or any other public safety event). As used in this disclosure, the term “disaster area” may refer to a geographic area affected by or associated with a disaster or any other crisis / emergency. A geographic area may be defined as an area defined by relevant latitude and longitude, an area containing a set of cells (at least one cell), an administrative area (e.g., a city, district, building, and / or similar), and any combination thereof.

[0031] Since the people in the disaster area are unknown, the primary target of this approach is for rescuers to find UE identification information and their locations. Furthermore, more detailed information, such as photographs showing the environment surrounding the UE, can be useful in helping rescuers determine what approach to take when attempting to rescue the affected people.

[0032] (First example of the first aspect) A first example of the first aspect discloses a method for locating and rescuing people in a disaster area using RAN node 5.

[0033] The following describes the detailed procedure of the first example of the first embodiment with reference to Figure 3. Figure 3 shows the overall rescue procedure.

[0034] Step 1. Rescuers identify the occurrence of the disaster. Rescuers may collect information about the disaster. For example, they may collect information about the area where the disaster occurred. The area where the disaster occurred may be referred to as the disaster area.

[0035] Step 2. Based on the collected disaster information, rescuers collect status information for RAN nodes installed in the disaster area. The status information for a particular RAN node may indicate whether that RAN node is damaged by the disaster or otherwise affected by the disaster. The status information for a particular RAN node may indicate whether that particular RAN node is operational.

[0036] Step 3. Rescue personnel take appropriate action based on the status of RAN node 5.

[0037] Step 4. If RAN node 5 is damaged, the following actions can be taken depending on the damage (if known):

[0038] It should be noted that, in addition to the RAN node functions and the so-called Lifeguard APL553, RAN node 5 may also include appropriate 5GC functions, CBC functions, and IMS functions for performing search procedures. Lifeguard APL553 may be an application or program configured to run on RAN node 5. For example, memory within RAN node 5 may store Lifeguard APL553, and at least one processor within RAN node 5 coupled to memory may execute Lifeguard APL553 for processing in this disclosure. In this disclosure, a sentence in which the subject is Lifeguard APL553 may be interpreted as a sentence in which the subject is RAN node 5.

[0039] {Connection to the core network / O&M is lost while the wireless portion and power supply are operating.} - If Lifeguard APL553 determines that a search procedure needs to be performed based on a combination of various inputs, such as the loss of backhaul connectivity and the detection of a large earthquake (e.g., exceeding a relevant threshold), Lifeguard APL553 initiates the search procedure according to a pre-configured program in data storage 5531, as disclosed in the second example of the first embodiment. In this case, RAN node 5 is responsible for the rescue operation in both periods 2 and 3 of Figure 2.

[0040] {Power is lost while the connection to the core network / O&M and the wireless unit is active.} - If the lifeguard APL553 determines that it is necessary to perform a search procedure based on a combination of various inputs, such as the loss of backhaul connection and the detection of a major earthquake, the lifeguard APL553 initiates the search procedure according to a pre-configured program in the data storage 5531, as disclosed in the second example of the first embodiment. - The lifeguard APL553 can initiate communication with the rescuers to indicate that rescue operations have been initiated by RAN node 5 and the estimated time when RAN node 5 will lose battery power. In this case, RAN node 5 is responsible for the search procedure for period 2 shown in Figure 2.

[0041] Step 5. Based on the disaster information collected, rescuers activate drone RAN node 5 in the disaster area.

[0042] Information from lifeguard APL553 at RAN node 5 can also be referenced to help decide when and where drone RAN node 5 will be needed.

[0043] For example, the lifeguard APL553 at RAN node 5 indicates that the battery at RAN node 5 will last for at least 5 hours, and that drone RAN node 5 will be launched / deployed to the disaster area where RAN node 5 is located approximately 5 hours later. In this case, drone RAN node 5 will be responsible for the search procedure in period 3 shown in Figure 2.

[0044] Drone RAN Node 5 has one or more of the following characteristics: - Drone RAN node 5 includes all the normal RAN node functions as shown in RAN node 5 in Figure 15. Furthermore, the Lifeguard APL553 within the drone RAN node 5 includes 5GC, CBC, and IMS functions to perform search procedures. - The IMS function within the Lifeguard APL553 may also have a PSAP function that interacts with the IMS function. The PSAP function may handle the MSD in the IMS message and communicate with the UE3 using the communication path set by the IMS function. - Drone RAN node 5 has the ability to broadcast PLMN IDs available in the disaster area. The PLMN ID may be the one to which the damaged RAN node 5 belongs, so that all UEs belonging to that PLMN can tune into Drone RAN node 5. - Drone RAN node 5 has the ability to broadcast multiple PLMN IDs that may be available in the disaster area. All PLMN IDs operating in the disaster area are pre-configured at Drone RAN node 5. For example, all PLMN IDs that identify the PLMN(s) operating in the disaster area can be pre-configured at Drone RAN node 5. This shared RAN function can help search for UEs that have several PLMN IDs registered in the prohibited PLMN list within the UE's USIM. - Once Drone RAN Node 5 completes the search procedure, Drone RAN Node 5 returns to its designated location, either within the program or based on commands from the rescuer.

[0045] Step 6. Once the normal RAN node 5 or drone RAN node 5 completes the search procedure, rescuers begin rescue operations based on the information gathered during the search procedure at RAN node 5 and / or drone RAN node 5.

[0046] Step 7. Based on the disaster information collected and information from RAN Node 5 via O&M connection, rescuers may instruct RAN Node 5 to initiate search procedures. When RAN Node 5 is handling traffic for mobile communications, including emergency calls, rescuers may instruct RAN Node 5 to adopt search procedures that do not interfere with the handling of traffic for mobile communications. For example, rescuers may use their own UE to carry out the above instructions. If RAN Node 5 is not damaged, Step 7 can be performed.

[0047] Step 8. Once RAN Node 5 completes the search procedure, rescuers will initiate appropriate rescue operations based on the information gathered during the search procedure at RAN Node 5.

[0048] (Second example of the first aspect) A second example of the first embodiment discloses a search procedure using PWS and eCALL functions as defined in 3GPP TS23.041 (Non-Patent Document 2) and 3GPP TS23.167 (Non-Patent Document 7), respectively. The search procedure provides useful information for rescuers to locate and rescue people at a disaster site.

[0049] In this example, RAN node 5 could be a regular RAN node or a drone RAN node.

[0050] The LifeGuard APL553 in RAN node 5 includes the following functions: -CBC function: The CBC function generates write request warning request messages as defined in 3GPP TS23.041 (Non-Patent Document 2). Write request warning request messages may be replaced with write replacement warning request messages. -AMF and MME functions: The AMF and MME functions are responsible for cell broadcast message processing, mobility management, and session management. - SMF, UPF, SGW and PGW, PCRF and PCF functions: These functions are responsible for IMS eCALL session processing. -IMS function: The IMS function handles eCALLs on IMS, as defined in 3GPP TS23.167 (Non-Patent Document 7). eCALLs can be expressed as emergency calls.

[0051] LifeGuard APL363 in UE3 includes the following features: - Public Warning System (PWS) application function: When a warning message is received in the system information block, SIB, the LifeGuard APL363 digests the received message and takes appropriate action based on the request in the received message. -IMS function: The IMS function processes eCALL on IMS, as defined in 3GPP TS23.167 (Non-Patent Document 7).

[0052] LifeGuardAPL363 may be an application or program configured to run in UE3. For example, memory within UE3 may store LifeGuardAPL363, and at least one processor within UE3 coupled to memory may execute LifeGuardAPL363 for the processing described in this disclosure. In this disclosure, any sentence in which the subject is LifeGuardAPL363 may be interpreted as a sentence in which the subject is UE3.

[0053] The following describes the detailed processing of the second example of the first embodiment with reference to Figure 4. Figure 4 shows the search procedure using eCALL.

[0054] Step 1. RAN node 5 decides to initiate the search procedure. This decision may be made solely by RAN node 5 based on pre-configured decision criteria within RAN node 5, or it may be instructed by rescue personnel (e.g., via O&M communications). For example, if RAN node 5 determines that a disaster situation exists, RAN node 5 may decide to initiate the search procedure. For example, RAN node 5 may determine that a disaster situation exists based on information acquired by RAN node 5 or information received from other communication devices. The information acquired by RAN node 5 or received from other communication devices may indicate the occurrence of a disaster. For example, if it is an earthquake, RAN node 5 may acquire information indicating the occurrence of an earthquake using at least one sensor capable of acquiring seismic intensity.

[0055] Step 2. Based on the disaster situation (for example, if RAN node 5 is determined to be in a disaster situation) and instructions from the rescuers, the lifeguard APL553 generates a write request warning request message containing a message ID, warning type, and requested information parameters. The write request warning request message may be replaced by a write replacement warning request message. Instructions from the rescuers may be instructions to start a search procedure or instructions to generate a write request warning request message. The following bullet points describe some illustrative details of each parameter that may be included in the write request warning request message. -Message ID: Information that identifies the broadcasted message. In this example, it could mean "This is a request for data collection for life-saving purposes due to a disaster." This message ID is read by UE3 and routed to lifeguard APL363 within UE3. - Warning Type: The warning type indicates the type of warning. In this example, it could be, for example, "Data requested due to disaster". This parameter may be read by UE3 and routed to Lifeguard APL363. - Requested information: A message to lifeguard APL363 in UE3. This requested information may include the following: #Notification Mode: The notification mode may indicate whether an alert is needed for UE3. If an alert is needed, the type of alert is also indicated. For example, the type of alert can be at least one of the following: beep, volume level, vibration, and pop-up message. If no alert is needed, the lifeguard APL363 in UE3 will perform any requested action in the background to avoid being perceived by the UE3 user and / or other people in the vicinity. #Warning message in text: A warning message that can be read by humans. #User consent request: This indicates that the UE3 user needs consent to send information to the lifeguard APL553 in RAN node 5. #Requested information: *UE identifier: This may be the UE's IMSI, SUPI, and / or MSISDN number (or any other appropriate identifier associated with the user or UE3). *UE Location: The UE location may be given in GPS format, or it may be a location expressed in urban and geospatial location formats as defined in IETF RFC5580 (Non-Patent Document 4). *Video: You will be asked to take video clips of the surrounding scenery. *Photography: You will be asked to take pictures of the surrounding scenery. *Audio: The UE is requested to record the audio of its location. *Temperature: The temperature at the location of the UE is required. *Vital Information: If vital information is available, request measurement. This can be done if the UE is connected to a smartwatch or similar device. *Contact: Requests the user to report their contact information. The requested information may also represent information that UE3 obtains.

[0056] Furthermore, the requested information can be in the form of normalized information. For example, it can be represented numerically. In this case, the meaning of the normalized information is shared in advance between LifeGuard APL363 and LifeGuard APL553. This normalization can help reduce the amount of data transferred to LifeGuard APL363 within UE3.

[0057] Step 3. The AMF or MME function within the LifeGuard APL553 sends a write request warning request message containing a message ID, warning type, requested information, and other parameters to the RAN node function within the communication control module 552, in accordance with 3GPP TS23.041 (Non-Patent Literature 2). The write request warning request message may be replaced with a write replacement warning request message.

[0058] Step 4. The RAN node function in the communication control module 552 broadcasts the requested information on the BCCH. The RAN node function in the communication control module 552 may also broadcast a write request warning request message.

[0059] The requested information or write request warning request message may be broadcast in SIB6 as an ETWS primary notice, and / or in SIB7 as an ETWS secondary notice, and / or in SIB8 as a CMAS notice, if RAN node 5 supports NG-RAN functionality.

[0060] The requested information or write request warning request message may be broadcast in SIB10 as an ETWS primary notice, and / or in SIB11 as an ETWS secondary notice, and / or in SIB12 as a CMAS notice, if RAN node 5 supports the E-UTRAN function.

[0061] Step 5. When the communication control module 362 in UE3 receives a message broadcast on BCCH, the communication control module 362 forwards the received message to the lifeguard APL363 in UE3.

[0062] Lifeguard APL363 can be selected as the application destination by the communication control module 362 by referring to the value of the message identifier or serial number, or both, received on the SIB, in accordance with 3GPP38.331 (Non-Patent Document 5) and 3GPP36.331 (Non-Patent Document 6) for NG-RAN and E-UTRAN, respectively.

[0063] Lifeguard APL363 may be selected by the communication control module 362 as the application destination by referring to the received values ​​of the message ID and / or warning type in the warning request message corresponding to the message ID and warning type set by Lifeguard APL553 in step 2.

[0064] Furthermore, the message broadcast in step 4 can be received by UE3 even if UE3 is in a limited service state in accordance with section 4.6.4 of 3GPP22.268 (Non-Patent Literature 9). Therefore, any device in the disaster area can receive the message broadcast in step 4.

[0065] Step 6. The lifeguard APL363 in UE3 may parse the received message and decide whether to ignore the message or perform a reporting procedure. For example, the lifeguard APL363 may decide to perform a reporting procedure based on the information contained in the requested message. For example, the lifeguard APL363 may decide to perform a reporting procedure if the requested message contains the requested information. If the lifeguard APL363 decides to perform a reporting procedure, it may perform the processing described in Step 7 below as part of the reporting procedure. For example, the lifeguard APL363 may decide to ignore the message if the requested message does not contain the requested information.

[0066] Furthermore, regardless of the above judgment, the Lifeguard APL363 may perform the following actions. - Based on the received notification mode, the LifeGuard APL363 may sound a warning beep, emit a warning sound, or vibrate the UE3 to notify / warn the user of the UE3. - If a warning message is received, the received message may be displayed on the UE3 user display or read out by a speech generation application within UE3.

[0067] If a received message has a digital signature, the sender can be verified using a public key pre-configured in the data storage 3631 within the LifeGuard APL363.

[0068] Step 7. Once Lifeguard APL363 decides to initiate the reporting procedure in Step 6, Lifeguard APL363 collects all necessary data as requested by Lifeguard APL553 in Step 2.

[0069] For example, one or more of the following actions may be performed by UE3: - If the notification mode indicates that a warning to UE3 is not necessary, all processing performed by the LifeGuard APL363 in step 7 may be performed secretly (as background processing) to avoid being perceived by the UE3 user and / or other people nearby. Otherwise (for example, if the notification mode indicates that a warning to UE is necessary), the LifeGuard APL363 may notify / warn the UE3 user based on the instructions of the notification mode parameter by sounding a warning beep, sounding an alarm, or vibrating the UE3. - When a warning message is received, the received message is either displayed on the UE3 user display or read aloud by a speech generation application within UE3. - If user consent is required, LifeGuard APL363 will ask the UE3 user to indicate their preference regarding whether or not to allow data reporting. For example, this user consent may involve one of the following actions: # A pop-up message prompting the user to press a button will appear. #A voice generation application prompts the device to say YES or NO through its built-in speaker. #Negative questions can be used to obtain user consent. For example, an equipped speaker could ask the user, "If you don't want to report, please shout or say something." This can be useful if the UE3 user is unconscious and unable to do anything. For example, the LifeGuard APL363 may decide whether or not to collect and report the collected data based on the results of the inquiry, as described below. For example, if the microphone included with UE3 does not detect user speech / voice, the LifeGuard APL363 may collect and report the collected data, as described below. For example, if the microphone detects user speech / voice, the LifeGuard APL363 may not collect and report the collected data, as described below. -The following data collection may be performed. If a #UE identifier is requested (for example, the requested information includes a UE identifier), Lifeguard APL363 retrieves the identifier of UE3 (for example, at least one of UE3's IMSI, SUPI, and MSISDN numbers). Lifeguard APL363 may also retrieve the identifier of UE3 from UE3's memory. If the UE location is requested (for example, the requested information includes the UE location), the Lifeguard APL363 obtains the current location of the UE3 by interacting with the positioning / GPS application within the UE3. The current location may be expressed as location information where the UE3 is located. #If video is requested (for example, the requested information includes video), LifeGuard APL363 creates video clips of the surroundings of UE by interacting with UE3's video application and camera. LifeGuard APL363 can create video clips of the surrounding environment or scene of UE3. The video clips may be represented as video information. #If a photograph is requested (for example, the requested information includes a photograph), the LifeGuard APL363 will take several photographs of the UE's surroundings by interacting with the UE3's camera application and camera unit. The LifeGuard APL363 may take photographs of the environment or scene surrounding the UE3. The photographs may be represented as photo information or picture information. #If audio is requested (for example, if the requested information includes audio), the LifeGuard APL363 will interact with the UE3's recording application and microphone to record any noise / sound at the UE's location into one or more audio files. The LifeGuard APL363 may also record sounds from the environment or scene surrounding the UE3. The audio files and audio may be represented as audio information. #If temperature is required (for example, the requested information includes temperature), the LifeGuard APL363 measures the temperature by interacting with a thermometer application within the UE3. The LifeGuard APL363 can measure or obtain the ambient temperature of the UE. The LifeGuard APL363 may also measure or obtain information about the weather conditions around the UE3. The measured temperature may be presented as temperature information. #When vital information is requested (for example, if the requested information includes vital information), the LifeGuard APL363 measures vital information and / or accesses any pre-recorded vital information in the UE3 in order to obtain the vital information by interacting with a health monitoring application in the UE3. The LifeGuard APL363 may measure or obtain the vital information of the user in the UE3. The vital information may include vital signs such as body temperature, heart rate, respiratory rate, and blood pressure. #If contact information is requested (for example, if the requested information includes contact information), LifeGuard APL363 will provide the UE3 user's phone number and / or a pre-configured phone number (for example, an emergency contact number), the relationship to the UE3 user, etc. For example, the contact information to reply could be a family member's phone number (for example, a spouse's or parent's phone number) and current address. For example, the Lifeguard APL363 interacts with an address book application within UE3 to retrieve at least some (or all) of the contact information stored in UE3.

[0070] Step 8. Lifeguard APL363 within UE3 initiates the UE discoverable emergency session procedure as specified in section 7.7.1 of 3GPP TS23.167 (Non-Patent Document 7).

[0071] Furthermore, UE3 can initiate the UE discoverable emergency session procedure even if UE3 is in a limited service state in accordance with Section 3.5 of 3GPP23.122 (Non-Patent Literature 8). Therefore, if UE3 is 3GPP compliant, any device in the disaster area can initiate the UE discoverable emergency session procedure.

[0072] Step 9. Lifeguard APL363 in UE3 sends an initial emergency SIP invitation message to Lifeguard APL553 in RAN node 5, which includes the MSD, an eCall type emergency service indicator, and other parameters. The MSD includes the data collected by UE3 in Step 7. The eCall type of the emergency service indicator can be either automatic or manual, depending on the configuration set by the rescuer. The collected data may include at least one of the following, as described in Step 7: the identifier of UE3, the location of UE3, a photograph, an audio file, temperature, vital information, and contact information.

[0073] Step 10. When the initial emergency SIP invitation message is received by the LifeGuard APL553 at RAN node 5, the LifeGuard APL553 stores the received MSD in the data storage 5531 of RAN node 5.

[0074] Step 11. Lifeguard APL553 in RAN node 5 sends a 200 OK message containing an MSD acknowledgment to Lifeguard APL363 in UE3.

[0075] Step 12. After the MSD transfer from UE3 to RAN node 5 is successful, the emergency session is released by either LifeGuard APL553 or LifeGuard APL363. For example, if LifeGuard APL363 in UE3 receives a 200 OK message, LifeGuard APL363 may release the emergency session. For example, if LifeGuard APL553 in RAN node 5 sends a 200 OK message, LifeGuard APL553 may release the emergency session.

[0076] After step 12, the rescuer can retrieve and refer to the data in the data storage 5531 within RAN node 5 and perform appropriate rescue operations based on the collected data in the data storage 5531. For example, if the lifeguard APL 553 has stored the received MSD, the lifeguard APL 553 may notify the rescuer (e.g., the rescuer's UE) that RAN node 5 has collected the data. The rescuer can then retrieve and refer to the data in the data storage 5531 within RAN node 5.

[0077] (Modification 1 of the second example of the first embodiment) In step 10 of Figure 4, after the LifeGuard APL553 in RAN node 5 stores the received MSD in data storage 5531, the LifeGuard APL553 may request additional data from LifeGuard APL363 in UE3.

[0078] In this case, the following steps in Figure 5 can be performed between steps 11 and 12 in Figure 4. Figure 5 shows the MSD request procedure.

[0079] Step 11-1. Lifeguard APL553 on RAN node 5 sends a SIP message containing a request for MSD to Lifeguard APL363 on UE3. The request for MSD may contain all or part of the requested information, as shown in Step 2 of Figure 4. For example, the SIP message in Step 11-1 is a SIP Information (INFO) method message.

[0080] Step 11-2. Upon receiving the SIP message in Step 11-1, LifeGuard APL363 collects all the necessary data requested by LifeGuard APL553 in Step 11-1. For details on the data collection process by LifeGuard APL363, please refer to Step 7 in Figure 4.

[0081] Step 11-3. Lifeguard APL363 sends a SIP response message to Lifeguard APL553 in RAN node 5, which contains the MSD. For example, the SIP response message in step 11-3 is a SIP information method message. The MSD may include data collected by Lifeguard APL363 in step 11-2.

[0082] Step 11-4. When LifeGuard APL553 receives a SIP response message at RAN node 5, LifeGuard APL553 stores the received MSD in the data storage 5531 of RAN node 5.

[0083] (Third example of the first aspect) A third example of the first aspect discloses a search procedure using PWS and emergency call functions as defined in 3GPP TS23.041 (Non-Patent Document 2) and 3GPP TS23.167 (Non-Patent Document 7), respectively. The search procedure provides useful information for rescuers to locate and rescue people at a disaster site.

[0084] In this example, RAN node 5 could be a regular RAN node or a drone RAN node.

[0085] The Lifeguard APL553 within RAN node 5 includes one or more of the following functions: -CBC function: The CBC function generates write request warning request messages as defined in 3GPP TS23.041 (Non-Patent Document 2). Write request warning request messages may be replaced with write replacement warning request messages. -AMF and MME functions: The AMF and MME functions are responsible for cell broadcast message processing, mobility management, and session management. - SMF, UPF, SGW and PGW, PCRF and PCF functions: These functions are responsible for IMS eCALL session processing. -IMS function: The IMS function handles emergency calls on IMS, as defined in 3GPP TS23.167 (Non-Patent Document 7). -Communication Function: The communication function is responsible for communicating with the UE3 user (e.g., via the user interface). Based on the conversation with the user, the communication function understands the situation the user is facing and, if necessary, finds the best way to rescue the user. The communication function may be implemented by software within the lifeguard APL553 that can perform speech recognition and speech generation using, for example, AI and ML technologies to converse with the user. Alternatively, voice communication may be conducted with the rescuer / paramedic. In this case, a dedicated data connection is established between the rescuer (the rescuer's UE) and the lifeguard APL553, and this data connection is used for voice communication between the user using UE3 and the rescuer / rescueer via RAN node 5.

[0086] LifeGuard APL363 in UE3 includes the following features: - Public Warning System (PWS) application function: When a warning message is received in the system information block, SIB, the LifeGuard APL363 digests the received message and takes appropriate action based on the request in the received message. -IMS function: The IMS function processes eCALL on IMS, as defined in 3GPP TS23.167 (Non-Patent Document 7).

[0087] The following describes the detailed processing of the third example of the first embodiment with reference to Figure 6. Figure 6 shows the search procedure based on an emergency call.

[0088] Steps 1-7. Steps 1-7 are the same as steps 1-7 in Figure 4.

[0089] Step 8. Lifeguard APL363 in UE3 initiates MSD transfer / acknowledgment during session establishment with PSAP supporting the NG-eCall procedure, as specified in section 7.7.1 of 3GPP TS23.167 (Non-Patent Literature 7). In Step 8, the data collected in Step 7 may be sent to RAN node 5. Lifeguard APL553 may store the MSD containing the received collected data in data storage 5531 in RAN node 5.

[0090] The lifeguard APL553 on RAN node 5 collects or determines the situation the user in UE3 is facing and, if necessary, finds the best way to rescue the user. For example, the lifeguard APL553 may report at least one of the situation and the best way to rescue the user to a rescuer (e.g., the rescuer's UE). At least one of the situation and the best way to rescue the user may be included in the collected data and may be transmitted to RAN node 5.

[0091] For example, based on the collected data, the lifeguard APL553 in RAN node 5 can gather information about the situation the UE3 user is facing and, if necessary, find the best way to rescue the user.

[0092] For example, LifeGuard APL553 may transmit the UE location in the collected data to another communication device that has location information indicating the area where the disaster has occurred. The communication device then determines that the user of UE3 is affected by or may be affected by the disaster if the location indicated by the UE location falls within the area indicated by the location information. The communication device then transmits information to LifeGuard APL553 indicating that the user of UE3 is affected by or may be affected by the disaster. LifeGuard APL553 then collects information indicating that the user of UE3 is affected by or may be affected by the disaster as a situation related to that user (or UE3). For example, LifeGuard APL553 may determine that a fire truck and an ambulance are needed as the best way to rescue the user.

[0093] For example, the LifeGuard APL553 at RAN node 5 may make the above determination as to whether the user of UE3 is affected by the disaster or may be affected by the disaster, based on the location of the UE in the collected data and location information indicating the area where the disaster occurred. In this case, the LifeGuard APL553 may obtain location information indicating the area where the disaster occurred from another communication device.

[0094] For example, if Lifeguard APL553 in RAN node 5 detects a video clip or photo in the collected data indicating the occurrence of a fire (or the risk of fire), it will determine that there is a risk of fire in UE3 and that a fire truck is needed as the best way to rescue the user.

[0095] For example, if the lifeguard APL553 in RAN node 5 contains (or identifies) a scream or similar sound in an audio file within the collected data, it determines that the UE3 user is facing a dangerous situation and that calling the police is necessary as the best way to rescue the user.

[0096] For example, if the LifeGuard APL553 at RAN node 5 detects that the temperature in the collected data is low and that the vital information in the collected data indicates that the user's condition is serious, it will determine that the user's life is in danger and that an ambulance is necessary as the best way to rescue the user.

[0097] Furthermore, once a connection for voice communication is established between the UE3 and the LifeGuard APL553, the UE3 user can interact with (or use via) the LifeGuard APL553's communication function to describe the situation the user is facing and, if necessary, find the best way to rescue the user.

[0098] Furthermore, in accordance with Section 3.5 of 3GPP23.122 (Non-Patent Document 8), UE3 can initiate MSD forwarding / acknowledgment during session establishment with a PSAP that supports the NG-eCall procedure, even when UE3 is in a limited service state. Therefore, UE3 can use 3GPP (Registered trademark) If compliant, any device within the disaster area can initiate MSD forwarding / acknowledgment while establishing a session with a PSAP that supports the NG-eCall procedure.

[0099] Step 9. After the successful MSD transfer / acknowledgment during session establishment with the PSAP supporting the NG-eCall procedure, the emergency session is released by either the LifeGuard APL553 or LifeGuard APL363.

[0100] After step 9, the rescuer can collect / receive data from the MSD and store that data in the data storage 5531 within the RAN node 5. The rescuer can then refer to the collected data in the data storage 5531 within the RAN node 5 and take appropriate rescue actions based on the collected data in the data storage 5531 and conversations with the user. For example, if the lifeguard APL 553 is storing the collected data, the lifeguard APL 553 may notify the rescuer (e.g., the rescuer's UE) that the RAN node 5 has collected the data. The rescuer can then collect and refer to the data in the data storage 5531 within the RAN node 5.

[0101] (Modification 1 of the third example of the first embodiment) If UE3 is unable to provide location information to Lifeguard APL553, for example, if UE3 does not have GPS functionality and RAN node 5 is drone RAN node 5, the following steps can be taken to find the exact location of UE3. - After a connection for voice communication is established between UE3 and Lifeguard APL553 in step 8, the drone RAN node 5 may maintain the connection and begin measuring the signal strength of the radio signal from UE3 (e.g., a reference signal or any other suitable signal). - The drone RAN node 5 can measure signals from UE3 by rotating the antenna direction, and / or by using beamforming, and / or by using other radio technologies. -Based on multiple measurement results, the drone RAN node 5 finds the exact location of UE3. - The drone RAN node 5 may move closer to the UE3 based on the measurement results. In this case, in addition to the voice communication connection using the native IMS function, the LifeGuard APL553 may also have a video media connection between the LifeGuard APL553 and the UE3 to visually locate and recognize the user.

[0102] (Second aspect) This embodiment discloses several examples of how it can be effective in locating and assessing the situation of a known person in need of rescue due to an emergency. For example, in one use case, a person may become unconscious after a fall (or similar accident) while climbing. In this case, rescuers can know in advance who the person requesting rescue is, because the climber may have submitted a climbing plan that includes personal data such as their phone number.

[0103] (First example of the second aspect) A first example of the second aspect discloses a search procedure using IMS functionality as defined in 3GPP TS23.228 (Non-Patent Document 11). The search procedure is particularly useful for obtaining information about a user's location and situation when the user is known to be in an emergency situation or is considered to be in an emergency situation.

[0104] PSAP202 includes the following features: -IMS function: The IMS function handles IMS calls as defined in 3GPP TS23.228 (Non-Patent Document 11). - Warning message processing function: To support the search function, PSAP202 generates a warning message and sends it to IMS (e.g., CSCF)201. PSAP202 also receives data collected from IMS (e.g., CSCF)201. IMS201 may be or contain CSCF.

[0105] LifeGuard APL363 in UE3 includes the following features: -IMS function: The IMS function handles IMS calls as defined in 3GPP TS23.228 (Non-Patent Document 11). - Warning message processing function: When an IMS message containing a warning is received, the LifeGuard APL363 digests the received message and takes appropriate action based on the request in the received message.

[0106] Next, the detailed processing of the first example of the second embodiment will be explained using Figure 7. Figure 7 shows the person detection procedure using IMS.

[0107] Step 0. PSAP202 makes a phone call to a person suspected of being involved in an accident. For example, a worker uses PSAP202 to call a person suspected of being involved in an accident. For example, if a climber does not return from the mountain as scheduled, the worker uses PSAP202 to call the climber. If a person (a UE3 user) does not answer the phone, the worker may consider that the person-finding procedure in this disclosure may help in locating the person (for example, if the person is unable to answer the phone due to an injury or accident in the mountains).

[0108] Step 0 may not be performed, for example, if a PSAP worker attempts to make contact with a person who has been detained.

[0109] Step 1. PSAP202 decides to make (initiate) a call to find a user of UE3 who may not be able to answer or respond to the call. In this example, the worker uses PSAP202 to decide whether or not to make a call to find a user of UE3 who may not be able to answer or respond to the call. For example, if the worker instructs PSAP202 to start the search procedure, PSAP202 may decide to start the search procedure in Step 1. For example, the worker may decide to start the search procedure and instruct PSAP202 to start the search procedure. The worker may decide to start the search procedure if they have called a user of UE but have not received a response / response from the user.

[0110] Step 2. PSAP202 generates a SIP invitation message containing the requested information. The content of the requested information can be the same as the requested information described in Step 2 of Figure 4. The requested information can be expressed by parameters in the existing Session Initiation Protocol (SIP) and the relevant Session Description Protocol (SDP) as defined in 3GPP TS24.229 (Non-Patent Literature 10).

[0111] Step 3. PSAP202 sends a SIP invitation message containing the user ID and requested information. The user ID may be public user identification information, a Tel URI, or a SIP URI for UE3.

[0112] Step 4. IMS (e.g., CSCF) 201 forwards the SIP invitation message received in Step 3 to UE3.

[0113] Step 5. UE3 receives the SIP invitation message. Lifeguard APL363 within UE3 may parse the received message and decide whether to ignore it or perform a reporting procedure. For example, Lifeguard APL363 may decide to perform a reporting procedure based on the information contained in the SIP invitation message. For example, Lifeguard APL363 may decide to perform a reporting procedure if the SIP invitation message contains the requested information. If Lifeguard APL363 decides to perform a reporting procedure, it may perform the processing described in Step 6 below as part of the reporting procedure. For example, Lifeguard APL363 may decide to ignore the message if the requested message does not contain the requested information.

[0114] Furthermore, regardless of the above decision, the LifeGuard APL363 may perform one or more of the following actions: - Based on the received notification mode, the LifeGuard APL363 may notify / warn the user of the UE3 by sounding a warning beep, sounding a warning tone, or vibrating the UE3. - When a warning message is received, the received message is either displayed on the UE3 user display or read aloud by a speech generation application within UE3.

[0115] Step 6. Once Lifeguard APL363 decides to initiate the reporting procedure in Step 5, Lifeguard APL363 collects all necessary data requested by PSAP202 in Step 2.

[0116] In UE3, the following actions may be used as examples. - If the notification mode indicates that an alert to the UE is not needed, all actions performed by the LifeGuard APL363 in this step 6 may be performed secretly in the background so as not to be perceived by the UE3 user and those nearby. Otherwise (for example, if the notification mode indicates that an alert to the UE is needed), the LifeGuard APL363 may notify / warn the UE3 user by sounding an alert beep, sounding an alert tone, or vibrating the UE3, based on the instructions of the notification mode parameter. - When a warning message is received, the received message is either displayed on the UE3 user display or read aloud by a speech generation application within UE3. - If user consent is required, LifeGuard APL363 will ask the UE3 user to indicate their preference regarding whether or not to allow data reporting. For example, user consent can be obtained using one of the following processes (or any combination thereof): # A pop-up message prompting the user to press a button will appear. #A voice generation application prompts the device to say YES or NO through its built-in speaker. #Negative questions can be used to obtain user consent or preferences. For example, an equipped speaker could ask the user, "If you don't want to report, please shout or say something." This can be useful when the UE3 user is unconscious and unable to speak or act. For example, LifeGuard APL363 may decide whether or not to collect and report the collected data based on the results of querying the user, as described below. For example, if UE3 does not detect any words or sounds from the user (using its microphone), LifeGuard APL363 may collect and report the collected data, as described below. For example, if the microphone detects words or sounds from the user, LifeGuard APL363 may not have to collect and report the collected data, as described below. -The following data collection may be performed. If a #UE identifier is requested (for example, the requested information includes a UE identifier), LifeGuard APL363 retrieves the identifier of UE3 (for example, the UE3's IMSI, SUPI, or MSISDN number). LifeGuard APL363 may also retrieve the identifier of UE3 from UE3's memory. If #UE location is requested (for example, the requested information includes the UE location), the Lifeguard APL363 obtains the current location of UE3 (for example, by interacting with a GPS application within UE3). #If video is requested (for example, if the requested information includes video), the Lifeguard APL363 will create video clips of the UE by interacting with the UE3 video application and camera unit. #If photos are requested (for example, if the requested information includes photos), the LifeGuard APL363 will take several photos of the UE's surroundings by interacting with the camera application and the UE3's unit. #If audio is requested (for example, if the requested information includes audio), the Lifeguard APL363 will interact with the UE3's recording application and microphone to record any noise / sound at the UE's location into one or more audio files. #If temperature is required (for example, if the requested information includes temperature), the Lifeguard APL363 measures the temperature through interaction with a thermometer application (and any relevant thermal sensors, if applicable) within the UE3. #When vital information is requested (for example, if the requested information includes vital information), the LifeGuard APL363 will interact with the health monitoring application (and any relevant sensors, if applicable) within the UE3 to obtain the appropriate vital information and / or access any recorded vital information within the UE3. #If contact information is requested (for example, if the requested information includes contact information), LifeGuard APL363 will provide the UE3 user's phone number or a pre-configured phone number (for example, an emergency contact number), its relationship to the UE3 user, etc. For example, the contact information to reply could be the UE3 user's family phone number (for example, a spouse's or parent's phone number) and current address. For example, the Lifeguard APL363 interacts with an address book application within UE3 to retrieve at least some (or all) of the contact information stored in UE3.

[0117] Step 7. Lifeguard APL363 sends a SIP message containing the collected data to IMS (e.g., CSCF)201. The collected data includes the data collected in Step 6. The collected data may also be included in the SDP.

[0118] Step 8. IMS (e.g., CSCF) 201 forwards the SIP message received in Step 7 to PSAP 202. Upon receiving the SIP message, PSAP 202 may store the received SDP in its data storage.

[0119] After step 8, the rescuer refers to the collected data and takes appropriate rescue action. For example, if PSAP202 stores the received SDP, PSAP202 may notify the rescuer (e.g., the rescuer's UE) that PSAP202 holds the collected data. The rescuer can then retrieve and refer to the data in the data storage within PSAP202.

[0120] (Second example of the second aspect) A second example of the second aspect discloses a search procedure using a NEF as defined in 3GPP TS23.501 (Non-Patent Document 12) and 3GPP TS23.502 (Non-Patent Document 13). The search procedure is particularly useful for obtaining information about the location and circumstances of a user when the user is known to be in an emergency situation or is considered to be in an emergency situation.

[0121] PSAP202 includes the following features: - Warning message processing function: To support the search function, PSAP202 generates a warning message and sends it to NEF77. PSAP202 also receives the collected data from NEF77.

[0122] LifeGuard APL363 in UE3 includes the following features: - Warning message handling function: When LifeGuard APL363 receives a page containing a warning (paging message, system broadcast, etc.), it digests the received message and takes appropriate action based on the request in the received message.

[0123] Next, the detailed processing of the second example of the second embodiment will be explained using Figure 8. Figure 8 shows the person detection procedure using NEF.

[0124] Step 1. PSAP202 decides to initiate a search procedure to locate a user of UE3 who may be in urgent need of assistance. For example, a PSAP202 worker decides to initiate a search procedure to find a user of UE3 who may be in urgent need of assistance. For example, PSAP202 may decide to initiate a search procedure if a worker instructs PSAP202 to do so. For example, a worker can decide to initiate a search procedure and instruct PSAP202 to do so. A worker may decide to initiate a search procedure if they have made a call to a UE but have not received a response or reply from the user.

[0125] Step 2. PSAP202 generates an NEF service message containing the requested information. The content of the requested information can be the same as the requested information described in Step 2 of Figure 4.

[0126] Step 3. PSAP202 sends an Nnef_EventExposure_Subscribe message to NEF77 containing the UE ID and requested information. The UE ID may be any appropriate identifier associated with the user or UE3, such as the UE3's IMSI, SUPI, PEI, or MSISDN number. If the UE ID is a PEI or MSISDN number, NEF77 converts it to the UE3's SUPI.

[0127] Step 4. NEF77 sends the Nnef_EventExposure_Subscribe response message to PSAP202.

[0128] Step 5. NEF77 sends a Nudm_EventExposure_Subscribe message to UDM75 containing the UE ID and requested information. The UE ID can be IMSI or SUPI.

[0129] Step 6. UDM75 sends a Namf_EventExposure_Subscribe message to AMF70 containing the UE ID and requested information. The UE ID can be IMSI or SUPI.

[0130] Step 7. AMF70 sends a paging message containing the UE ID and requested information to all RAN nodes 5 in the UE3 TAI list.

[0131] Step 8. RAN node 5 receives a paging message from AMF70. RAN node 5 pages the requested information to UE3. For example, RAN node 5 can page the UE ID and the requested information to UE3.

[0132] Step 9. Upon receiving a paging message, the communication control module 362 in the UE3 recognizes the requested information and signals the lifeguard APL363 to notify it of the received message (e.g., the requested information). The lifeguard APL363 in the UE3 may parse the received message (e.g., the requested information) and decide whether to ignore the message or perform a reporting procedure. For example, the lifeguard APL363 may decide to perform a reporting procedure based on the information contained in the received message. For example, the lifeguard APL363 may decide to perform a reporting procedure if the paging message contains the requested information. If the lifeguard APL363 decides to perform a reporting procedure, it may perform the processing described in steps 10 and 11 below as part of the reporting procedure. For example, the lifeguard APL363 may decide to ignore the paging message if the paging message does not contain the requested information.

[0133] Furthermore, regardless of the above decision, the LifeGuard APL363 may perform one or more of the following actions: - Based on the received notification mode, the LifeGuard APL363 may notify / warn the user of the UE3 by sounding a warning beep, sounding a warning tone, or vibrating the UE3. - When a warning message is received, the received message is either displayed on the UE3 user display or read aloud by a speech generation application within UE3.

[0134] Step 10. Step 10 is the same as Step 6 in Figure 7.

[0135] Step 11. UE3 sends a service request message to AMF70 containing the collected data. The collected data includes any data collected in Step 10.

[0136] Step 12. AMF70 sends a Namf_EventExposure_Notify message to NEF77 containing the UE ID and collected data. The UE ID in the Namf_EventExposure_Notify message may be the same as the UE ID received in Step 6.

[0137] Step 13. NEF77 sends an Nnef_EventExposure_Notify message containing the UE ID and collected data to PSAP202.

[0138] After step 13, the rescuer refers to the collected data and takes appropriate rescue action. For example, if PSAP202 stores the received SDP, PSAP202 may notify the rescuer (e.g., the rescuer's UE) that PSAP202 holds the collected data. The rescuer can then retrieve and refer to the data in the data storage within PSAP202.

[0139] (Third example of the second aspect) A third example of the second aspect discloses a search procedure using NEF and PCF as specified in 3GPP TS23.501 (Non-Patent Document 12), 3GPP TS23.502 (Non-Patent Document 13), and TS23.503 (Non-Patent Document 14). The search procedure is particularly useful for obtaining information about the location and circumstances of a user when the user is known to be in an emergency situation or is considered to be in an emergency situation.

[0140] PSAP202 includes the following features: - Warning message processing function: To support the search function, PSAP202 generates a warning message and sends it to NEF77. PSAP202 also receives the collected data from NEF77.

[0141] LifeGuard APL363 in UE3 includes the following features: - Warning message handling function: When LifeGuard APL363 receives a page containing a warning (paging message, system broadcast, etc.), it digests the received message and takes appropriate action based on the request in the received message.

[0142] Next, the detailed processing of the second example of the second embodiment will be explained with reference to Figure 9. Figure 9 is a diagram showing the person detection procedure using NEF and PCF.

[0143] Steps 1-4 are the same as steps 1-4 in Figure 8.

[0144] Step 5. NEF77 sends an Npcf_EventExposure_Subscribe message to PCF73 containing the UE ID and requested information. The UE ID can be IMSI or SUPI. If UE3 roams out to a PLMN other than its home PLMN, PCF73 may be split into two parts: H-PCF (home) and V-PCF (visit). In this case, H-PCF uses the Npcf_EventExposure_Subscribe message to forward the message received in step 5 to V-PCF.

[0145] Step 6. PCF73 sends an Nsmf_PDUSession_TransferMTData message to SMF71 containing the UE ID and the requested information. The UE ID can be IMSI or SUPI. For example, if V-PCF received an Npcf_EventExposure_Subscribe message in Step 5, V-PCF can send an Nsmf_PDUSession_TransferMTData message to SMF71.

[0146] Step 7. SMF71 sends a Namf_Communication_N1N2MessageTransfer message to AMF70 containing the UE ID and the requested information. The UE ID can be IMSI or SUPI.

[0147] Steps 8-12. Steps 8 through 12 are the same as steps 7 through 11 in Figure 8.

[0148] Step 13: AMF70 sends an Nsmf_PDUSession_SendMOData message to SMF71 containing the UE ID and the collected data.

[0149] Step 14: SMF71 sends an Nsmf_PDUSession_TransferMOData message containing the UE ID and collected data to PCF73. If UE3 is roaming out to another PLMN, PCF73 may be split into two parts: H-PCF and V-PCF. In this case, V-PCF uses the Npcf_EventExposure_Notify message to forward the message received in Step 14 to H-PCF.

[0150] Step 15: PCF73 sends an Npcf_EventExposure_Notify message to NEF77 containing the UE ID and the collected data. For example, if H-PCF received an Nsmf_PDUSession_TransferMOData message in Step 14, H-PCF may send an Npcf_EventExposure_Notify message to NEF77.

[0151] Step 16: Step 16 is the same as Step 13 in Figure 8.

[0152] After step 16, the rescuer refers to the collected data and takes appropriate rescue action. For example, if PSAP202 stores the received SDP, PSAP202 may notify the rescuer (e.g., the rescuer's UE) that PSAP202 holds the collected data. The rescuer can then retrieve and refer to the data in the data storage within PSAP202.

[0153] (Third aspect) This embodiment discloses several examples of UE behavior when UE3 receives a message from the network requesting emergency data collection. According to this embodiment, UE3 provides information indicating whether the user of UE3 is safe or not. This information indicating whether the user of UE3 is safe or not may be used by rescuers or workers using PSAP202 to decide how to rescue the user or how to rescue them.

[0154] This embodiment is generally applicable to both the first and second embodiments when UE3 receives a message in one or more of the following situations: -When UE3 receives the broadcasted message in step 4 of Figure 4. -When the UE receives a SIP message in step 11-1 of Figure 5. -When UE3 receives the broadcasted message in step 4 of Figure 6. -In step 4 of Figure 7, when UE3 receives the SIP invitation message. -In step 8 of Figure 8, when UE3 receives a paging message containing the requested information. -In step 9 of Figure 9, when UE3 receives a paging message containing the requested information.

[0155] (First example of the third aspect) A first example of the third aspect discloses the behavior of the UE when the user of UE3 is secure. The network in Figure 10 may be RAN node 5, AMF70, and / or IMS201. Figure 10 shows the behavior of the UE when the user of UE3 is secure.

[0156] Next, the detailed processing of the first example of the third embodiment will be explained using Figure 10.

[0157] Step 1. UE3 receives an urgent message with the requested information. The message in Step 1 may be the broadcast message described above with reference to Step 4 in Figure 4, the SIP message in Step 11-1 in Figure 5, the broadcast message in Step 4 in Figure 6, the SIP invitation message in Step 4 in Figure 7, the paging message with the requested information in Step 8 in Figure 8, or the paging message with the requested information in Step 9 in Figure 9.

[0158] Step 2. When UE3 receives the message from Step 1, it sounds a loud warning and / or uses the UE3's voice generation application to make a voice announcement saying, "This is an emergency message. If you are safe, press any button on the UE."

[0159] Step 3. The UE3 user presses the button in UE3 (if the user feels safe).

[0160] Step 4. UE3 sends a message to the network that includes the appropriate UE ID for UE3, the UE location indicating the location of UE3, and a status set to "Safe Confirmed". Setting the status to "Safe Confirmed" may indicate that the user of UE3 is safe. The UE ID, UE location, and status may be included in the appropriate information elements of the message sent in Step 4 (e.g., disaster report information elements).

[0161] For example, UE3 may retrieve its UE ID (e.g., UE3's IMSI, SUPI, or MSISDN number) from its memory.

[0162] For example, UE3 can obtain its location by interacting with a GPS application within UE3.

[0163] For example, UE3 may send a message when it detects that a UE3 user has pressed a button that indicates they believe the system is safe.

[0164] For example, when the network is the RAN node 5, the UE3 may send the message in step 4 of FIG. 10 to the RAN node 5. The information included in the message in step 4 of FIG. 10 may be sent in a message as shown in step 9 of FIG. 4. The information included in the message in step 4 of FIG. 10 may also be sent in a message as shown in step 11-3 of FIG. 5. The information included in the message in step 4 of FIG. 10 may be sent together with the data collected as shown in step 8 of FIG. 6.

[0165] For example, when the network is the IMS 201, the IMS 201 can transfer the message received in step 4 to the PSAP 202. The information included in the message in step 4 of FIG. 10 may be sent in a message as shown in step 7 of FIG. 7.

[0166] For example, when the network is the AMF 70, the AMF 70 may transfer the message received in step 4 to the PSAP 202 via the NEF 77 as shown in FIG. 8. The information included in the message in step 4 of FIG. 10 may be sent in a message as shown in step 11 of FIG. 8.

[0167] For example, when the network is the AMF 70, the AMF 70 can transfer the message received in step 4 to the PSAP 202 via the SMF 71, the PCF 73, and the NEF 77 as shown in FIG. 9. The information included in the message in step 4 of FIG. 10 may be sent in a message as shown in step 12 of FIG. 9.

[0168] (Second example of the third aspect) The second example of the third aspect discloses the behavior of the UE when the user of the UE3 is unconscious or cannot interact with the UE3 for other reasons. The network in FIG. 11 may be the RAN node 5, the AMF 70, and / or the IMS 201. FIG. 11 shows the behavior of the UE when the user of the UE3 is unconscious.

[0169] Next, the detailed processing of the second example of the third aspect will be described using FIG. 11.

[0170] Step 1. UE3 receives a message indicating an emergency with the requested information. Step 1 may be the same as Step 1 in FIG. 10.

[0171] Step 2. When UE3 receives the message in Step 1, it makes a loud warning sound and / or uses the voice generation application of UE3 to make a voice announcement saying, "This is an emergency message. If you are safe, please press any button on the UE."

[0172] Step 3. The user of UE3 cannot press the button on UE3 (for example, because the user is unconscious).

[0173] Step 4. After the warning processing in Step 2 (for example, 10 seconds after the warning processing in Step 2), UE3 launches the photo APL (application) of UE3 to take some photos.

[0174] Step 5. UE3 sends a message to the network that includes the UE ID of UE3, the UE position indicating the location of UE3, the photos, and a status set to "safety not confirmed". The fact that the status is set to "safety not confirmed" may indicate that the user of UE3 may be unconscious or not safe. The UE ID, UE location, photos, and status may be included in appropriate information elements (such as disaster report information elements, etc.) of the message sent in Step 5.

[0175] For example, if the network is RAN node 5, UE3 may send the message in step 5 of Figure 11 to RAN node 5. The information contained in the message in step 5 of Figure 11 may be sent in a message as shown in step 9 of Figure 4. The information contained in the message in step 5 of Figure 11 may be sent in a message as shown in step 11-3 of Figure 5. The information contained in the message in step 5 of Figure 11 may be sent together with the collected data as shown in step 8 of Figure 6.

[0176] For example, if the network is IMS201, IMS201 can forward the message received in step 4 to PSAP202. The information contained in the message in step 5 of Figure 11 can be transmitted in the message as shown in step 7 of Figure 7.

[0177] For example, if the network is AMF70, AMF70 may forward the message received in step 4 to PSAP202 via NEF77, as shown in Figure 8. The information contained in the message in step 5 of Figure 11 may be transmitted in the message as shown in step 11 of Figure 8.

[0178] For example, if the network is AMF70, AMF70 can forward the message received in step 4 to PSAP202 via SMF71, PCF73, and NEF77, as shown in Figure 9. The information contained in the message in step 5 of Figure 11 can be transmitted in the message as shown in step 12 of Figure 9.

[0179] (Third example of the third aspect) A third example of the third embodiment discloses the behavior of the UE when the user of the UE3 is unconscious or otherwise unable to interact with the UE3. In this example, the UE3 has appropriate health measurement capabilities. For example, the UE3 may be a smartwatch UE or may be connected to a smartwatch worn by the user.

[0180] The network in Figure 12 could be RAN node 5, AMF70, and / or IMS201. Figure 12 shows the behavior of the UE when the user of UE3 with health measurement capabilities is unconscious.

[0181] Next, the detailed processing of the third example of the third embodiment will be explained with reference to Figure 12.

[0182] Step 1. UE3 receives an urgent message with the requested information. Step 1 may be the same as Step 1 in Figure 10.

[0183] Step 2. When UE3 receives the message from Step 1, it sounds a loud warning and / or uses the UE3's voice generation application to make a voice announcement saying, "This is an emergency message. If you are safe, press any button on the UE."

[0184] Step 3. The UE3 user is unable to press the buttons in UE3 (for example, because the user is unconscious).

[0185] Step 4. After the warning processing in Step 2 (for example, 10 seconds after the warning processing in Step 2), UE3 performs vital sign measurements to obtain the UE user's vital data. Previously measured vital data may be retrieved from UE3's memory.

[0186] Step 5. UE3 sends a message to the network containing the UE ID of UE3, the UE location indicating the location of UE3, the vital data obtained in Step 4, and a status set to "Vitals Confirmed". The status set to "Vitals Confirmed" may indicate that the vital data has been confirmed by the user. The status set to "Vitals Confirmed" may also indicate that the vital data has been finalized. The UE ID, UE location, vital data, and status may be included in the appropriate information element of the message sent in Step 5 (e.g., a disaster report information element).

[0187] For example, when the network is the RAN node 5, the UE 3 may send the message of step 5 in FIG. 12 to the RAN node 5. The information included in the message of step 5 in FIG. 12 may be sent in a message as shown in step 9 of FIG. 4. The information included in the message of step 5 in FIG. 12 may be sent in a message as shown in step 11-3 of FIG. 5. The information included in the message of step 5 in FIG. 12 may be sent together with the collected data as shown in step 8 of FIG. 6.

[0188] For example, when the network is the IMS 201, the IMS 201 can transfer the message received in step 4 to the PSAP 202. The information included in the message of step 5 in FIG. 12 may be sent in a message as shown in step 7 of FIG. 7.

[0189] For example, when the network is the AMF 70, the AMF 70 may transfer the message received in step 4 to the PSAP 202 via the NEF 77 as shown in FIG. 8. The information included in the message of step 5 in FIG. 12 may be sent in a message as shown in step 11 of FIG. 8.

[0190] For example, when the network is the AMF 70, the AMF 70 can transfer the message received in step 4 to the PSAP 202 via the SMF 71, the PCF 73, and the NEF 77 as shown in FIG. 9. The information included in the message of step 5 in FIG. 12 may be sent in a message as shown in step 12 of FIG. 9.

[0191] (System Overview) FIG. 13 schematically shows a mobile (cellular or wireless) communication system 1 to which each of the above-described aspects is applicable.

[0192] Telecommunication system 1 represents a system overview capable of end-to-end communication. For example, UE3 (or user equipment, "mobile device", 3) communicates with other UE3 or service servers in the data network 20 via their respective (R)AN nodes 5 and core network 7.

[0193] (R)AN Node 5 supports any radio access, including 5G radio access technology (RAT), E-UTRA radio access technology, RAT beyond 5G, 6G RAT, and non-3GPP RAT, including radio local area network (WLAN) technology as defined by the Institute of Electrical and Electronics Engineers (IEEE).

[0194] A (R)AN node 5 can be divided into one or more radio units (RUs), one or more distributed units (DUs), and one or more centralized units (CUs). In some embodiments, each of the units can be connected to one another and form a (R)AN node 5 by adopting an architecture defined by the Open RAN (O-RAN) Alliance, and the above units are referred to as O-RUs, O-DUs, and O-CUs, respectively.

[0195] (R)AN node 5 may be divided into control plane functions and user plane functions. Furthermore, multiple user plane functions may be assigned to support communication. In some embodiments, user traffic may be distributed to multiple user plane functions, and user traffic on each user plane function may be aggregated at both UE3 and (R)AN node 5. This divided architecture is sometimes called "dual connectivity" or "multi-connectivity".

[0196] (R)AN node 5 may also support communications using satellite access. In some embodiments, (R)AN node 5 may support at least one of satellite access and terrestrial access. Satellite access may also be referred to as non-terrestrial access.

[0197] Furthermore, (R)AN node 5 may be referred to as an access node for non-wireless access. Such non-wireless access may include, for example, fixed-line access as defined by the Broadband Forum (BBF) and / or optical access as defined by the Innovative Optical and Wireless Network (IOWN).

[0198] The core network 7 may include logical nodes (or "functions") for supporting communications in the telecommunications system 1. For example, the core network 7 may be a 5G core network (5GC) that includes control plane functions and user plane functions, among other functions. Each function within a logical node can be considered a network function. Network functions may be provided to other nodes by adapting a service-based architecture (SBA).

[0199] Network functions can be deployed as distributed, redundant, stateless, and scalable functions that provide services from several locations and several running instances in each location by adapting network virtualization technologies defined by the European Telecommunications Standards Institute, Network Functions Virtualization (ETSI NFV).

[0200] Core network 7 may support so-called non-public network (NPN) functionality. The NPN can be a standalone non-public network (SNPN) or a public network integrated NPN (PNI-NPN).

[0201] As is well known, UE3 can enter and exit areas (i.e., radio cells) served by (R)AN nodes 5 when UE3 is moving within a geographic area covered by telecommunications system 1. To track UE3 and facilitate movement between different (R)AN nodes 5, the core network 7 includes at least one Access and Mobility Management Function (AMF) 70. The AMF 70 communicates with (R)AN nodes 5 coupled to the core network 7. In some core networks, instead of the AMF 70, a Mobility Management Entity (MME) or a Mobility Management Node beyond 5G or a Mobility Management Node of 6G may be used.

[0202] In this example, for illustrative purposes, the core network 7 also includes, among other things, a session management function (SMF) 71, a user plane function (UPF) 72, a policy control function (PCF) 73, an authentication server function (AUSF) 74, an integrated data management function (UDM) 75, a network data analysis function (NWDAF) 76, a network exposure function (NEF) 77, and a network slice reception control function (NSACF) 78. When UE3 is roaming on a local public land mobile network (VPLMN), UE3's home public land mobile network (HPLMN) provides the roaming UE3 with the UDM 75, as well as at least some of the functions of SMF 71, UPF 72, and PCF 73.

[0203] UE3 and each Serving(R)AN node 5 are connected via an appropriate air interface (e.g., a so-called "Uu" interface). Adjacent (R)AN nodes 5 are connected to each other via an appropriate (R)AN node 5-(R)AN node interface (e.g., a so-called "Xn" interface). Each (R)AN node 5 is also connected to a node in the core network 7 (e.g., a so-called core network node) via an appropriate interface (e.g., a so-called "N2" / "N3" interface). The core network 7 also provides connectivity to the data network 20. The data network 20 can be the PLMN's internet, public network, external network, private network, or internal network. If the data network 20 is provided by a PLMN operator or mobile virtual network operator (MVNO), IP multimedia subsystem (IMS) services may be provided by that data network 20. UE3 can connect to the data network 20 using IPv4, IPv6, IPv4v6, Ethernet, or unstructured data types. The data network 20 may include the IMS201 and PSAP202 nodes described above.

[0204] The "Uu" interface may include the control plane of the Uu interface and the user plane of the Uu interface.

[0205] The user plane of the Uu interface is responsible for transmitting user traffic between UE3 and Serving(R)AN node 5. The user plane of the Uu interface may have a hierarchical structure with SDAP, PDCP, RLC, and MAC sublayers on the physical connection.

[0206] The Uu interface control plane is responsible for establishing, modifying, and releasing connections between UE3 and Serving(R)AN node 5. The Uu interface control plane may have a hierarchical structure with RRC, PDCP, RLC, and MAC sublayers via physical connections.

[0207] For example, to support AS signaling, the following messages may be communicated via the RRC layer. - RRC setup request message: This message is sent from UE3 to (R)AN node 5. In addition to the parameters disclosed in the embodiments described herein, the following parameters may be included together in the RRC setup request message. # Establishment cause and ue-identification information. The ue-identification information can take the value of ng-5G-S-TMSI-Part 1 or a random value. -RRC setup message: This message is sent from (R)AN node 5 to UE3. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the RRC setup message. #Master cell group and wireless bearer configuration -RRC setup complete message: This message is sent from UE3 to (R)AN node 5. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the RRC setup complete message. #guami-type, iab-node instruction, idle measurement available, mobile status, ng-5G-S-TMSI-part2, registered AMF, selected PLMN-identification information

[0208] The UE3 and AMF70 are connected via an appropriate interface (e.g., a so-called N1 interface). The N1 interface is an interface for communication between the UE3 and AMF70 using NAS signaling. The N1 interface may be established via 3GPP access and / or non-3GPP access. For example, the following messages may be communicated via the N1 interface. -Registration Request Message: This message is sent from UE3 to AMF70. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the registration request message. #5GS registration type, ngKSI, 5GS mobile identification information, non-current native NAS key set identifier, 5GMM capability, UE security capability, requested NSSAI, last visit registered TAI, S1 UE network capability, uplink data status, PDU session status, MICO instruction, UE status, additional GUTI, allowed PDU session status, UE usage settings, requested DRX parameters, EPS NAS message container, LADN instruction, payload container type, payload container, network slicing instruction, 5GS update type, mobile station class mark 2, supported codecs, NAS message container, EPS bearer context status, requested extended DRX parameters, T3324 value, UE radio capability ID, requested mapped NSSAI, requested information, requested WUS assistance information, N5GC instruction and requested NB-N1 DRX parameters. -Registration Acceptance Message: This message is sent from AMF70 to UE3. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the registration acceptance message. #5GS registration results, 5G-GUTI, equivalent PLMN, TAI list, permitted NSSAI, denied NSSAI, configured NSSAI, 5GS network function support, PDU session status, PDU session reactivation result, PDU session reactivation result error cause, LADN information, MICO instruction, network slicing instruction, service area list, T3512 value, non-3GPP registration timer value, T3502 value, emergency number list, extended emergency number list, SOR transparent container, EAP message, NSSAI inclusion mode, operator defined access category definition, negotiated DRX parameters, non-3GPP NW policy, EPS bearer context status, negotiated extended DRX parameters, T3447 value, T3448 value, T3324 value, UE radio capability ID, UE radio capability ID deletion instruction, pending NSSAI, encryption key data, CAG information list, truncated 5G-S-TMSI configuration, negotiated WUS support information, negotiated NB-N1 mode DRX parameters, and extended rejected NSSAI. -Registration complete message: This message is sent from UE3 to AMF70. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the registration complete message. #SOR transparent container. - Authentication request message: This message is sent from AMF70 to UE3. In addition to the parameters disclosed in the manner described herein, the authentication request message may also include the following parameters: #ngKSI, ABBA, authentication parameter RAND(5G authentication challenge), authentication parameter AUTN(5G authentication challenge), and EAP message. - Authentication response message: This message is sent from UE3 to AMF70. In addition to the parameters disclosed in the aspects described herein, the following parameters may be included in the authentication response message: # Authentication response message: Identity, authentication response parameters, and EAP message. - Authentication result message: This message is sent from AMF70 to UE3. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the authentication result message. #ngKSI, EAP messages, and ABBA. - Authentication failure message: This message is sent from UE3 to AMF70. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the authentication failure message: #Authentication failure message identifier, 5GMM cause, and authentication failure parameters. -Authentication denial message: This message is sent from AMF70 to UE3. In addition to the parameters disclosed in the manner described herein, the authentication denial message may also include the following parameters: #EAP message. - Service request message: This message is sent from UE3 to AMF70. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the service request message: #ngKSI, service type, 5G-S-TMSI, uplink data status, PDU session status, authorized PDU session status, NAS message container. -Service Acceptance Message: This message is sent from AMF70 to UE3. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the Service Acceptance Message. #PDU session status, PDU session reactivation result, PDU session reactivation result error cause, EAP message, and T3448 value. - Denial of Service Message: This message is sent from AMF70 to UE3. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the denial of service message. #5GMM cause, PDU session status, T3346 value, EAP message, T3448 value, and CAG information list. -Configuration update command message: This message is sent from AMF70 to UE3. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the configuration update command message. #Configuration update instructions, 5G-GUTI, TAI list, authorized NSSAI, service area list, network full name, network short name, local time zone (Universal Standard Time and local time zone), network daylight saving time, LADN information, MICO instructions, network slicing instructions, configured NSSAI, denied NSSAI, operator-defined access category definitions, SMS instructions, T3447 values, CAG information list, UE radio capability ID, UE radio capability ID deletion instructions, 5GS registration results, truncated 5G-S-TMSI configuration, additional configuration instructions and extended denied NSSAI. -Configuration update complete message: This message is sent from UE3 to AMF70. In addition to the parameters disclosed in the manner described herein, the following parameters may be included in the configuration update complete message. #Configuration update complete message identification information.

[0209] (User Equipment (UE)) Figure 14 is a block diagram showing the main components of UE3 (Mobile Device 3). As shown, UE3 includes a transceiver circuit 31 capable of transmitting signals to and receiving signals from nodes connected via one or more antennas 32. UE3 may also include a user interface 34 for inputting or outputting information from the outside. Although not necessarily shown in Figure 14, UE3 may have all the usual functions of a conventional mobile device, which may be provided by hardware, software, and firmware, one or any combination thereof, as needed. The software may be pre-installed in memory and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The control unit 33 controls the operation of UE3 according to the software stored in memory 36. The software includes, among other things, an operating system 361 and a communication control module 362 having at least a transceiver control module 3621. The communication control module 362 (using its transceiver control module 3621) is responsible for processing (generating / transmitting / receiving) signaling and uplink / downlink data packets between the UE3 and other nodes such as the (R)AN node 5 and AMF70. Such signaling may include, for example, appropriately formatted signaling messages relating to access and mobility management procedures (for the UE3) (e.g., registration request messages and associated response messages). The control unit 33 interacts with one or more Universal Subscriber Identity Modules (USIMs) 35. If multiple USIMs 35 are installed, the control unit 33 may activate just one USIM 35 or multiple USIMs 35 simultaneously.

[0210] Memory 36 may include LifeGuard APL363. Control unit 33 may execute LifeGuard APL363 to perform the processing of UE3 as described in this disclosure. UE3 may include associated data storage 3631. Memory 36 may include data storage 3631 (for example, as part of Lifeguard APL363).

[0211] UE3 may, for example, support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs). UE3 may be items of equipment for production or manufacturing and / or energy-related machinery (e.g., boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermoelectric generators; nuclear generators; batteries; nuclear systems and / or related equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; hydraulic equipment; pneumatic equipment; metalworking machinery; manipulators; robots and / or their application systems; tools; molds or dies; rolls; conveying equipment; elevators; material handling equipment; textile machinery; sewing equipment; printing and / or related machinery; paper conversion equipment; chemical machinery; mining machinery and / or construction machinery and / or related equipment; machinery and / or equipment for agriculture, forestry and / or fisheries; safety and / or environmental protection equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubrication equipment; valves; pipe fittings; and / or application systems for any of the aforementioned equipment or machinery, etc.).

[0212] UE3 may be items such as transportation equipment (e.g., transportation equipment such as rolled materials; automobiles; motorcycles; bicycles; trains; buses; carts; human-powered vehicles; ships and other vessels; aircraft; rockets; satellites; drones; balloons, etc.).

[0213] UE3 may be, for example, an item of information and communication equipment (e.g., information and communication equipment such as electronic computers and related equipment; communication and related equipment; electronic components, etc.).

[0214] UE3 may be, for example, refrigerators, refrigerator applications, items of goods and / or service industry equipment, vending machines, automated service machines, office equipment or machinery, consumer electronics and electronic devices (e.g., consumer electronics such as audio equipment; video equipment; speakers; radios; televisions; microwave ovens; rice cookers; coffee machines; dishwashers; washing machines; dryers; electronic fans or related equipment; vacuum cleaners, etc.).

[0215] UE3 may be, for example, an electrical application system or device (e.g., an X-ray system; a particle accelerator; a radioisotope device; a sound wave device; an electromagnetic application device; an electronic power application device, etc.).

[0216] UE3 may include, for example, electronic lamps, lighting fixtures, measuring instruments, analyzers, testers, or surveying or sensing equipment (e.g., surveying or sensing equipment such as smoke detectors; human presence sensors; motion sensors; wireless tags, etc.), wristwatches or clocks, inspection equipment, optical devices, medical equipment and / or systems, weapons, tableware items, hand tools, etc.

[0217] UE3 may be, for example, a wireless-equipped portable information terminal or related equipment (e.g., a wireless card or module designed to be attached to or inserted into another electronic device (e.g., a personal computer, an electrical measuring instrument)). UE3 may be part of a device or system that uses various wired and / or wireless communication technologies to provide the applications, services, and solutions described below with respect to the Internet of Things (IoT).

[0218] Internet of Things (IoT) devices (or “things”) may be equipped with appropriate electronics, software, sensors, network connectivity, etc., that enable them to collect and exchange data with each other and with other communication devices. IoT devices may include automated devices that follow software instructions stored in internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices may also remain stationary and / or inactive for extended periods. IoT devices may be implemented as part of (generally) fixed devices. IoT devices may also be embedded in non-fixed devices (e.g., vehicles) or attached to animals or people being monitored / tracked.

[0219] It will be understood that IoT technology can be implemented on any communication device that can connect to a communication network to send / receive data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0220] It will be understood that IoT devices are sometimes called machine-type communication (MTC) devices, machine-to-machine (M2M) communication devices, or narrowband IoT UEs (NB-IoT UEs). It will be understood that a UE3 can support one or more IoT or MTC applications.

[0221] UE3 can be a smartphone or a wearable device (e.g., smart glasses, smartwatch, smart ring, or hearable device).

[0222] UE3 may be a car, connected car, autonomous vehicle, vehicle device, motorcycle, or V2X (vehicle-to-all-things) communication module (e.g., a vehicle-to-vehicle communication module, a vehicle-to-infrastructure communication module, a vehicle-to-people communication module, and a vehicle-to-network communication module).

[0223] ((R)AN node) Figure 15 is a block diagram showing the main components of an exemplary (R)AN node 5, for example, a base station (an "eNB" in LTE, a "gNB" in 5G, a 5G base station and a 6G base station thereafter). As shown in the diagram, the (R)AN node 5 includes a transceiver circuit 51 that is capable of transmitting signals to and receiving signals from UE3 connected via one or more antennas 52, and transmitting signals to and receiving signals from other network nodes (directly or indirectly) via a network interface 53. A control unit 54 controls the operation of the (R)AN node 5 according to software stored in memory 55. The software may be pre-installed in memory and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 551 and a communication control module 552 having at least a transceiver control module 5521.

[0224] The communication control module 552 (using its transceiver control submodule) is responsible for processing (generating / transmitting / receiving) signaling between (R)AN node 5 and other nodes such as UE3, another (R)AN node 5, AMF70, and UPF72 (e.g., directly or indirectly). The signaling may include, for example, appropriately formatted signaling messages related to radio connectivity and connection with the core network 7 (for a particular UE3), particularly connection establishment and maintenance (e.g., RRC connection establishment and other RRC messages), NG Application Protocol (NGAP) messages (i.e., messages by N2 reference point) and Xn Application Protocol (XnAP) messages (i.e., messages by Xn reference point). Such signaling may also include, for example, broadcast information in the transmission case (e.g., master information and system information).

[0225] The control unit 54, once implemented, is also configured (by software or hardware) to handle related tasks such as UE mobility estimation and / or movement trajectory estimation.

[0226] (R) AN node 5 may support a non-public network (NPN), which may be a standalone non-public network (SNPN) or a public network integrated NPN (PNI-NPN).

[0227] The memory 55 may include the LifeGuard APL553. The control unit 54 can execute the LifeGuard APL553 to perform the processing of the RAN node 5 as described in this disclosure.

[0228] RAN node 5 may include data storage 5531. Memory 55 may include data storage 5531 (for example, as part of lifeguard APL553).

[0229] (System overview of (R)AN node 5 based on O-RAN architecture) Figure 16 schematically shows (R)AN node 5 based on an O-RAN architecture to which the (R)AN node 5 configuration can be applied.

[0230] A (R)AN node 5 based on the O-RAN architecture represents a system overview in which the (R)AN node is divided into a radio unit (RU) 60, a distributed unit (DU) 61, and a centralized unit (CU) 62. In some embodiments, each unit can be combined. For example, RU 60 can be integrated / coupled with DU 61 as an integration / coupled unit, and DU 61 can be integrated / coupled with CU 62 as another integration / coupled unit. Any function in the description of a unit (e.g., one of RU 60, DU 61, and CU 62) can be performed by the above integration / coupled units. Furthermore, CU 62 can be separated into two functional units, such as a CU control plane (CP) and a CU user plane (UP). The CU CP has control plane functionality in (R)AN node 5. The CU UP has user plane functionality in (R)AN node 5. Each CU CP is connected to the CU UP via an appropriate interface (such as the so-called "E1" interface).

[0231] UE3 and each serving RU60 are connected via an appropriate air interface (e.g., a so-called "Uu" interface). Each RU60 is connected to a DU61 via an appropriate interface (e.g., a so-called "fronthaul", "open fronthaul", or "F1" interface). Each DU61 is connected to a CU62 via an appropriate interface (e.g., a so-called "midhaul", "open midhaul", or "E2" interface). Each CU62 is also connected to a node in the core network 7 (a so-called core network node) via an appropriate interface (e.g., a so-called "backhaul", "open backhaul", or "N2" / "N3" interface). Furthermore, the user plane portion of the DU61 can also be connected to the core network node 7 via an appropriate interface (e.g., a so-called "N3" interface).

[0232] Depending on the functions divided among RU60, DU61, and CU62, each unit provides a portion of the functions provided by (R)AN node 5. For example, RU60 can provide the function for communicating with UE3 via the air interface, DU61 can provide the function for supporting the MAC and RLC layers, and CU62 can provide the function for supporting the PDCP, SDAP, and RRC layers.

[0233] (Wireless Unit (RU)) Figure 17 is a block diagram showing the main components of the RU portion of an exemplary RU60, for example, a base station (an "eNB" in LTE, a "gNB" in 5G, a 5G base station and a 6G base station). As shown in the diagram, the RU60 includes a transceiver circuit 601 that is operable to transmit signals to and receive signals from UE3 connected via one or more antennas 602, and to transmit signals to and receive signals from other network nodes or network units (directly or indirectly) via a network interface 603. The control unit 604 controls the operation of the RU60 according to software stored in memory 605. The software may be pre-installed in memory and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 6051 and a communication control module 6052 having at least a transceiver control module 60521.

[0234] The communication control module 6052 is responsible for handling (generating / transmitting / receiving) signaling (e.g., directly or indirectly) between the RU60 and other nodes or units such as UE3, another RU60, and DU61 (using its transceiver control submodule). The signaling may include, for example, appropriately formatted signaling messages regarding radio connectivity and connections with the RU60 (for a particular UE3), particularly concerning the MAC and RLC layers.

[0235] The control unit 604, once implemented, is also configured (by software or hardware) to handle related tasks such as UE mobility estimation and / or movement trajectory estimation.

[0236] RU60 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0237] As described above, RU60 can be integrated / coupled with DU61 as an integration / coupling unit. Any functionality described in the RU60 description can be implemented in the above integration / coupling unit.

[0238] (Distributed Unit (DU)) Figure 18 is a block diagram showing the main components of the DU section of an exemplary DU61, for example, a base station (an "eNB" in LTE, a "gNB" in 5G, a 5G base station and a 6G base station). As shown in the diagram, the device includes a transceiver circuit 611 that is operable to transmit signals to and receive signals from other nodes or units (including RU60) via a network interface 612. A control unit 613 controls the operation of the DU61 according to software stored in memory 614. The software may be pre-installed in memory 614 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 6141 and a communication control module 6142 having at least a transceiver control module 61421. The communication control module 6142 (using its transceiver control module 61421) is responsible for handling (generating / transmitting / receiving) signaling between the DU61 and RU60 and other nodes or units such as other nodes and units.

[0239] DU61 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0240] As described above, RU60 can be integrated / combined with DU61 or CU62 as an integration / combination unit. Any function described in the DU61 description can be performed by one of the above integration / combination units.

[0241] (Centralized Unit (CU)) Figure 19 is a block diagram showing the main components of the CU portion of an exemplary CU62, for example, a base station (an "eNB" in LTE, a "gNB" in 5G, a 5G base station and a 6G base station). As shown in the diagram, the device includes a transceiver circuit 621 that is operable to transmit signals to and receive signals from other nodes or units (including a DU61) via a network interface 622. A control unit 623 controls the operation of the CU62 according to software stored in memory 624. The software may be pre-installed in memory 624 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 6241 and a communication control module 6242 having at least a transceiver control module 62421. The communication control module 6242 (using its transceiver control module 62421) is responsible for handling (generating / transmitting / receiving) signaling between CU62 and DU61 and other nodes or units such as other nodes and units.

[0242] CU62 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0243] As described above, CU62 can be integrated / coupled with DU61 as an integration / coupling unit. Any function described in the CU62 description can be implemented in the above integration / coupling unit.

[0244] (AMF) Figure 20 is a block diagram showing the main components of the AMF70. As shown, the device includes a transceiver circuit 701 that can operate to transmit signals to and receive signals from other nodes (including UE3) via a network interface 702. A control unit 703 controls the operation of the AMF70 according to software stored in memory 704. The software may be pre-installed in memory 704 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 7041 and a communications control module 7042 having at least a transceiver control module 70421. The communications control module 7042 is responsible for handling (generating / transmitting / receiving) signaling between the AMF70 and other nodes, such as UE3 (e.g., via (R)AN node 5) and other core network nodes (including core network nodes in UE3's HPLMN when UE3 is roaming in) (using its transceiver control module 70421). Such signaling could include, for example, well-formatted signaling messages related to access and mobility management procedures (for UE3) (e.g., registration request messages and associated response messages).

[0245] The AMF70 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0246] (SMF) Figure 21 is a block diagram showing the main components of the SMF71. As shown, the device includes a transceiver circuit 711 that can operate to send signals to and receive signals from other nodes (including the AMF70) via a network interface 712. A control unit 713 controls the operation of the SMF71 according to software stored in memory 714. The software may be pre-installed in memory 714 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 7141 and a communications control module 7142 having at least a transceiver control module 71421. The communications control module 7142 (using its transceiver control module 71421) is responsible for handling (generating / transmitting / receiving) signaling between the SMF71 and other nodes such as the UPF72 and other core network nodes (including the core network nodes in the HPLMN of the UE3 when the UE3 is roaming in). Such signaling may include, for example, well-formatted signaling messages related to session management procedures (for UE3) (e.g., restful methods of the Hypertext Transfer Protocol (HTTP) based on a service-based interface).

[0247] SMF71 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0248] (UPF) Figure 22 is a block diagram showing the main components of UPF72. As shown, the device includes a transceiver circuit 721 that can operate to transmit signals to and receive signals from other nodes (including SMF71) via a network interface 722. A control unit 723 controls the operation of UPF72 according to software stored in memory 724. The software may be pre-installed in memory 724 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (e.g., a removable memory device (RMD)). The software includes, among other things, an operating system 7241 and a communications control module 7242 having at least a transceiver control module 72421. The communications control module 7242 (using its transceiver control module 72421) is responsible for handling (generating / transmitting / receiving) signaling between UPF72 and other nodes such as SMF71 and other core network nodes (including core network nodes in the HPLMN of UE3 when UE3 is roaming in). Such signaling could include, for example, well-formatted signaling messages related to user data processing (for UE3) (e.g., GPRS Tunneling Protocol (GTP) for the user plane).

[0249] UPF72 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0250] A collated gNB-CU-UP and UPF, or a communication device that performs the functions of a collated gNB-CU-UP and UPF, or a communication device that performs the functions of a gNB-CU-UP and a UPF, may have the same components as UPF72.

[0251] (PCF) Figure 23 is a block diagram showing the main components of the PCF73. As shown, the device includes a transceiver circuit 731 that can operate to send signals to and receive signals from other nodes (including AMF70) via a network interface 732. The control unit 733 controls the operation of the PCF73 according to software stored in memory 734. The software may be pre-installed in memory 734 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (e.g., a removable memory device (RMD)). The software includes, among other things, an operating system 7341 and a communications control module 7342 having at least a transceiver control module 73421. The communications control module 7342 (using its transceiver control module 73421) is responsible for handling (generating / transmitting / receiving) signaling between the PCF73 and other nodes such as AMF70 and other core network nodes (including core network nodes in the HPLMN of the UE3 when the UE3 is roaming in). Such signaling could include, for example, well-formatted signaling messages related to policy management procedures (for UE3) (e.g., a restful HTTP method based on a service-based interface).

[0252] PCF73 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs). H-PCF and V-PCF may contain the same components as PCF73.

[0253] (AUSF) Figure 24 is a block diagram showing the main components of AUSF74. As shown, the device includes a transceiver circuit 741 that can operate to transmit signals to and receive signals from other nodes (including UDM75) via a network interface 742. A control unit 743 controls the operation of AUSF74 according to software stored in memory 744. The software may be pre-installed in memory 744 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (e.g., a removable memory device (RMD)). The software includes, among other things, an operating system 7441 and a communications control module 7442 having at least a transceiver control module 74421. The communications control module 7442 (using its transceiver control module 74421) is responsible for handling (generating / transmitting / receiving) signaling between AUSF74 and other nodes such as AMF70 and other core network nodes (including core network nodes in the HPLMN of UE3 when UE3 is roaming in). Such signaling could include, for example, well-formatted signaling messages related to policy management procedures (for UE3) (e.g., a restful HTTP method based on a service-based interface).

[0254] AUSF74 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0255] (UDM) Figure 25 is a block diagram showing the main components of the UDM75. As shown, the device includes a transceiver circuit 751 that can operate to transmit signals to and receive signals from other nodes (including the AMF70) via a network interface 752. A control unit 753 controls the operation of the UDM75 according to software stored in memory 754. The software may be pre-installed in memory 754 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 7541 and a communications control module 7542 having at least a transceiver control module 75421. The communications control module 7542 (using its transceiver control module 75421) is responsible for handling (generating / transmitting / receiving) signaling between the UDM75 and other nodes such as the AMF70 and other core network nodes (including core network nodes in the VPLMN of the UE3 when the UE3 is roaming out). Such signaling could include, for example, well-formatted signaling messages related to mobility management procedures (for UE3) (e.g., a restful HTTP method based on a service-based interface).

[0256] UDM75 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0257] (NWDAF) Figure 26 is a block diagram showing the main components of the NWDAF76. As shown, the device includes a transceiver circuit 761 that can operate to transmit signals to and receive signals from other nodes (including AMF70) via a network interface 762. A control unit 763 controls the operation of the NWDAF76 according to software stored in memory 764. This software may, for example, be pre-installed in memory 764 and / or downloaded via a telecommunications network or from a removable data storage device (e.g., a removable memory device (RMD)). The software includes, among other things, an operating system 7641 and a communications control module 7642 having at least a transceiver control module 76421. The communications control module 7642 (using its transceiver control module 76421) is responsible for handling (generating / transmitting / receiving) signaling between the NWDAF76 and other nodes such as AMF70 and other core network nodes (including core network nodes in the HPLMN of UE3 when UE3 is roaming in). Such signaling could include, for example, well-formatted signaling messages related to network data analysis functionality procedures (for UE3) (e.g., a restful HTTP method based on a service-based interface).

[0258] NWDAF76 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0259] (NEF) Figure 27 is a block diagram showing the main components of the NEF77. As shown, the device includes a transceiver circuit 771 that can operate to transmit signals to and receive signals from other nodes (including UDM75) via a network interface 772. A control unit 773 controls the operation of the NEF77 according to software stored in memory 774. The software may be pre-installed in memory 774 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (e.g., a removable memory device (RMD)). The software includes, among other things, an operating system 7741 and a communications control module 7742 having at least a transceiver control module 77421. The communications control module 7742 (using its transceiver control module 77421) is responsible for handling (generating / transmitting / receiving) signaling between the NEF77 and other nodes such as UDM75 and other core network nodes (including core network nodes in the HPLMN of UE3 when UE3 is roaming in). Such signaling could include, for example, well-formatted signaling messages related to network exposure functionality procedures (for UE3) (e.g., a restful HTTP method based on a service-based interface).

[0260] NEF77 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0261] (NSACF) Figure 28 is a block diagram showing the main components of NSACF78. As shown, the device includes a transceiver circuit 781 that can operate to transmit signals to and receive signals from other nodes (including AMF70) via a network interface 782. A control unit 783 controls the operation of NSACF78 according to software stored in memory 784. This software may, for example, be pre-installed in memory 784 and / or downloaded via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 7841 and a communications control module 7842 having at least a transceiver control module 78421. The communications control module 7842 (using its transceiver control module 78421) is responsible for handling (generating / transmitting / receiving) signaling between NSACF78 and other nodes such as AMF70 and other core network nodes (including core network nodes in the HPLMN of UE3 when UE3 is roaming in). Such signaling could include, for example, well-formatted signaling messages related to network data analysis functionality procedures (for UE3) (e.g., a restful HTTP method based on a service-based interface).

[0262] NSACF78 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0263] (IMS) Figure 29 is a block diagram showing the main components of IMS201. As shown, the device includes a transceiver circuit 2011 that can operate to transmit signals to and receive signals from other nodes (including UE3, NEF77, and PSAP202) via a network interface 2012. A control unit 2013 controls the operation of IMS201 according to software stored in memory 2014. The software may be pre-installed in memory 2014 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 20141 and a communication control module 20142 having at least a transceiver control module 201421. The communications control module 20142 (using its transceiver control module 201421) is responsible for handling (generating / transmitting / receiving) signaling between IMS201 and other nodes such as UE3, NEF77 or PSAP202 and other core network nodes (including core network nodes in UE3's VPLMN when UE3 is roaming out). Such signaling may include, for example, well-formatted signaling messages related to mobility management procedures (for UE3) (e.g., a restful HTTP method based on a service-based interface).

[0264] IMS201 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs). IMS(CSCF) may include the same components as IMS201 described in the above embodiment.

[0265] (PSAP) Figure 30 is a block diagram showing the main components of the PSAP202. As shown, the device includes a transceiver circuit 2011 that can operate to transmit signals to and receive signals from other nodes (including NEF77 and IMS201) via a network interface 2012. A control unit 2013 controls the operation of the PSAP202 according to software stored in memory 2014. The software may be pre-installed in memory 2014 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 20141 and a communication control module 20142 having at least a transceiver control module 201421. The communications control module 20142 (using its transceiver control module 201421) is responsible for handling (generating / transmitting / receiving) signaling between PSAP202 and other nodes such as NEF77 or IMS201 and other core network nodes (including core network nodes in the UE3's VPLMN when the UE3 is roaming out). Such signaling may include, for example, well-formatted signaling messages related to mobility management procedures (for the UE3) (e.g., a restful HTTP method based on a service-based interface).

[0266] PSAP202 may support non-public networks (NPNs), which may be standalone non-public networks (SNPNs) or public network integrated NPNs (PNI-NPNs).

[0267] (Variations and alternative examples) Detailed embodiments have been described above. As those skilled in the art will understand, several modifications and substitutions can be made to the above embodiments, but still benefit from the disclosures embodied therein. Only a few of these substitutions and modifications are described here as examples.

[0268] For the sake of clarity, the above description assumes that the UE3 and network device have several separate modules (such as a communications control module). These modules may be provided in this way for specific applications, such as existing systems being modified to implement this disclosure, as well as for other applications, such as systems designed from the outset with the features of the present invention in mind. However, because these modules may be integrated into the overall operating system or code, they may not be identifiable as separate entities. These modules may be implemented in software, hardware, firmware, or a combination thereof.

[0269] Each control unit may include, for example (but not limited to), any suitable form of processing circuitry, including one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuits, internal memory / cache (programs and / or data), processing registers, communication buses (e.g., control buses, data buses and / or address buses), direct memory access (DMA) functions, hardware or software-implemented counters, pointers and / or timers. In the embodiments described above, numerous software modules have been described. As those skilled in the art will understand, the software modules may be provided in compiled or uncompiled form and may be supplied to the UE3 and network equipment as signals via a computer network or on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred because it facilitates the updating of the UE3 and network equipment to update their functions.

[0270] In the above embodiment, 3GPP wireless communication (wireless access) technology is used. However, any other wireless communication technology (e.g., WLAN, Wi-Fi, WiMAX, Bluetooth) may be used. (Registered trademark) Other fixed-line communication technologies (e.g., BBF access, cable access, optical access, etc.) may also be used in accordance with the above-described manner.

[0271] User equipment items may include, for example, communication devices such as mobile phones, smartphones, user devices, personal digital assistants, laptop / tablet computers, web browsers, and e-book readers. Such mobile (or generally fixed) devices are typically operated by a user, but it is also possible to connect so-called "Internet of Things" (IoT) devices and similar machine-type communication (MTC) devices to a network. For simplicity, this application refers to mobile devices (or UEs) in the description, but it will be understood that the described technology can be implemented on any communication device (mobile and / or generally fixed) that can connect to a communication network to send and receive data, whether such communication devices are controlled by human input or software instructions stored in memory. Various other modifications will be obvious to those skilled in the art and will not be described in further detail here.

[0272] As those skilled in the art will understand, this disclosure can be embodied as a method and / or system. Accordingly, this disclosure can take the form of entirely hardware embodiments, software embodiments, or embodiments combining software and hardware aspects.

[0273] It will be understood that each block in the block diagram can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general-purpose computer, a dedicated computer, or another programmable data processing device in order to manufacture a machine, such that instructions executed via the processor of a computer or other programmable data processing device create means for performing the functions / operations specified in one or more blocks of the flowchart and / or block diagram. The general-purpose processor may be a microprocessor, but instead, the processor may be any conventional processor, control unit, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, e.g., multiple microprocessors, one or more microprocessors, or any other such configuration.

[0274] Methods or algorithms described in relation to the examples disclosed herein may be embodied directly in hardware, software modules executed by a processor, or a combination of the two. The software modules may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art. The storage medium may be coupled to the processor so that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor. The processor and storage medium may reside within an ASIC.

[0275] The above-mentioned descriptions of the disclosed examples are provided to enable those skilled in the art to create or use this disclosure. Various modifications to these examples will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other examples without departing from the spirit or scope of this disclosure. Accordingly, this disclosure is not intended to be limited to the examples shown herein, but should be given the broadest scope consistent with the principles and novel features disclosed herein.

[0276] This disclosure is shown and described in particular with reference to its exemplary embodiments, but is not limited to these embodiments. Those skilled in the art will understand that various modifications of form and detail can be made without departing from the spirit and scope of this disclosure as defined herein. For example, it is applicable not only to 5GS but also to other communication systems (e.g., 6G systems, Beyond 5G systems).

[0277] (Note) All or part of the exemplary embodiments disclosed above may be described as follows, but are not limited to these. (Note 1) It is about sending a message, The message includes a request to send information. The information includes at least one of the following: user device (UE) identifier, location information of the UE, video information of the UE's surroundings, photographic information of the UE's surroundings, audio information of the UE's surroundings, temperature information of the UE's surroundings, vital information of the UE's user, and contact information of the UE. Including receiving information after sending a message. Methods for communication devices. (Note 2) The message will be sent in the event of a disaster. The method described in Appendix 1. (Note 3) The information includes information indicating whether the UE user is safe or not. The method described in Appendix 1 or 2. (Note 4) Receiving a message, The message includes a request to send information. The information includes at least one of the following: user device (UE) identifier, location information of the UE, video information of the UE's surroundings, photographic information of the UE's surroundings, audio information of the UE's surroundings, temperature information of the UE's surroundings, vital information of the UE's user, and contact information of the UE. Sending information after receiving a message, and including UE method. (Note 5) The message will be sent in the event of a disaster. The method described in Appendix 4. (Note 6) The information includes information indicating whether the UE user is safe or not. The method described in Appendix 4 or 5. (Note 7) A means of sending a message, The message includes a request to send information. The information includes at least one of the following: a user device (UE) identifier, location information of the UE, video information of the UE's surroundings, photographic information of the UE's surroundings, audio information of the UE's surroundings, temperature information of the UE's surroundings, vital information of the UE's user, and contact information of the UE. Includes means for receiving information after sending a message. Communication device. (Note 8) The message will be sent in the event of a disaster. The communication device described in Appendix 7. (Note 9) The information includes information indicating whether the UE user is safe or not. Communication device as described in Appendix 7 or 8. (Note 10) A means of receiving a message, The message includes a request to send information. The information includes at least one of the following: a user device (UE) identifier, location information of the UE, video information of the UE's surroundings, photographic information of the UE's surroundings, audio information of the UE's surroundings, temperature information of the UE's surroundings, vital information of the UE's user, and contact information of the UE. A means for sending information after receiving a message, including UE. (Note 11) The message will be received in the event of a disaster. UE as described in Appendix 10. (Note 12) The information includes information indicating whether the UE user is safe or not. UE as described in Appendix 10 or 11.

[0278] This application claims priority under Indian Patent Application No. 202211014351, filed on 16 March 2022, the disclosure of which is incorporated herein by reference in its entirety. [Explanation of Symbols]

[0279] 3 UE 31 Transceiver Circuit 32 Antennas 33 Control Unit 34 User Interface 35 USIM 36 memory 361 Operating Systems 362 Communication control module 3621 Transceiver Control Module 363 Lifeguard APL 3631 Data Storage 5 RANNode 51 Transceiver Circuit 52 Antennas 53 Network Interfaces 54 Control Unit 55 memory 551 Operating Systems 552 Communication control module 5521 Transceiver Control Module 553 Lifeguard APL 5531 Data Storage 60 RU 601 Transceiver Circuit 602 Antenna 603 Network Interface 604 Control Unit 605 memory 6051 Operating System 6052 Communication Control Module 60521 Transceiver Control Module 61 DU 611 Transceiver Circuit 612 Network Interfaces 613 Control Unit 614 memory 6141 Operating Systems 6142 Communication control module 61421 Transceiver Control Module 62 CU 621 Transceiver Circuit 622 Network Interfaces 623 Control Unit 624 memory 6241 Operating Systems 6242 Communication control module 62421 Transceiver Control Module 7 Core Network 70 AMF 701 Transceiver Circuit 702 Network Interface 703 Control Unit 704 memory 7041 Operating System 7042 Communication control module 70421 Transceiver Control Module 71 SMF 711 Transceiver Circuit 712 Network Interfaces 713 Control Unit 714 memory 7141 Operating Systems 7142 Communication control module 71421 Transceiver Control Module 72 UPF 721 Transceiver Circuit 722 Network Interfaces 723 Control Unit 724 memory 7241 Operating Systems 7242 Communication control module 72421 Transceiver Control Module 73 PCF 731 Transceiver Circuit 732 Network Interfaces 733 Control Unit 734 memory 7341 Operating Systems 7342 Communication control module 73421 Transceiver Control Module 74 AUSF 741 Transceiver Circuit 742 Network Interfaces 743 Control Unit 744 memory 7441 Operating Systems 7442 Communication control module 74421 Transceiver Control Module 75 UDM 751 Transceiver Circuit 752 Network Interfaces 753 Control Unit 754 memory 7541 Operating Systems 7542 Communication control module 75421 Transceiver Control Module 76 NWDAF 761 Transceiver Circuit 762 Network Interfaces 763 Control Unit 764 memory 7641 Operating Systems 7642 Communication control module 76421 Transceiver Control Module 77 NEF 771 Transceiver Circuit 772 Network Interfaces 773 Control Unit 774 memory 7741 Operating System 7742 Communication control module 77421 Transceiver Control Module 78 NSACF 781 Transceiver Circuit 782 Network Interfaces 783 Control Unit 784 memory 7841 Operating System 7842 Communication control module 78421 Transceiver Control Module 20 Data Networks 201 IMS 2011 Transceiver Circuit 2012 Network Interface 2013 Control Unit 2014 Memory 20141 Operating Systems 20142 Communication Control Module 201421 Transceiver Control Module 202 PSAP 2021 Transceiver Circuit 2022 Network Interface 2023 Control Unit 2024 memory 20241 Operating Systems 20242 Communication Control Module 202421 Transceiver Control Module

Claims

1. Transmitting a first message to a user device (UE), The first message includes a request for the UE to automatically retrieve and transmit information, The information includes photographic information of the surroundings of the UE, and vital information including the vital signs of the user of the UE. This includes receiving the information after sending the first message, The first message mentioned above is, When the UE receives the first message, the UE is instructed to prompt the user of the UE to press the button on the UE. After the above instructions are given, the UE is instructed to automatically take a photograph and send a second message containing the photograph and information indicating that the user may not be safe, and after the above instructions are given, to automatically measure the vital information and send a third message containing the vital information and information indicating that the vital information has been confirmed by the user or that the vital information has been finalized. The aforementioned photographic information is used by the communication device to determine that a fire truck is needed if the photographic information contains information related to a fire. The aforementioned vital information is used by the communication device to determine if an ambulance is needed. Methods for communication devices.

2. Receiving the first message, The first message includes a request for the user device (UE) to automatically acquire and transmit information. The information includes photographic information of the surroundings of the UE, and vital information including the vital signs of the user of the UE. This includes automatically acquiring and transmitting the information after receiving the first message, Automatically acquiring and transmitting the information after receiving the first message is: Upon receiving the first message, the user of the UE is instructed to press the button on the UE, After the aforementioned instructions are given, the system automatically takes a photograph and sends a second message containing the photograph and information indicating that the user may not be safe; and after the aforementioned instructions are given, the system automatically measures the vital information and sends a third message containing the vital information and information indicating that the vital information has been confirmed by the user or that the vital information has been finalized. Includes, The aforementioned photographic information is used to determine that a fire truck is needed if the photographic information contains information related to a fire. The aforementioned vital information is used to determine whether an ambulance is necessary. UE's method.

3. A means for transmitting a first message to a user device (UE), The first message includes a request for the UE to automatically retrieve and transmit information, The means includes photographic information of the surroundings of the UE and vital information including the vital signs of the user of the UE. The system includes means for receiving the information after sending the first message, The first message mentioned above is, When the UE receives the first message, the UE is instructed to prompt the user of the UE to press the button on the UE. After the above instructions are given, the UE is instructed to automatically take a photograph and send a second message containing the photograph and information indicating that the user may not be safe, and after the above instructions are given, to automatically measure the vital information and send a third message containing the vital information and information indicating that the vital information has been confirmed by the user or that the vital information has been finalized. The aforementioned photographic information is used by the communication device to determine that a fire truck is needed if the photographic information contains information related to a fire. The aforementioned vital information is used by the communication device to determine if an ambulance is needed. Communication device.

4. A means for receiving a first message, The first message includes a request for the user device (UE) to automatically acquire and transmit information. The means includes photographic information of the surroundings of the UE and vital information including the vital signs of the user of the UE. The system includes means for automatically acquiring and transmitting the information after receiving the first message, The means for automatically acquiring and transmitting the information after receiving the first message is: Upon receiving the first message, the user of the UE is instructed to press the button on the UE, After the aforementioned instructions are given, a photograph is automatically taken and a second message is sent containing the photograph and information indicating that the user may not be safe; and after the aforementioned instructions are given, the vital information is automatically measured and a third message is sent containing the vital information and information indicating that the vital information has been confirmed by the user or that the vital information has been finalized. Execute, The aforementioned photographic information is used to determine that a fire truck is needed if the photographic information contains information related to a fire. The aforementioned vital information is used to determine whether an ambulance is necessary. UE.

Images