US20100265095A1

Movatterモバイル変換

Info

Publication number: US20100265095A1
Application number: US12/362,457
Authority: US
Inventors: Mark Cornwall; Matthew Johnson; Barry Cahill-O'Brien
Original assignee: Itron Inc
Current assignee: Itron Inc
Priority date: 2009-04-20
Filing date: 2009-04-20
Publication date: 2010-10-21
Also published as: US20100265096A1; US8242887B2

Abstract

Packet formats and related infrastructure for improved messaging and processing of commands in an AMR system are disclosed. In one embodiment, a method for identifying the features of an endpoint based on data encoded in a standard meter reading is provided. In this regard, the method includes receiving a standard meter reading having an endpoint type and subtype classification, wherein the subtype classification corresponds to a feature of the endpoint that may be re-configured. Once received, the standard metering reading is decoded. Then, the method identifies the classification of the endpoint with regard to type and subtype and determines whether the endpoint is capable of implementing a particular command.

Description

BACKGROUND

Historically the meter readings that measure consumption of utility resources such as water, gas, or electricity has been accomplished manually by human meter readers at the customers' premises. The relatively recent advances in this area include collection of data by telephone lines, radio transmission, walk-by, or drive-by reading systems using radio communications between the meters and the meter reading devices. Although some of these methods require close physical proximity to the meters, they have become more desirable than the manual reading and recording of the consumption levels. Over the last few years, there has been a concerted effort to automate meter reading through the implementation of devices and messaging systems that allow data to flow from the meter to a host computer system without human intervention. These systems are referred to in the art as Automated Meter Reading (AMR) systems.

In an AMR system, an Encoder Receiver Transmitter (“ERT”) may be implemented within a utility meter in order to encode and transmit data utilizing radio-based communications. The ERT is a meter interface device attached to the meter, which either periodically transmits utility consumption data (“bubble-up” ERTs) or receives a “wake up” polling signal containing a request for their meter information from a collector (e.g., a fixed transceiver unit, a transceiver mounted in a passing vehicle, a handheld unit, etc.).

Transmissions of meter readings from an ERT are typically encoded as “packetized” data. In the present application, the term “packet” is intended to encompass packets, frames, cells or any other method used to encapsulate data for transmission between remote devices. As understood in the art, packets typically maintain a plurality of fields as well as a preamble and trailer to identify the beginning and end of the packet. In this regard, existing packet formats and related systems typically include at least one field that identifies the category of utility meter (gas, water, electricity etc.) that is reporting a meter reading. However, these aspects of meter messaging systems have not developed in ways to account for the expanded functionality and diversity in the types of ERTs in use. For example, while existing meter messaging systems identify ERT (“endpoint”) type, endpoints are not readily classified based on their ability to satisfy particular commands. A utility service provider may not be able to readily determine all of the capabilities of a particular endpoint from data in a meter reading. The enhanced services desired by customers and utility service providers will only continue to increase the diversity in the types of endpoints being installed in AMR systems. The limitations in existing meter messaging systems may limit continued development of these enhanced services.

SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of the disclosed subject matter will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram depicting an illustrative meter reading system formed in accordance with an embodiment of the disclosed subject matter;

FIG. 2 is a block diagram depicting components of one example of an endpoint device formed in accordance with an embodiment of the disclosed subject matter;

FIG. 3 is a block diagram illustrating a packet format suitable for illustrating aspects of the disclosed subject matter;

FIG. 4 is a block diagram depicting components of one example of a collector formed in accordance with an embodiment of the disclosed subject matter; and

FIG. 5 is a flow diagram of one example feature identification routine formed in accordance with an embodiment of the disclosed subject matter.

DETAILED DESCRIPTION

The detailed description set forth below in connection with the appended drawings where like numerals reference like elements is intended as a description of various embodiments of the disclosed subject matter and is not intended to represent the only embodiments. Each embodiment described in this disclosure is provided merely as an example or illustration and should not be construed as preferred or advantageous over other embodiments. In this regard, the following disclosure first provides a general description of a meter reading system in which the disclosed subject matter may be implemented. Then, an exemplary routine for identifying the capabilities of an endpoint based on data encapsulated in a standard meter reading will be described. The illustrative examples provided herein are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Similarly, any steps described herein may be interchangeable with other steps, or combinations of steps, in order to achieve the same or substantially similar result.

