Method, system and computer readable medium for dynamically providing and using public land mobile network (PLMN) location mapping in a service capability exposure function (SCEF) or a network exposure function (NEF)

Abstract

A method for dynamically providing and using PLMN location mapping includes, in a SCEF or NEF, receiving a message including a PLMN location identifier and a non-PLMN location identifier from a PLMN network node, extracting the PLMN location identifier and the non-PLMN location identifier from the message, and storing the mapping between the PLMN location identifier and the non-PLMN location identifier in a PLMN location mapping database in the SCEF or NEF. The method also includes, via a monitoring interface of the SCEF or NEF, receiving a monitoring request message requesting IoT device information and including a non-PLMN location identifier. The method also includes locating an entry corresponding to the non-PLMN location identifier in a PLMN location mapping database, extracting the PLMN location identifier from the database, obtaining IoT device information using the PLMN location identifier extracted from the database, and responding to the monitoring request message with the IoT device information.

Description

[0001] Priority claim

[0002] This application claims priority to U.S. patent application serial number 16 / 287,808, filed on February 27, 2019, which is incorporated herein by reference in its entirety. Technical Field

[0003] The subject matter described herein relates to providing and using PLMN location mappings in a database. More specifically, the subject matter described herein relates to dynamically providing a PLMN location mapping database and using the mappings to respond to monitoring request messages from an Internet of Things (IoT) application server (AS) and a service capability server (SCS). Background Art

[0004] The 3rd Generation Partnership Project (3GPP) defines a Machine Type Communication (MTC) monitoring process that allows IoT AS and SCS to monitor IoT devices. The interface used by AS and SCS to monitor IoT devices is called the T8 interface or reference point, which is provided by SCEF in 4G networks. In 5G networks, NEF provides an interface for IoT AS and SCS to obtain information about IoT devices.

[0005] One type of monitoring performed via the T8 interface is monitoring to determine the number of IoT devices located in a geographic area. Such monitoring may be useful, for example, to determine the number of IoT devices or UEs present in a fleet of motor vehicles within a geographic area. In another example, an IoT device may be attached to or worn by a cattle and may be used to track the movement of cattle within a geographic area. In security applications, an IoT device may be worn or carried by security personnel, and it may be desirable to know the number of security personnel present within a given geographic area.

[0006] To perform this type of monitoring, a user may send a request to an SCS or AS. The request from the user may use a common name, address, or geographic coordinates to identify the geographic area for which monitoring is requested. The SCS or AS sends a monitoring request message to the SCEF or NEF. Since the SCS and AS are located outside the PLMN where the IoT device is running, the SCS and AS may not know the PLMN location information (e.g., cell ID, evolved NodeB (eNB) ID, etc.) where the IoT device is located. As a result, the monitoring request message may only include a geographic identifier (e.g., the name of a place or region).

[0007] The SCEF or NEF receives the Monitoring Request message and must determine which PLMN nodes to contact to obtain a count of UEs within the geographical area identified in the Monitoring Request message. In order to identify the PLMN node to contact, the SCEF or NEF must store or have access to a mapping between the geographical identifier and the PLMN location information of the PLMN nodes serving the UEs within the geographical area.

[0008] Currently, there is no mechanism specified for automatically provisioning a PLMN location mapping database in a SCEF or NEF in response to these and other types of monitoring request messages. Thus, there is a long-standing need for methods, systems, and computer-readable media for dynamically provisioning and using PLMN location mapping in a SCEF or NEF. Summary of the invention

[0009] A method for dynamically providing and using a public land mobile network (PLMN) location mapping includes, in a service capability exposure function (SCEF) or a network exposure function (NEF) implemented using at least one processor, receiving a message including a PLMN location identifier and a non-PLMN location identifier from a PLMN network node, extracting the PLMN location identifier and the non-PLMN location identifier from the message, and storing the mapping between the PLMN location identifier and the non-PLMN location identifier in a PLMN location mapping database in the SCEF or NEF. The method also includes receiving a monitoring request message requesting Internet of Things (IoT) device information and including a non-PLMN location identifier via a monitoring interface of the SCEF or NEF, locating an entry corresponding to the non-PLMN location identifier in the PLMN location mapping database, extracting the PLMN location identifier from the database, obtaining IoT device information using the PLMN location identifier extracted from the database, and responding to the monitoring request message with the IoT device information.

[0010] According to yet another aspect of the subject matter described herein, receiving a message including a non-PLMN location identifier and a PLMN location identifier from a PLMN network node includes receiving a Diameter Connection Management Request (CMR) or a Connection Update Request.

[0011] According to yet another aspect of the subject matter described herein, receiving the CMR from the PLMN network node includes receiving the CMR from a mobility management entity (MME) in response to a setup request or a configuration update message, respectively, from an evolved Node B (eNB).

[0012] According to yet another aspect of the subject matter described herein, the non-PLMN location identifier included in the CMR or the connection update request includes geographical coordinates of an area corresponding to the eNB, and the PLMN location identifier in the CMR includes the eNB identifier.

[0013] According to yet another aspect of the subject matter described herein, a PLMN location identifier included in a CMR or a connection update request includes at least one of a cell ID, a tracking area (TA), and a routing area (RA) corresponding to geographic coordinates.

[0014] According to yet another aspect of the subject matter described herein, receiving a message including a PLMN location identifier and a non-PLMN location identifier from a PLMN network node includes receiving the message from a Self-Organizing Network (SON) system for configuring an evolved NodeB.

[0015] According to another aspect of the subject matter described herein, when an evolved Node B (eNB) connects or reconnects to a PLMN and sends a setup request message to a mobility management node, the SCEF or NEF adds or updates a mapping of PLMN locations to non-PLMN locations to a PLMN location mapping database.

[0016] According to another aspect of the subject matter described herein, the monitoring request message is a request for a count of the number of user equipment (UE) in a geographic area specified by a non-PLMN location identifier, and the SCEF uses a mapping between the non-PLMN location identifier and the PLMN location identifier to contact a mobility management entity (MME) and obtain a count of the UEs in the geographic area.

[0017] According to yet another aspect of the subject matter described herein, the extracting and storing is performed automatically by the SCEF or NEF in response to receiving a message from a PLMN network node.

[0018] A system for dynamically providing and using public land mobile network (PLMN) location mapping includes a service capability exposure function (SCEF) or a network exposure function (NEF) implemented using at least one processor. The SCEF or NEF also includes a public land mobile network (PLMN) location mapping database for storing mappings between PLMN location identifiers and non-PLMN location identifiers. The SCEF or NEF also includes an interface facing the PLMN for receiving a message containing a PLMN location identifier and non-PLMN location information from a PLMN network node. The SCEF or NEF also includes a dynamic PLMN location mapping database providing module for extracting the PLMN location identifier and the non-PLMN location identifier from the message, and storing the mappings between the PLMN location identifier and the non-PLMN location identifier in the PLMN location mapping database. The SCEF or NEF also includes a monitoring interface, which is used to receive a monitoring request message requesting Internet of Things (IoT) device information and including a non-PLMN location identifier from an application server (AS) or a service capability server (SCS), locate an entry corresponding to the non-PLMN location identifier in a PLMN location mapping database, extract the PLMN location identifier from the database, use the PLMN location identifier extracted from the database to obtain IoT device information, and respond to the monitoring request message with the IoT device information.

[0019] According to yet another aspect of the subject matter described herein, a dynamic PLMN location mapping database providing module is configured to associate a serving mobility management entity (MME) or access and mobility management function (AMF) identity with the mapping.

[0020] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium having executable instructions stored thereon, when executed by a processor of a computer, the executable instructions control the computer to perform steps. The steps are performed in a service capability exposure function (SCEF) or a network exposure function (NEF) implemented using at least one processor. The steps include receiving a message including a PLMN location identifier and a non-PLMN location identifier from a PLMN network node. The steps also include extracting the PLMN location identifier and the non-PLMN location identifier from the message, and storing the mapping between the PLMN location identifier and the non-PLMN location identifier in a PLMN location mapping database in the SCEF or NEF. The steps also include receiving a monitoring request message requesting Internet of Things (IoT) device information and including a non-PLMN location identifier via a monitoring interface of the SCEF or NEF. The steps also include locating an entry corresponding to the non-PLMN location identifier in the PLMN location mapping database, and extracting the PLMN location identifier from the database. The steps also include obtaining IoT device information using the PLMN location identifier extracted from the database. The steps also include responding to the monitoring request message with IoT device information.

[0021] The subject matter described herein can be implemented in software in combination with hardware and / or firmware. For example, the subject matter described herein can be implemented with software executed by a processor. In an exemplary implementation, the subject matter described herein can be implemented using a non-temporary computer-readable medium having computer-executable instructions stored thereon, which, when executed by a processor of a computer, controls the computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-temporary computer-readable media, such as disk storage devices, chip storage devices, programmable logic devices, and application-specific integrated circuits. In addition, the computer-readable medium that implements the subject matter described herein can be located on a single device or computing platform, or can be distributed on multiple devices or computing platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The subject matter described herein will now be described with reference to the accompanying drawings, in which:

[0023] Figure 1 is a block diagram illustrating an exemplary IoT use case scenario regarding a SCEF or NEF having a PLMN location mapping database;

[0024] Figure 2 is a message flow diagram illustrating exemplary messaging exchanged for dynamically provisioning a PLMN location mapping database in a SCEF or NEF and responding to a monitoring request using the dynamically provisioned PLMN location mapping database;

[0025] Figure 3 is a message flow diagram illustrating exemplary messaging exchanged for dynamically updating a PLMN location mapping database in a SCEF or NEF;

[0026] Figure 4 is a block diagram illustrating the dynamic updating of a PLMN location mapping database in a SCEF or NEF using a Self-Organizing Network (SON) Operation Administration and Maintenance (OAM) node.