Referring now toFIG. 1, the following is intended to provide a general description of one embodiment of a communications system, such as ameter reading system100, in which aspects of the present disclosure may be implemented. In one embodiment, themeter reading system100 may be an automated meter reading (AMR) system that reads and monitors endpoints remotely, typically using a collection system comprised of fixed collection units, mobile collection units, etc.

Generally described, themeter reading system100 depicted inFIG. 1 includes a plurality ofendpoint devices102, acollection system106, and ahost computing system110. Theendpoint devices102 are associated with, for example, utility meters UM (e.g., gas meters, water meters, electric meters, etc.), for obtaining data, such as meter data (e.g., consumption data, tampering data, etc.) therefrom. Theendpoint devices102 in themeter reading system100 may be a wired or wireless communications device capable of performing two-way communications with thecollection system106 utilizing AMR protocols. For example, theendpoint devices102 are capable of receiving data (e.g., messages, commands, etc.) from thecollection system106 and transmitting meter data or other information to thecollection system106. Depending on the exact configuration and types of devices used, theendpoint devices102 transmit standard meter readings either periodically (“bubble-up”), in response to a wake-up signal, or in a combination/hybrid configuration. In each instance, theendpoint devices102 are configured to exchange data with devices of thecollection system106.

Still referring toFIG. 1, thecollection system106 of themeter reading system100 collects meter reading data and other data from the plurality ofendpoint devices102, processes the data, and forwards the data to thehost computing system110 of theutility service provider112. Thecollection system106 may employ any number of AMR protocols and devices to communicate with theendpoint devices102. In the embodiment shown, thecollection system106, for example, may include ahandheld meter reader120 capable of radio-based collection and/or manual entry of meter readings. As illustrated, thecollection system106 may also include a mobile collection unit122 (e.g., utility vehicle), configured with a radio transmitter/receiver for collecting meter readings within a drive-by coverage area. In addition, thecollection system106, may also include, for example, a fixed network comprised of one or more Cell Control Units124 (“CCU124”) that collect radio-based meter readings within a particular geographic area. Each of the meter reading devices120-124 may collect either directly from theendpoint devices102, or indirectly via one or moreoptional repeaters126. Collectively, the meter reading devices included in thecollection system106 will be referred to hereinafter as a “collector.” In this regard, those skilled in the art and others will recognize that other types of collectors then those illustrated inFIG. 1 may be used to implement aspects of the disclosed subject matter. Accordingly, the specific types of devices illustrated should be construed as exemplary.

In the embodiment depicted inFIG. 1, thecollection system106 is configured to forward meter readings to thehost computing system110 of theutility service provider112 over awide area network114, which may be implemented utilizing TCP/IP Protocols (e.g., Internet), GPRS or other cellular-based protocols, Ethernet, WiFi, Broadband Over Power Line, and combinations thereof, etc. In one aspect, thecollection system106 serves as the bridge for transmitting data between devices that utilize AMR protocols (e.g., the endpoint devices102) with computers (e.g., the host computing system110) coupled to thewide area network114. As mentioned previously, collectors are configured to receive meter reading data (e.g., packets) from one ormore endpoints102. The received data is parsed and re-packaged into a structured format suitable for transmission over thewide area network114 to thehost computing system110. In this regard, meter reading data may be aggregated in a data store maintained at thehost computing system110. Accordingly, thehost computing system110 includes application logic for reading, processing, and managing the collection of meter data.

The discussion provided above with reference toFIG. 1 is intended as a brief, general description of onemeter reading system100 capable of implementing various features of the present disclosure. While the description above is made with reference to particular devices linked together through different interfaces, those skilled in the art will appreciate that the claimed subject matter may be implemented in other contexts. In this regard, the claimed subject matter may be practiced using different types of devices and communication interfaces than those illustrated inFIG. 1.