[0027] Figure 5 is a message flow diagram illustrating exemplary messaging exchanged to respond to a monitoring request using a PLMN location map dynamically provisioned in a SCEF or NEF;

[0028] Figure 6 is a flow chart illustrating an exemplary process for dynamically providing and using a PLMN location mapping database;

[0029] Figure 7 is a block diagram of a standalone SCEF or NEF including a dynamically provided PLMN location mapping database;

[0030] Figure 8 is a block diagram of a SCEF or NEF as a component of a Diameter signaling router, wherein the SCEF or NEF includes a dynamically provisioned PLMN location mapping database; and

[0031] Fig. 9 is a block diagram of a policy server comprising a SCEF or NEF with a dynamically provided location mapping database. DETAILED DESCRIPTION

[0032] The subject matter described herein includes a SCEF or NEF including a dynamically provided PLMN location mapping database. Such a database can be used to respond to monitoring requests from SCS and AS, wherein the monitoring request includes a non-PLMN location identifier, such as geographic coordinates, geographic place names, etc. Figure 1 is a block diagram illustrating an exemplary use case regarding a SCEF or NEF with a dynamically provided PLMN location mapping database. Figure 1In the example, the IoT application server 100 sends a monitoring request message to the network open function (NEF) 102. The monitoring request message may include a non-PLMN location identifier, such as a city or state identifier, geographic coordinates (including GPS coordinates and longitude and latitude), a region identifier, a street address, etc. The NEF 102 includes a common application programming interface (API) framework (CAPIF) gateway 104, a SCEF 106, and a NEF service process module 110. The CAPIF gateway 104 provides a common API for devices to access network functions. The CAPIF gateway 104 is not essential in describing the subject matter described herein, but is included for completeness. Figure 1 The IoT AS 100 may communicate with the CAPIF gateway 104 via 3GPP messaging specified for the N33 interface or by using an open API.

[0033] On the CAPIF gateway 104 side, the SCEF 106 includes the T8 interface mentioned above for receiving monitoring requests about 4G IoT devices. On the PLMN side, the SCEF 106 communicates with PLMN network nodes, such as the mobility management entity (MME) 108, to obtain information about IoT devices. The interface between the SCEF 106 and the MME 108 is called the T6a interface.

[0034] For 5G (and possibly next generation) IoT devices, the NEF service process module 110 receives monitoring requests from application servers and service capability servers. On the PLMN-facing side, the NEF service process module 110 can communicate with the access and mobility management function (AMF) 112 via an interface called the Namf interface. The MME 108 performs mobility and registration management procedures for 4G UEs (such as 4G IoT devices). The AMF 112 performs mobility and registration management procedures for 5G UEs (such as 5G IoT devices).

[0035] Continuing with the location monitoring request example, the IoT application server 100 sends a monitoring request to the NEF 102. Depending on whether the request is for 4G IoT device information or 5G IoT device information, the CAPIF gateway 104 may forward the monitoring request to the SCEF 106 or the NEF service process module 110. The SCEF 106 or the NEF service process module 110 accesses the internal mapping between the geographic identifier and the PLMN identifier in the request message to determine the identity of the MME and / or AMF to be contacted in order to obtain the requested location information.

[0036] As mentioned above, there is no defined procedure for automatically providing PLMN location mapping in a SCEF or NEF. As a result, such location mapping may be provided manually. Given the large number of eNBs that may exist in a PLMN, manually providing location mapping in a SCEF or NEF is not desirable.

[0037] Once the PLMN location mapping is obtained, the SCEF 106 and / or NEF service process module 110 contacts the MME 108 and / or AMF 112. The MME 108 and AMF 112 provide the requested location information to the SCEF 106 and NEF service process module 110. The SCEF 106 and NEF service process module 110 provide the requested location information to the IoT application server 100. In this example, the location information is a count of UEs occupying a specific geographic area. The count can be the number of UEs that the system knows are in the geographic area during normal operation. In the 3GPP specification, this is referred to as the last known location of the UE. The count can also be the number of UEs that are currently in the geographic area. In the 3GPP specification, this is referred to as the current location.

[0038] As described above, manually providing location mapping at a SCEF or NEF is labor intensive and prone to errors.Thus, the subject matter described herein includes a method for dynamically configuring a PLMN location database at a SCEF or NEF. Figure 2 is a message flow diagram illustrating exemplary message reception for dynamically configuring a PLMN location mapping database in a SCEF or NEF. Figure 2 The message flow in is used to automatically provide a PLMN location mapping database in a SCEF, and uses a 4G message example. It can be understood that similar messaging can be used to automatically provide a PLMN location mapping database at a NEF for a 5G network element.