Turning now toFIG. 2, there is shown one example architecture of anendpoint device102 for use in themeter reading system100. Eachendpoint device102 continuously gathers and stores meter data from the associated sensors of the utility meters. Upon request or periodically (e.g., every 30 seconds) theendpoint device102 retrieves the stored data, formats and/or encodes the data according to one or more metering protocols, and transmits this data with other information via radio frequency (RF) communication links to a collector. Theendpoint device102 is also capable of receiving data from a collector, or other RF-based communications devices.

For carrying out the functionality described herein, theendpoint device102 comprises amain computing device200 communicatively coupled to acommunications device202. In the example depicted inFIG. 2, thecommunications device202 is a radio-based transceiver, transmitter-receiver, or the like, that may include acommunications antenna204, transmit (TX)circuitry206 and receive (RX)circuitry208, and anantenna multiplexer210 that switches between the transmit (TX)circuitry206 and the receive (RX)circuitry208 depending on the mode of operation. The communications device may be configured to transmit RF-based communications signals according to any suitable modulation protocols, such as DSSS, FHSS, FM, AM, etc. The transmit circuitry and/or receive circuitry may be implemented as an RF integrated circuit (RFIC) chip, and may comprise various components including, for example, mixers, a voltage controlled oscillator (VCO), a frequency synthesizer, automatic gain control (AGC), passive and/or active filters, such as harmonic filters, dielectric filters, SAW filters, etc, A/D and/or D/A converters, modulators/demodulators, PLLs, upconverters/downconverters, and/or other analog or digital components that process baseband signals, RF signals, or IF band signals, etc.

In one embodiment, theendpoint device102 transmits data over a preselected set of frequency channels in a predefined frequency band (“operational frequency band”) using frequency hopping spread spectrum (FHSS) techniques. For example, in one embodiment, theendpoint device102 may operate over a preselected set of 80 channels approximately 200 KHz in width. One example of such a frequency band is the 902-918 MHz portion of the ISM frequency band, although other portions of the ISM or other radio frequency bands may be used. The operational frequency band may be contiguous (e.g., 902-918 MHZ) or non-contiguous (e.g., 902-908 and 916-924 MHz). In this embodiment, theendpoint device102 may frequency hop between channels in the entire operational frequency band or may frequency hop between a subset of channels (e.g., fifty (50) channels) in the operational frequency band. In any event, standard meter readings containing a default set of data may be transmitted as a frequency-hopping spread-spectrum (FHSS) signal at a frequency and time selected in accordance with a frequency hopping table. For example, in one embodiment, using a frequency hopping table, theendpoint device102 will periodically transmit a FHSS signal having a standard meter reading using a programmed subset of fifty (50) frequency channels.

As briefly discussed above, the communication of RF-based communications signals by theendpoint devices102 is carried out under control of themain computing device200. In the example depicted inFIG. 2, themain computing device200 may include aprocessor220, atiming clock222, and amemory224, connected by acommunication bus226. As further depicted inFIG. 2, themain computing device200 may also include an I/O interface228 for interfacing with, for example, one or more sensors S associated with a utility meter. The one or more sensors S may be any known sensor for obtaining consumption data, tampering data, etc. The data obtained from the sensors S is processed by theprocessor220 and then stored in thememory224.

Thememory224 depicted inFIG. 2 is one example of computer-readable media suited to store data and program modules for implementing aspects of the claimed subject matter. As used herein, the term “computer-readable media” includes volatile and non-volatile and removable and non-removable memory implemented in any method or technology capable of storing information, such as computer-readable instructions, data structures, program modules, or other data. In this regard, thememory224 depicted inFIG. 2 is one example of computer-readable media but other types of computer-readable media may be used.

Those skilled in the art and others will recognize that theprocessor220 serves as the computational center of theendpoint device102 by supporting the execution of instructions that are available from thememory224. Accordingly, theprocessor220 executes instructions for managing the overall system timing and supervision of theendpoint device102 including accumulating and storing sensor data, providing data to be transmitted, as well as selecting the time and frequency channel the data will be transmitted/received. In this regard, instructions executed by theprocessor220 effectuates the formatting and encoding of the meter data and other data in any standard format or protocol.

In one embodiment, a packet format and associated metering infrastructure are provided that minimize the quantity of data transmitted from theendpoint102 when reporting meter readings. Upon request or periodically (e.g., every 30 seconds) theendpoint102 may transmit a standard meter reading containing a default set of data. To conserve resources, theendpoint102 may be configured to only supply power to thetransmitter circuitry206 as needed. By reducing the size or amount of data transmitted, the amount of time that power is supplied to thetransmitter circuitry206 is also minimized. Accordingly, providing a highly compact packet format to report standard meter reading will reduce the total power consumed and effectively extend the operational life of the endpoint.

Now with reference toFIG. 3, a packet format well-suited for reporting a standard meter reading will be described. In the embodiment depicted inFIG. 3, thepacket300 includes a plurality of rows (“fields”) having entries organized within theBYTES302,VALUE304, andDESCRIPTION306 columns. In this embodiment, theBYTES302 column includes entries containing integers that identify the amount of data allocated to a particular field. TheVALUE304 column includes entries that identify a fixed or variable value for the data within the field of thepacket300. Similarly, theDESCRIPTION306 column includes a string of characters that provides a human-readable description of the field.

In accordance with one embodiment, thepacket300 provides a highly compact format for encapsulating a standard meter reading. Thepacket300 depicted inFIG. 3 utilizes a total fixed length of 136 bits in encapsulated data. In particular, thepacket300 includes a fixed length 32-bit consumption field308 suitable for providing the relevant data while minimizing packet size. An expanded 16-bit cyclicalredundancy check field310 is provided to improve the detection rates for identifying corrupt packets. In addition, a lengthenedtamper field312 is provided that enables improved tamper identification. As described in further detail below, theprotocol ID field314 and endpoint type/subtype field316, allow the implementation of improved mechanisms for identifying the features of a particular endpoint. Those skilled in the art and others will recognize that certain attributes of thepacket300 illustrated inFIG. 3 are only illustrative. In this regard, entries within the fields of thepacket300 may be added/removed or otherwise modified in alternative embodiments. Accordingly, thepacket300 is only representative one embodiment of how a standard meter reading may be encapsulated for transmission from theendpoint102.

Returning toendpoint102 depicted inFIG. 2, thememory224 includes apacket creation interface228 having instructions suitable for being executed by theprocessor220 to implement aspects of the present disclosure. In one embodiment, thepacket creation interface228 implements a method operative to collect packet data for transmission from theendpoint102 in a standard meter reading. For example, thepacket creation interface228 may be used to collect data in preparation of encoding the packet300 (FIG. 3). When called, thepacket creation interface228 may receive two parameters that identify a current consumption value and a pointer referencing a buffer memory space that will be used to store packet data. Upon receiving the call, an existing buffer memory space having a partial set of data that includes a protocol ID value corresponding to a process for decoding the packet and a type/subtype value for classifying one or more features of the endpoint is accepted. Then, thepacket creation interface228 retrieves one or more data items for temporary storage in the buffer memory space. In one embodiment, the one or more data items include a serial number that uniquely identifies the endpoint. Upon storing the one or more data items in the buffer memory space, thepacket creation interface228 returns the pointer to the buffer memory space. In this way, data is collected on the endpoint in preparation of encoding thepacket300 for transmission to a remote device.

Now with reference toFIG. 4, one example component architecture for acollector400 will be described. As mentioned previously with reference toFIG. 1, thecollector400 may be a handheld meter reader, a mobile collection unit (e.g., utility vehicle), a CCU, etc. Generally described, thecollector400 includes aprocessor402, amemory404, and aclock406 interconnected via one ormore buses408. In addition, thecollector400 includes anetwork interface410 comprising components for communicating with other devices over the wide area network114 (FIG. 1), utilizing any appropriate protocol, such as TCP/IP Protocols (e.g., Internet), GPRS or other cellular-based protocols, Ethernet, WiFi, Broadband Over Power Line, and combinations thereof, etc. As further depicted inFIG. 4, thecollector400 includes a radio-based communication device412 for transmitting/receiving wireless communications with other radio-based devices (e.g., the endpoint devices102).