[0039] refer to Figure 2 , instead of manually providing a PLMN location mapping database, when an evolved Node B (eNB) attaches to or reconnects to the network, the SCEF automatically provides the database by using a location map obtained by messaging transmitted from the MME. In the illustrated example, the SCEF 106 is connected to the MME 108 via a T6a interface. The SCEF 106 receives the PLMN location mapping information through this interface. The MME 108 is connected to the eNB 150 via an S1-C interface. When the eNB 150 attaches to the network, the eNB 150 provides the location mapping information to the MME 108, and the MME 108 provides the location mapping information to the SCEF 106. The specific messaging and parameters used will now be described.

[0040] exist Figure 2In the message flow diagram illustrated in FIG. 1 , in the first row, the eNB 150 sends an S1 Setup Request to the MME 108 over the S1-C interface. The S1 Setup Request is sent when the eNB 150 attaches to or reconnects with the network. The S1 Setup Request message includes new information elements (IEs) that are not specified for the S1 Setup Request message by the current 3GPP specifications. These information elements will include non-PLMN location information, such as the geographic coordinates of the eNB 150. The geographic coordinates may include latitude and longitude or GPS coordinates. The S1 Setup Request message may also include PLMN location information, such as the cell ID of the cell in which the eNB 150 operates.

[0041] Once the MME 108 receives the S1 setup message with the PLMN and non-PLMN location information, the MME 108 sends a Diameter Connection Management Request (CMR) message to the SCEF 106. The CMR message includes the eNB ID and the supported transaction areas (TAs), as defined in 3GPP TS 36.413, Version 15.4.0 (2018-12), the disclosure of which is incorporated herein by reference in its entirety. According to 3GPP TS 29.128, Version 15.4.0 (2018-12), the disclosure of which is incorporated herein by reference in its entirety, the format of the CMR message is as follows:

[0042] <connection-management-request>::=<Diameter Header:8388732,PXY,16777346>

[0043] <session-id>

[0044] <user-identifier>

[0045] <bearer-identifier>

[0046] [DRMP]

[0047] {Auth-Session-State}

[0048] {Origin-Host}

[0049] {Origin-Realm}

[0050] [Destination-Host]

[0051] {Destination-Realm}

[0052] [OC-Supported-Features]

[0053] [CMR-Flags]

[0054] [Maximum-UE-Availability-Time]

[0055] *[Supported-Features]

[0056] [Connection-Action]

[0057] [Service-Selection]

[0058] [Serving-PLMN-Rate-Control]

[0059] [Extended-PCO]

[0060] [3GPP-Charging-Characteristics]

[0061] [RAT-Type]

[0062] [Terminal-Information]

[0063] [Visited-PLMN-Id]

[0064] *[Failed-AVP]

[0065] *[Proxy-Info]

[0066] *[Route-Record]

[0067] *[AVP]

[0068] In addition to the attribute value pairs (AVPs) listed above, the CMR message will also include new AVPs to carry PLMN location information, such as geographical coordinates (latitude and longitude). Another new AVP that can be carried in the CMR message is the Cell ID as described in 3GPP TS36.413. Other AVPs that can be carried include eNB ID, TA, RA, etc. The serving MME or SGSN information can be obtained from the Origin Host AVP of the CMR message, or it can be carried in a separate AVP.

[0069] Once the SCEF 106 receives the CMR message, the SCEF 106 adds the mapping between the PLMN location information and the non-PLMN location information to the PLMN location mapping database. The mapping information added to the database may include geographic coordinates, cell ID, eNB ID, routing area (RA), and tracking area (TA). The SCEF 106 may also associate these parameters with the MME or SGSN address of the MME or SGSN that sent the CMR message. Thus, the PLMN location mapping database record or entry created after receiving the CMR message may include the following:

[0070]

[0071] Table 1: Example PLMN Location Mapping Database Record In the example PLMN location mapping database record illustrated in Table 1, the record is indexed by geographic coordinates, which in the example shown are longitude and latitude. The next parameter is the cell ID specified in 3GPP TS 36.413. The next parameter is the eNB identifier, which is the leftmost 20 bits of the cell ID. The next two parameters are the routing area and tracking area, which are used to identify the location of the UE for different types of services. The next parameter is the MME or SGSN address, which in the example shown is an IP address.

[0072] SCEF 106 also responds to the CMR message with a Diameter Connection Management Answer (CMA) message and transmits the CMA message to MME 108 over the T6a interface.

[0073] Once SCEF 106 is provided with the location mapping information, SCEF 106 can respond to the monitoring request message from AS 100. Figure 2 In the example illustrated in FIG, AS100 sends a monitoring request message to SCEF 106. The monitoring request message is a request for the number of UEs present in a geographic area. The monitoring request message may include a non-PLMN location parameter that identifies the area for which AS100 wishes to query the number of UEs. The monitoring request may include a monitoring event type parameter that indicates that the request is a request for the number of UEs present in the geographic area. In response to receiving the monitoring request message, SCEF 106 accesses the PLMN location mapping database using a non-PLMN location identifier in the monitoring request message or a non-PLMN location identifier derived from the non-PLMN location identifier in the request message. For example, if the monitoring request message includes geographic coordinates, the geographic coordinates can be used to access the PLMN location mapping database. If the monitoring request message includes a place name, the place name can be mapped to a geographic coordinate, and then the geographic coordinates can be used to access the database.