In the embodiment shown inFIG. 4, the communication device412 includes at least one transceiver, transmitter-receiver, or the like, generally designated418, of half-duplex (transmit or receive but not both simultaneously) or full-duplex design (transmit and receive simultaneously) that is capable of identifying, locating, and tracking FHSS signals transmitted by theendpoint devices102. In one embodiment, the radio-based communications device412 has the ability to measure the signal strength level and/or noise/interference level of all channels across the endpoints' operating frequency band. The communication device412 examines the entire portion of the operational frequency band employed by theendpoint devices102, to identify a signal suggestive of a standard meter reading. In addition or alternatively, thecollector400 can send a “wake-up” message in order to establish communication with theendpoint device102.

In the embodiment depicted inFIG. 4, thememory404 includes afeature identification application420 having instructions suitable for being executed by theprocessor402 to implement aspects of the present disclosure. Thecollector400 is configured to receive meter reading data (e.g., packets) from different types of endpoints. In this regard, some endpoints may be configured to accept and respond to received commands. For example the collector may issue and transmit a command to re-program the channels on which the endpoint transmits meter readings, request particular types and/or intervals of consumption data, modify network configuration information and/or the packet format in which data is encapsulated for network transmission, etc. In one embodiment, thefeature identification application420 identifies the features of an endpoint based on data provided in a standard meter reading. By identifying these features, determinations may be readily made regarding whether an endpoint can implement a particular command.

Now, with reference toFIG. 5, afeature identification routine500 that identifies the capabilities of an endpoint device from data in a standard meter reading will be described. As mentioned previously, a collector may receive meter readings from various types of devices. In one embodiment, thefeature identification routine500 decodes and analyzes packet data to identify the features of the endpoint that is reporting a meter readings. As a result, a collector or other device can readily identify whether the endpoint is capable of implementing a particular type of command. While thefeature identification routine500 is described herein as being performed on a device that collects a meter reading (i.e., a collector), those skilled in the art and others will recognize that the routine500, or a portion thereof, may be implemented on other types of devices.

As illustrated inFIG. 5, thefeature identification routine500 begins atblock502 where a standard meter reading containing a default set of data is captured. As mentioned previously, thecollector300 can generate and store a “snapshot” of the operational frequency band employed by theendpoint devices102. In one embodiment, thecollector300 examines the operational frequency band employed by theendpoint devices102 to identify and capture a signal containing a standard meter reading, atblock502.

Atdecision block504 of thefeature identification routine500, a determination is made regarding whether the endpoint that is reporting a meter reading is limited to performing simplex communication. A collector provided by the disclosed subject matter is capable of reading and decoding packets from multiple types of endpoints, at least some of these endpoints may be legacy devices that are limited to performing simplex communications. In one embodiment, a data item in the preamble of the packet received atblock502 indicates whether the packet originated from one of the types of legacy devices. In this instance when the result of the test performed atblock504 is “yes,” a command cannot be implemented on the endpoint and thefeature identification routine500 proceeds to block516, where it terminates. Conversely, if the data item in the preamble indicates that the received packet was not generated by a legacy device, the result of the test performed atblock504 is “no” and thefeature identification routine500 proceeds to block506.

Atblock506, the packet containing the standard meter reading received atblock502 is categorized based on the method that will be used to decode the packet. It will be appreciated that endpoints may utilize any number of different packet formats in reporting metering reading data. In one embodiment, an enhanced format is provided that generically classifies a packet based on how the packet will be decoded. For example, thepacket300 described above with reference toFIG. 3 includes aprotocol ID field318 having a value that is read and used to categorize theincoming packet506. In this regard, the value in theprotocol ID field316 corresponds to a set of attributes that affect how the packet will be decoded including but not limited to, whether the packet is of fixed or variable length, field size, redundancy checking and tampering attributes, and the like.

Atblock508 of thefeature identification routine500, the incoming packet is decoded based on the categorization performed atblock506. As understood in the art, the specific process or algorithm used to decode a packet may depend on the structure and/or values of data being provided in the transmission. In this regard and by way of example only, decoding the packet atblock508 may include calculating error detection values, applying redundancy checks, verifying tamper counters, and the like. However, it should be understood that the process or algorithm used to decode the packet varies depending on how the packet is categorized atblock506. Accordingly, other and/or different processes may be performed atblock508 without departing from the scope of the claimed subject matter.

As illustrated inFIG. 5, the type/subtype categorization of the endpoint that generated an incoming packet is identified, atblock510. As mentioned previously, a collector may receive a meter reading from any number of devices, each having potentially different capabilities.