[0074] SCEF 106 contacts the MME and SGSN corresponding to the geographic location information received in the monitoring event request message. The MME and SGSN report the number of UEs served by the eNBs or other access devices in their respective areas to SCEF 106. SCEF 106 totals the number of UEs and reports the number of UEs to AS 100 in a monitoring event response message.

[0075] Figure 3 is a message flow diagram illustrating exemplary messaging exchanged for dynamically updating the PLMN location mapping database in a SCEF or NEF when the eNB has a configuration update to send to the MME. Figure 3 108, eNB 150 transmits a PLMN location update to MME 108 using an existing configuration update message to MME 108. When eNB 150 has a configuration update to send to eNB 150, eNB 150 sends a configuration update message to MME 108. The configuration update message may include updated PLMN location information, such as an updated tracking area identifier (TAI) list update. MME 108 responds to the configuration update with a corresponding response message.

[0076] The MME 108 sends the TAI list update to the SCEF 106. The SCEF 106 may use the TAI list update to update the PLMN location mapping data. The SCEF 106 responds to the update request message with a corresponding response message. In addition, when a new eNB is provided in the network and the new eNB is connected to the MME 108, the MME 108 sends the TAI list update to the SCEF 106.

[0077] In an alternative implementation, instead of using messaging from the MME to carry information for dynamically provisioning a PLMN location mapping database at a SCEF or NEF, a SON interface may be provided to the SCEF or NEF over which the SCEF or NEF communicates with a SON system to receive location information for dynamically provisioning a PLMN location mapping database. The SON system is used by network operators to manage eNB nodes. Thus, the SON system will be or may be provided to be aware of PLMN and non-PLMN location information associated with the eNB node.

[0078] Figure 4 is a block diagram illustrating the dynamic update of the PLMN location mapping database in a SCEF or NEF using a SON system. Figure 4 In the configuration information, the SON system 160 may receive and store configuration information, including the eNB ID, cell ID, TA, RA, and geographic coordinates of the eNBs managed by the SON system 160. The SON system 160 may transmit this information to the SCEF 106 using new operations, administration, and maintenance (OAM) procedures implemented between the SON system 160 and the SCEF 106. These procedures may include sending a configuration update message including PLMN and non-PLMN location information from the SON system 160 to the SCEF 106 when the eNB first connects to the network or reconnects to the network after a disconnection. The SCEF 106 may use the information to update the mapping in the PLMN location mapping database. The SCEF 106 may confirm receipt of the configuration update message from the SON system 160 by sending a reply or confirmation message to the SON system 160.

[0079] As mentioned above, one use case for PLMN location information dynamically provided at a SCEF or NEF is in response to a query on the number of UEs present in a geographical location. Figure 5 1 is a message flow diagram illustrating exemplary messaging exchanged to respond to a monitoring request using a PLMN location mapping dynamically provided at a SCEF or NEF. Starting from the upper right corner of the figure, the SCS / IoT AS 100 sends a monitoring request to the SCEF 106 to report the number of UEs present in a geographic area. The request may identify the geographic area by a generic name (such as a region, street address, etc.). The SCEF 106 may perform the following operations:

[0080] - Use an Internet-accessible API to convert geographic regions to geographic locations (latitude /

[0081] Longitude). For example, there are Internet web servers that will convert a city name (such as Raleigh, North Carolina) into longitude and latitude or GPS coordinates. Converting a generic name into geographic coordinates is called geocoding. An example of an Internet API that can be used to perform geocoding is the Geocoding API, which is a component of the Google Maps API.

[0082] - Use geographic location to identify PLMN functions (e.g. Cell Id / eNB-Id / TAI /

[0083] Multimedia Broadcast / Multicast Service (MBMS) Service Area Identifier (SAI), etc.). This conversion may be performed using a dynamically provisioned PLMN mapping database maintained by the SCEF 106.

[0084] - Use the PLMN functionality information to identify the serving MME / AMF functionality. This conversion can also be done using a dynamically provisioned PLMN mapping database maintained by the SCEF 106.

[0085] Once the SCEF 106 identifies the serving MME or AMF, the SCEF 106 triggers the serving MME or AMF to report the number of UEs present in the PLMN function (e.g., a list of cells / RAIs / LAIs). The AMF or MME uses the cell ID, eNB ID, and / or RA / TA received from the SCEF 106 to determine the total number of UEs present in the geographic area for which the MME or AMF is responsible. Each MME or AMF contacted by the SCEF 106 reports the number of UEs. The SCEF 106 totals the number of UEs received from each MME or AMF and reports the total number to the AS 100.

[0086] Figure 6 is a flow chart illustrating an exemplary process for dynamically providing and using PLMN location mapping information at a SCEF or NEF. Figure 6 The steps illustrated in the diagram may be implemented using a SCEF or NEF including at least one processor. In step 500, the process includes receiving a message including a PLMN location identifier and a non-PLMN location identifier from a PLMN network node. For example, when an eNB connects or reconnects to a network, the SCEF 106 or NEF 102 may receive a CMR message from an MME. The CMR message may include a geographic identifier of the eNB and a PLMN identifier, such as a cell ID, an eNB ID, a RA, a TA, etc. In another example, the SCEF 106 or NEF 102 may receive geographic coordinates and a PLMN location identifier from a SON system, such as Figure 4 As shown in the diagram.

[0087] In step 502, the processing includes extracting a PLMN location identifier and a non-PLMN location identifier from the message, and storing a mapping between the PLMN location identifier and the non-PLMN location identifier in a PLMN location mapping database in the SCEF or NEF. For example, the SCEF 106 or NEF 102 may extract geographic coordinates as well as cell ID, eNB ID, RA, TA, and serving MME information from a message received from an MME or SON system.

[0088] In step 504, the process includes receiving a monitoring request message including a non-PLMN location identifier from an AS or SCS via a monitoring interface of the SCEF or NEF. The monitoring event request message may be a request for determining the number of UEs currently located in a geographic area. The monitoring request message may be used for one-time monitoring or continuous monitoring. The monitoring request message may identify the geographic area for which monitoring is requested by a non-PLMN name, such as a city, an area within a city, geographic coordinates, or other suitable identifier.

[0089] In step 504, the processing also includes locating an entry corresponding to the non-PLMN location identifier in a PLMN location mapping database and extracting the PLMN location identifier from the database. For example, if the non-PLMN location identifier is an identifier of a city or other address-like identifier, the SCEF 106 or NEF 102 can obtain the corresponding geographic coordinates (longitude and latitude or GPS) via an API that can access the Internet. The SCEF 106 or NEF 102 can then use the geographic coordinates to search in the PLMN location mapping database. If a matching entry is located, the SCEF 106 or NEF 102 can extract the PLMN location identifier from the entry or from an entry linked to the entry. As shown in Table 1 above, these identifiers can include a cell ID, an eNB ID, a TA, a RA, and a serving MME.

[0090] In step 506, the process includes obtaining IoT device information from nodes in the PLMN using the PLMN location information. For example, the SCEF 106 or NEF 102 may use the PLMN location information to query the serving MME of each eNB identified in the location mapping information extracted from the database. The MME will then contact the eNB to obtain the number of UEs served by each eNB. The eNB reports its total number to the MME, and each MME reports its total number of UEs to the SCEF 106 or NEF 102.

[0091] In step 506, the process also includes responding to the monitoring request message with IoT device information. For example, the SCEF 106 or NEF 102 may respond to the SCS or AS with the number of UEs present in the geographic area via a T8 interface.

[0092] In one example, the SCEF / NEF is an independent node that provides SCEF or NEF services. Figure 7 is an example of a standalone SCEF 106 or NEF 102 according to one exemplary implementation of the subject matter described herein. Figure 7 SCEF 106 or NEF 102 includes an interface 600 for PLMN, for receiving a message including a PLMN location identifier and non-PLMN location information from a PLMN network node. In one example, the interface 600 for PLMN is a Diameter T6a interface for receiving PLMN and non-PLMN location mapping information from an MME, or a Namf event open service API for receiving PLMN and non-PLMN location mapping information from an AMF. In another example, the interface 600 for PLMN may also include a SON interface for obtaining PLMN location mapping information from a SON system, such as Figure 4 As shown in the diagram.

[0093] The SCEF 106 or NEF 102 further comprises a PLMN location mapping database dynamic providing module 601 for extracting PLMN location information and non-PLMN location information from a PLMN message, and storing the mapping between the PLMN location information and the non-PLMN location information in a PLMN location mapping database 604 .

[0094] The SCEF 106 or NEF 102 also includes a monitoring interface 606 for receiving a monitoring request message including a non-PLMN location identifier from an AS, SCS, or 5G application function (AF). In one example, the monitoring interface 606 is a T8 interface. Typically, the monitoring interface 606 is an API-based interface through which the AS, SCS, and / or AF request and receive IoT device information. The monitoring interface 606 may include functions for responding to monitoring request messages received from the SCS and the AS. For example, the monitoring interface 606 may include the following functions: finding an entry corresponding to a non-PLMN location identifier in a PLMN location mapping database 604, locating an entry corresponding to a non-PLMN location identifier in a PLMN location mapping database 604, extracting a PLMN location identifier from the database 604, obtaining IoT device information from a node in the PLMN using the PLMN location identifier, and responding to the monitoring request message with the IoT device information. After obtaining the location mapping information from the database 604, the monitoring interface 606 may formulate the necessary query to obtain the requested UE information, and may send the query to the MME node via the PLMN-oriented interface 600. The PLMN-oriented interface 600 may receive responses to the queries and provide the responses to the monitoring interface 606. The monitoring interface 606 may aggregate the requested UE location information and provide the requested information to the SCS or AS.