In one embodiment, the enhanced packet format provided by the disclosed subject matter is configured to better account for the increase in diversity of endpoint types. In the embodiment depicted inFIG. 3, thepacket300 includes a type/subtype field306 which facilitates the use of a layered and more extensible schema in classifying endpoints. In existing AMR systems, packets used to report standard meter readings have typically maintained relatively small type fields (i.e., 4-bits). When a 4-bit type field is used, a total of sixteen (16) classifications of endpoints are available. In one embodiment, theexemplary packet300 includes an 8-bit type/subtype field having 5-bits allocated for an endpoint type and 3-bits allocated for a corresponding endpoint subtype. Accordingly, a total of thirty-two (32) classifications are available for endpoint types with each type capable of being further classified within eight (8) subtypes. In one embodiment, the attributes of a particular endpoint, including the endpoints corresponding type/subtype, may be cached at the collector and/or host computing system.

Atdecision block512, thefeature identification routine500 determines whether a particular endpoint is capable of implementing an issued command. As mentioned previously, data from a plurality ofendpoints102 may be aggregated in a data store maintained at thehost computing system110. This data may be analyzed for numerous purposes including detecting problems/malfunctions in meters, tuning network configuration attributes, and the like. Based on this or other processing, a command may be issued from thehost computer system110 and/orcollector300 to modify the current configuration of a particular endpoint.

In determining whether an endpoint is capable of implementing a particular command, atblock512, multi-layered processing of the endpoint types/subtype may be performed. By way of example, a command may be issued to “cut-off” the supply of a utility service, such as natural gas, at endpoints within a particular geographic area. In this instance, both the type and subtype associated an endpoint may be used in determining whether the command can be implemented. In particular, the value corresponding to the endpoint type may indicate that the endpoint is used to supply natural gas. However, each endpoint of this type may not be capable of performing an automatic “cut-off” to terminate utility services based on a received command. Accordingly, the subtype field can be used to further classify the features provided by the endpoint to, for example, specify whether the endpoint is capable of implementing an automatic “cut-off.”

Accordingly, a lookup to identify the classification of the endpoint with regard to type/subtype may be performed atblock512. If the result of the lookup indicates that the endpoint is capable of implementing an issued command, the result of the test performed atblock512 is “yes” and thefeature identification routine500 proceeds to block514, described in further detail below. Conversely, if the lookup indicates that endpoint is not capable of implementing the issued command, thefeature identification routine500 proceeds to block516, where it terminates. In this instance, utility service personnel may reconfigure the endpoint manually or take other action to implement the desired functionality.

Atblock514 of thefeature identification routine500, a command that modifies the configuration of a particular endpoint is implemented. Upon determining that an endpoint is capable of implementing an issued command, a message containing command logic may be routed from thehost computing system110 to theendpoint102 via thecollector300. In this regard, a received command may re-program the channels on which theendpoint102 transmits meter readings, request particular types and/or intervals of consumption data, modify network configuration information and/or the packet format. However, all of the types of commands that may be satisfied atblock514 are not described in detail here. Once the command has been implemented, thefeature identification routine500 proceeds to block516, where it terminates.

While embodiments of the claimed subject matter have been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the present disclosure.

Claims

1. A method of identifying the features of an endpoint based on data encoded in a standard meter reading, the method comprising:

receiving a standard meter reading having an endpoint type and subtype classification, the subtype classification corresponding to a capability of the endpoint that may be re-configured;

decoding the standard metering reading; and

identifying a type and subtype classification of the endpoint to determine whether the endpoint is capable of implementing an issued command.

2. A packet creation interface that implements a method operative to collect packet data for transmission from an endpoint in a standard meter reading, the method comprising:

receiving an interface call having parameters that identify a current consumption value and a pointer referencing a buffer memory space for temporary storage of packet data;

accepting an existing buffer memory space having a protocol ID value corresponding to a process for decoding the packet and a type/subtype value for classifying on or more features of the endpoint;

retrieving one or more data items for temporary storage in the buffer memory space, the one or more data items including serial number that uniquely identifies the endpoint; and

returning the pointer to the buffer memory space.