[0095] The SCEF 106 or NEF 102 may also include a processor 607 and a memory 608 .

[0096] exist Figure 7 In the example illustrated in FIG. 1 , SCEF 106 or NEF 102 is an independent component. In an alternative implementation, SCEF 106 or NEF 102 may be implemented as a component of a Diameter Signaling Router (DSR). Figure 8 The diagram illustrates this implementation. Figure 8 In the embodiment, DSR 700 includes a plurality of message processors 702, 704, 706, and 708. Each message processor 702, 704, 706, and 708 includes a printed circuit board, and at least one processor 710 and a memory 712 mounted on the printed circuit board. Message processors 702, 704, 706, and 708 can exchange information via a communication medium 714 (such as an Ethernet backplane 714).

[0097] In the illustrated example, message processors 702 and 704 each implement a Diameter connection layer 716 and a Diameter routing layer 718. The Diameter connection layer 716 establishes and maintains a Diameter connection with a peer Diameter node. The Diameter routing layer 718 routes Diameter messages based on Diameter layer information in the message, such as destination host and destination domain parameters. Message processors 702 and 704 may be connected to PLMN nodes, such as MME 108, AMF, and SON system 160, to receive PLMN location mapping information to provide a PLMN location mapping database. Message processor 706 may be connected to one or more SCSs or ASs via an API-based interface such as a T8 interface to receive and respond to monitoring request messages for monitoring UE location or status. The API-based interface may be a non-Diameter interface.

[0098] The message processor 706 implements the SCEF 106 and / or the NEF 102 and may include Figure 7 Thus, the message processor 706 may include Figure 7 6 and may receive PLMN and non-PLMN location mapping information for database 604 via a Diameter connection with a PLMN network node managed by a Diameter connection layer (DCL) 716 on message processors 702 and 704. In addition, message processor 706 may receive a request for UE location and status via an API-based interface and may respond to the request using dynamically provided location information stored in PLMN location mapping database 604.

[0099] Message processor 708 implements Diameter application 724. Diameter application 724 may be any suitable Diameter application, such as a Diameter firewall application, a performance monitoring application, or other suitable Diameter application.

[0100] exist Figure 8 In the example illustrated in FIG. 7 , SCEF 106 or NEF 102 is a component of DSR 700. In yet another alternative implementation, SCEF 106 or NEF 102 may be a component of a policy manager. Fig. 9 The diagram illustrates this implementation. Fig. 9 In the example, the policy manager 800 includes: Figure 8 Message processors 702, 704, 706, and 708 are illustrated in FIG. Each message processor 702, 704, 706, and 708 includes a processor 710 and a memory 712. Message processors 702, 704, 706, and 708 may communicate via a communication medium 714. However, rather than implementing Diameter routing or only implementing Diameter routing, Fig. 9 The message processor 702 shown in the diagram includes a policy and charging rules function (PCRF) 802, which implements the PCRF function. The PCRF function includes responding to policy and charging requests from the Diameter node. The message processor 702 also implements the Diameter connection layer 716 for establishing and maintaining connections with external Diameter nodes.

[0101] Message processor 704 implementation Figure 6 SCEF or NEF functions illustrated in the figure. In short, such functions include receiving subscription requests for IoT device status and location information via a monitoring interface such as a T8 interface or other API-based interface, mapping non-PLMN location information to PLMN location information, and sending corresponding subscription requests to MME, AMF and SGSN. The functions implemented by SCEF 106 or NEF 102 may also include dynamically providing a PLMN location mapping database 604 using information received from PLMN nodes (such as MME, SGSN, AMF and SON system) via a DiameterT6a interface, a Namf event open service API or a SON system interface. Message processors 706 and 708 may implement other Diameter applications, such as policy-related applications or non-policy-related Diameter applications.

[0102] Thus, the subject matter described herein includes a SCEF or NEF with a dynamically provisionable PLMN location mapping database. Such a SCEF or NEF is a specific machine in a 3GPP network that improves the functionality of a computer network by providing convenient and secure positioning for non-PLMN location information to be mapped or converted into PLMN location information. The dynamically provisionable PLMN location mapping database also improves the technical field of database management by automating the database update process using existing 3GPP messaging. Using existing 3GPP messaging for automatic database updates reduces the need for manual database configuration and reduces the need for implementing new interfaces for database provision on existing PLMN network nodes.

[0103] It should be understood that various details of the disclosed subject matter can be changed without departing from the scope of the disclosed subject matter.In addition, the above description is for the purpose of illustration only, not for the purpose of limitation. < / user-identifier> < / session-id>

Claims

1. A method for dynamically providing and using a public land mobile network (PLMN) location mapping, the method comprising: In a service capability exposure function SCEF or a network exposure function NEF implemented using at least one processor: Receiving a message including a PLMN location identifier and a non-PLMN location identifier from a PLMN network node, wherein receiving the message includes receiving a Diameter connection management request CMR or a connection update request from a mobility management entity MME, or receiving the message from a self-organizing network SON system for configuring an evolved Node B; extracting the PLMN location identifier and the non-PLMN location identifier from the message, and storing a mapping between the PLMN location identifier and the non-PLMN location identifier in a PLMN location mapping database in the SCEF or NEF; receiving, via a monitoring interface of the SCEF or NEF, a monitoring request message requesting IoT device information and including a non-PLMN location identifier, wherein the monitoring request message is a request for counting the number of user equipments UE in a geographical area specified by the non-PLMN location identifier; locating an entry corresponding to the non-PLMN location identifier in the monitoring request message in a PLMN location mapping database, and extracting the PLMN location identifier from the database; obtaining IoT device information using the PLMN location identifier extracted from the database, wherein the SCEF contacts the MME using a mapping between the non-PLMN location identifier and the PLMN location identifier and obtains a count of UEs in the geographical area; and Respond to monitoring request messages with IoT device information.

2. The method of claim 1, wherein receiving the CMR or the connection update request comprises receiving the CMR or the connection update request from the MME in response to a setup request or a configuration update message from the evolved Node B, respectively.

3. The method of claim 2, wherein the non-PLMN location identifier contained in the CMR or the connection update request comprises geographical coordinates of an area corresponding to the evolved Node B, and wherein the PLMN location identifier in the CMR or the connection update request comprises an evolved Node B identifier.

4. The method according to claim 3, wherein the PLMN location identifier contained in the CMR or the connection update request includes at least one of a cell ID, a tracking area TA and a routing area RA corresponding to the geographical coordinates.

5. A method according to any one of the preceding claims, wherein when the evolved Node B connects or reconnects to the PLMN and sends a setup request message to the mobility management node, the SCEF or NEF adds or updates the mapping of the PLMN location to the non-PLMN location to the PLMN location mapping database.

6. The method according to any one of claims 1-4, wherein the extracting and storing are automatically performed by a SCEF or a NEF in response to receiving the message from a PLMN network node.

7. A system for dynamically providing and using a public land mobile network (PLMN) location map, the system comprising: A service capability exposure function SCEF or a network exposure function NEF implemented by at least one processor, the SCEF or the NEF includes: a public land mobile network PLMN location mapping database for storing mappings between PLMN location identifiers and non-PLMN location identifiers; A PLMN-oriented interface, configured to receive a message including a PLMN location identifier and non-PLMN location information from a PLMN network node, wherein receiving the message includes receiving a Diameter connection management request CMR or a connection update request from a mobility management entity MME, or receiving the message from a self-organizing network SON system for configuring an evolved Node B; A dynamic PLMN location mapping database provides a module for extracting a PLMN location identifier and a non-PLMN location identifier from the message, and storing a mapping between the PLMN location identifier and the non-PLMN location identifier in a PLMN location mapping database; and A monitoring interface, configured to receive a monitoring request message requesting IoT device information and including a non-PLMN location identifier from an application server AS or a service capability server SCS, wherein the monitoring request message is a request for counting the number of user equipments UE in a geographical area specified by the non-PLMN location identifier, locate an entry corresponding to the non-PLMN location identifier in the monitoring request message in a PLMN location mapping database, extract the PLMN location identifier from the database, obtain IoT device information using the PLMN location identifier extracted from the database, wherein the SCEF uses the mapping between the non-PLMN location identifier and the PLMN location identifier to contact the MME and obtain the count of UEs in the geographical area, and respond to the monitoring request message with the IoT device information.

8. The system of claim 7, wherein receiving the CMR or the connection update request comprises receiving the CMR or the connection update request from the MME in response to a setup request or a configuration update request, respectively, from the evolved Node B.

9. The system of claim 8, wherein the non-PLMN location identifier contained in the CMR or the connection update request comprises geographic coordinates of an area corresponding to the evolved Node B, and wherein the PLMN location identifier in the CMR or the connection update request comprises an evolved Node B identifier.

10. The system of claim 9, wherein the PLMN location identifier contained in the CMR or the connection update request includes at least one of a cell ID, a tracking area TA, and a routing area RA corresponding to the geographical coordinates.

11. A system according to any one of claims 7-10, wherein when the evolved Node B connects or reconnects to the PLMN and sends a setup request message to the mobility management node, the SCEF or NEF adds or updates the mapping of the PLMN location to the non-PLMN location to the PLMN location mapping database.

12. A system according to any one of claims 7 to 10, wherein the extracting and storing are performed automatically by the SCEF or NEF in response to receiving a message from a PLMN network node.

13. A system according to any one of claims 7-10, wherein the dynamic PLMN location mapping database providing module is configured to associate a serving mobility management entity MME or an access and mobility management function AMF identifier with the mapping.

14. A non-transitory computer-readable medium having executable instructions stored thereon, which, when executed by a processor of a computer, controls the computer to perform the steps according to any one of claims 1-6.

Images